GNOME Bugzilla – Bug 723274
Can't handle ED25519 keys
Last modified: 2018-03-05 11:38:09 UTC
openssh 6.5 has support for ED25519 keys. http://www.openssh.com/txt/release-6.5 $ ssh-keygen -t ed25519 -f test-ed25519 -N "" Generating public/private ed25519 key pair. Your identification has been saved in test-ed25519. Your public key has been saved in test-ed25519.pub. --- *snip* --- $ ssh-add test-ed25519 Error reading response length from authentication socket. Could not add identity: test-ed25519
Still not supported in 3.12.0. Same goes for bug #641082 regarding ECDSA keys.
I have posted a 100 USD bounty on this (valid for the next 6 months) that can be seen here: https://www.bountysource.com/issues/22896549-can-t-handle-ed25519-keys/backers
Is gnome-keyring maintained at all? Not being able to handle ED25519 keys is a mountain-large annoyance... (not to mention the cryptic error message)
The problem apply also to Seahorse which cannot generate or list ed25519 (and also ecdsa) keys. However, I opened a bug on Seahorse and a patch which works has been proposed. (https://bugzilla.gnome.org/show_bug.cgi?id=754028) Perhaps, this could put again some interest in Gnome Keyring daemon to manage this type of key!
Dupe of bug #641082 I think
(In reply to Sam Morris from comment #5) > Dupe of bug #641082 I think The bug you mention is related to ECDSA which is a different type of key than ED25519, although both based on elliptic curves. The ED25519 keys are also stored in the new OpenSSH key format which breaks compatibility with the previous PEM format (used by default for other key types). So they might be extra work to implement. However, if one generates "known" key types in the new format, it does not work as well. Try: ssh-keygen -t rsa -b 4096 -o -a 100 This is a RSA key to be used for SSH-2, but the format has changed and gnome-keyring cannot handle it (nor can seahorse!). As Antoine Pitrou stated, this start slowly but surely to be a annoyance for more and more users. Basically all newer keys generated with OpenSSH with more security against brute force attack cannot be used by Gnome Keyring and Seahorse.
Any progress on this? More and more people suggest using Ed25519 but it's not use able with gnome/seahorse setup.
There is no bounty on https://www.bountysource.com/issues/22896549-can-t-handle-ed25519-keys anymore, but this issue is ugly and should really be fixed… We have 2017 now and still no ED25519 support in GNOME's keyring?! I would have expected this to ship with Debian 9 at most, but this might be too late now. Anyway, implementing this is in some way really a security improvement, because actually when you have multiple identities (RSA & ED25519), which might be common for compatibility reasons, GNOME's ssh actually selects the RSA one and unless the user notices this because he/she has different passwords set for the keys, the user will never notice it. This means GNOME may downgrade the security without any user feedback while users think ssh always uses the "best". FYI when only ED25519 is available GNOME'S ssh-agent falls back to the default ssh-agent, which supports ED25519 keys. https://bugzilla.gnome.org/show_bug.cgi?id=672145 is also about this issue.
If someone would like to see this and provide a patch, please see https://wiki.gnome.org/Git/Developers#Contributing_patches - thanks!
(In reply to 1d28ed33 from comment #8) > There is no bounty on > https://www.bountysource.com/issues/22896549-can-t-handle-ed25519-keys > anymore Added 23$ to change that! :) Pretty please someone take it or others reading it add more bounty. thanks all!
Yeah, already $40 bounty!
This will require significant work to be implemented. The struggle is mainly in the internal representation of the key in the gnome-keyring-daemon. It is using PKCS#11 and there is no straight-forward representation for ed25519 keys as it is for RSA and DSA keys (that are supported at the moment). I plan to have a look into that since I have some experience with both PKCS#11 and SSH, though I can not confirm how much time I will be able to spend on that nor the timeline of this feature. The implementation of ECDSA keys should be just a small addition to the Ed25519 keys (or the other way round).
gpg-agent already supports ED25519 SSH keys. It even keeps SSH keypairs in its own storage. Maybe it would make sense to kill off the SSH component and look into using gpg-agent for this, which with pinentry-gnome3 already has a connection to GCR.
I don't think many people really care about full ED25519 (or ECDSA) support in gnome-keyring, just ssh-agent support, so I bet most users would be satisfied if bug #775981 was fixed instead. Jakub, that might be a better bug to focus on first if you're interested in working on gnome-keyring.
Good idea. Personally I'd say I care about that it (=using ED25519 keys) works. How it is done, does not matter. In the end, it should work.
I disagree and think the solution using the GnuPG agent is simpler. GnuPG is already an application using GCR to ask and libsecret to store private key passwords in the GNOME keyring, so most of the code is already written. AFAICT the following steps are needed: 1. Configure pinentry-gnome3 as GnuPG's pinentry implementation 2. Enable and start all the gpg-agent socket units 3. Set SSH_AUTH_SOCK to the agent's SSH socket As a bonus, this gets not just SSH integration but GPG integration as well. 1 and 2 are probably best solved at the distribution level via preset config files, unless GNOME makes a big leap in systemd --user integration. 3 could be a job for pam-gnome-keyring. 1 could perhaps be solved by overriding the agent's arguments via a systemd service.d snippet, if this should be configured as part of the session setup.
Any news? The bug bounty has just been increased even further.
There's progress in bug #754028. Primary problem is there is no maintainer, so nobody to review the patches.
Why is GNOME even shipping software that doesn't have a maintainer? Either find one or pull gnome-keyring out entirely.
jon@dorsal.tk: Feel free to discuss meta issues not directly related to handling ED25519 keys (the topic of this task) on mailing lists/forums if you really think that shipping a platform without a password/key storage application in 2017 is something you want to discuss. Not on this task as it's off-topic. Thanks.
This should be fixed as part of bug 775981.