Multiple key pairs

[nullpixel]

Any news?

[agrinman]

We're working on it (no updates yet) -- we're figuring out the best way to do this. It's easy to manage two (or more) key pairs, but there's a bunch of UI changes to Kryptonite and kr that have to happen. kr me, kr copy, kr github etc now have to ask you which public key you want, all the approve dialogues and push notifications must specify which key you're authenticating with, and a few other smaller details. We're also considering have per-key policies, etc. We want the UI to be the same as it is now for users that only have one key (which we think will be the case for most users).

What's your use-case for multiple key pairs? One of the most compelling reasons we've heard so far is that GitHub/Bitbucket require different public keys for each user account.

[nullpixel]

Yeah, it was actually for GitHub. My other use of it would be for servers that do not actually support newer keys, like CentOS.

There's a few things I'd suggest about the iOS layout yesterday anyway, some buttons don't line up etc

[agrinman]

Got it, thanks. Yes that was the other reason -- people want to use ed25519 keys but servers (and even services like AWS https://github.com/kryptco/kr/issues/94) don't support them.

We'd greatly appreciate any suggestions, please create an issue or email us at support@krypt.co!

[standemchuk]

Hi, any news or help needed with this?

[agrinman]

No news yet. It's definitely on our roadmap and we're listening. It's still a relatively low priority as we expect most users to only need 1 key pair.

May I ask what your use case is for multiple key pairs? We'd love to know if we're missing any important use case and should update the priority of this feature.

[standemchuk]

I have multiple github accounts, one for personal projects and a few more for work projects. Can't really go around it :) So kinda forced to have an ssh config with different hosts and keys.

[nullpixel]

Plus, some of us just prefer having separate keys for everything: I'd love it if you could actually do this as a higher priority

[agrinman]

@standemchuk thanks!

[humandoing]

Hi Alex,

I don’t need this as a higher priority feature per se, but in general, most of the colleagues that I have that work in devops or security, or have any part of a deployment process to multiple machines or environments cringe at the idea of a single key pair. A lot of the reason behind this is that if you experience a compromised private key when only using a single keypair, you need to remove the corresponding public key from every single machine or service that might have access. This can take hours / days / mistakes can be made, keys can be missed etc. - leaving you open to potential vulnerability. On the other hand if you generate a key pair per service or per machine group or per machine (or whatever your process might require) - you’ll far more easily be able to remove and regenerate a new key pair for that service.

Granted the argument Kryptonite might make here could be “well, your private key is on your phone, so if someone gains access to one of your private keys they’ll gain access to all of them” which I suppose could be a fair argument.

Apologies if this is long-winded - just trying to provide additional context along with Jamie and Stanislav.

On Jun 30, 2017, at 9:03 PM, Alex Grinman notifications@github.com wrote:

No news yet. It's definitely on our roadmap and we're listening. It's still a relatively low priority as we expect most users to only need 1 key pair.

May I ask what your use case is for multiple key pairs? We'd love to know if we're missing any important use case and should update the priority of this feature.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kryptco/kryptonite-ios/issues/44#issuecomment-312408804, or mute the thread https://github.com/notifications/unsubscribe-auth/AAACbM_iq5nQ9QJFvOXCHBUsb8FmN38Fks5sJcUVgaJpZM4NSGUF.

[nullpixel]

Thanks! This is exactly what I’m waiting for.

[werediver]

To bump and to emphasize one aspect.

My use case is multiple GitHub accounts (most of the time), and the lack of support for multiple key-pairs in Krypton Core is a blocker for me.

So, while I believe that the majority of users could live with a single key-pair, it is a blocker for a significant amount of users.

By saying "it's a blocker" I mean that with multiple key-pairs you have to put some effort into setting up your environment to work properly, and an attempt to include Krypton Core into such a configuration causes more pain then joy (while within a single key-pair environment it works pretty neat! 💯 ).

[kcking]

@werediver Do you currently use SSH to authenticate to multiple GitHub accounts? This generally requires setting up multiple hosts in your ~/.ssh/config and specifying the correct IdentityFile for each, then setting your git remotes appropriately (more detail here: https://www.keybits.net/post/automatically-use-correct-ssh-key-for-remote-git-repo/)

Removing the IdentityFile lines from the ssh config block added by Krypton (and adding ~/.ssh/id_krypton to the GitHub user you'd like to use Krypton with) should fix your issue.

[werediver]

@kcking yes, I successfully use SSH access to GitHub with multiple accounts (work/personal) with 2FA on GitHub. Normal setup is not a problem, I'm only talking about the possibility of using Krypton Core in such a configuration.

[nullpixel]

is this feature still being worked on?

[kcking]

@werediver did you try the config change I mentioned at the bottom of my reply?

[agrinman]

@nullpixel it's in the feature log, but we decided to postpone the feature. Will update the label -- sorry!

[nullpixel]

aw :( I'd still love to use this, but as mentioned, I can't live on a single keypair

[agrinman]

@nullpixel understandable, sorry to hear that. We will support multi-key eventually and hope to have you back then :). Also as @kcking mentioned above you can still use Krypton on one of the GitHub accounts (i.e. for work).

[werediver]

@werediver did you try the config change I mentioned at the bottom of my reply?

Well, I took a look. But I've already mentioned that I do have a working configuration, so I do not experience this kind of troubles.

Just wondered if I can use this neat tool :) Unfortunately, not yet.

[rymcol]

@agrinman @kcking many macOS devs use Sparkle to manage updates, which requires a DSA signature on the code to push a release update. Given DSA was deprecated by openssh and is generally regarded as weaker, what are you thoughts on adding DSA for code signatures as a secondary key type once multiple key support has been added to the iOS/Android targets?

It would clearly need to be separated as a specific subset of functions that only apply to services that still require/support it, which could add to logic complexity quite a bit. However, this could be particularly useful in an enterprise setting by requiring multiple-key signatures for code signing releases.

[spgreene]

May I ask what your use case is for multiple key pairs? We'd love to know if we're missing any important use case and should update the priority of this feature.

I would actually like to have multiple GPG key support. I use different email/identify for a few projects and I would like to use krypton for the different GPG keys. E.g. sign this git commit with GPG Key A, and sign this other git commit on another project with GPG Key B.

[javi-salazar]

i need moar keys!! =D