add support for Ed25519 about libssh2 HOT 26 CLOSED

My employer has slated some dev time for me to look at ED25519 support within the next month or so. I plan on looking into this further then. I personally would like a stand alone version of 25519 support rather than adding a BoringSSL backend; but we'll see if I can manage to get something working.

from libssh2.

Hi! I'm Carlos, from Blink Shell. Blink uses libssh2 under the hood as a full shell and to open connections for Mosh. Thanks a lot for your hard work!

We need this for blinksh/blink#60. I wanted to get on it myself in a couple weeks, but I was also considering to hire someone. So if someone is up to the task, or knows someone, please ping me on Twitter @BlinkShell.

Thanks!

from libssh2.

@topilski My ECDSA key work was recently landed which opens the door for a PR for ED25519 support. However, I don't have an ETA at the moment do to my distinct lack of time. I will try and make some time in the coming weeks to start on a PR for it, but the changes are involved so it may take a little while.

from libssh2.

OpenSSH is not thread safe and porting their code to libssh2 is rough. You could look at BoringSSLs implementation, but it makes heavy use of custom data types as it's based on OpenSSL. This is also worth looking at as it's straight C: https://github.com/orlp/ed25519

from libssh2.

Any news? i have a lot of clients who waiting Ed25519 support.

from libssh2.

@yar05, yes it's on master. I suppose we should close this bug. 🙂

from libssh2.

Feel free to send us patches!

from libssh2.

Has there been any progress or plans on this since this issue was submitted?

I can try taking a look at this if you want, even though I don't really have any experience in cryptography.

from libssh2.

Please go ahead. I figure there should be existing code in OpenSSH and elsewhere to use to test against and to get inspiration from (or even plain borrowed if the license allows it).

from libssh2.

Unfortunately OpenSSL doesn't include ED25519 so we'd have to roll our own. I've looked at porting the logic from other libraries and it's non-trivial due to heavy use of custom data types and logic. The cleanest port would probably come from libssh if you're willing to take a crack at it (license allowing).

from libssh2.

libssh uses the LGPLv2 license so we cannot just use their code, we'd need to get their (the copyright holders') permission to re- license the code to a BSD license. OpenSSH is probably more suitably licensed...

from libssh2.

This might be worth looking at: https://ed25519.cr.yp.to/python/ed25519.py

from libssh2.

Also, forgot to mention. If any of the contributors of libssh2 wants to try Blink (and don't want to build it), just hit me up on Twitter @BlinkShell and I will get you rolling :)

from libssh2.

• Upgrade SSH keys Ed25519 https://blog.g3rt.nl/upgrade-your-ssh-keys.html

• -o
  Causes ssh-keygen to save private keys using the new OpenSSH format
  rather than the more compatible PEM format. The new format has
  increased resistance to brute-force password cracking but is not
  supported by versions of OpenSSH prior to 6.5. Ed25519 keys always
  use the new private key format.

  -----BEGIN OPENSSH PRIVATE KEY-----
  …
  -----END OPENSSH PRIVATE KEY-----
  
  
  -----BEGIN RSA PRIVATE KEY-----
  …
  -----END RSA PRIVATE KEY-----
  
  -----BEGIN EC PRIVATE KEY-----
  …
  -----BEGIN EC PRIVATE KEY-----
  

• Old encrypted keys have a short header that identifies them and the encryption algorithm used

from libssh2.

As @willco007 said, BoringSSL has ED25519-related algorithms. Do you think introducing BoringSSL as a dependency is a good idea? I implemented a partial patch for ED25519 private key support at https://github.com/yan12125/libssh2/tree/boringssl-ed25519. I've succcessfully used my fork to pull and push to some git repositories with my ED25519 private key.

There are a few limitations:

• Pass phrases are not supported yet. Because I don't use pass phrases so I skipped it. I guess it won't be too hard.
• Only file-based key paris are supported. Similarly, I don't know how in-memory keys should be organized.
• Only the CMake build system is supported. CMake is easier for me; autotools are aliens :(

Also, as I have little experience on implementing security-related softwares, beware that my patch may contain vulnerabilities.

For users on Arch, you can install my AUR package https://aur.archlinux.org/packages/libssh2-boringssl-ed25519-git/ to replace the official libssh2 package.

from libssh2.

Good news, so I have this implemented on my private fork. I'm using BoringSSL's curve implementation plus OpenBSDs bcrypt pbkdf related files; both of whose licenses are compatible with libssh2. I also implemented the new OpenSSH key file format parsing which is required for ed25519 key support.

Using the BoringSSL files currently relies on the OpenSSL backend. Looking at the source, it looks like it could be easily ported away from the hand full of OpenSSL specific functions (sha and rand), but I have little interest in doing that work. At the moment; I can't even guarantee my work will build using other crypto backends, yet alone not crash, so I'm not sure how we'd like to proceed. Any thoughts?

from libssh2.

Also, thanks to @yan12125 for the head-start on full ed25519 support; it was a great jumping off point. :)

from libssh2.

@willco007 That's great! On the other hand, OpenSSL has started a series of work for Ed25519 support: https://github.com/openssl/openssl/pulls?q=is%3Apr+ed25519+is%3Aclosed. A wild guess is OpenSSL 1.2 or 1.3 will see Ed25519 support :)

from libssh2.

@yan12125, of course OpenSSL would finally get working on this. :) The last I had read is it wouldn't make a release until fall 2017/spring 2018 at the earliest (that was a while back . If we keep the backend Boring based, it could be used with different crypto back ends if someone wants to do the work of updating it.

from libssh2.

@willco007 will you be submitting a PR of your ecdsa work?

What brought me here was the inability to connect to a Synology NAS with Guacamole. This thread led me here: https://lists.apache.org/thread.html/fe89f9a6221eb11f0735f1f981f7c5114500065e2d3e0e85aff393a6@%3Cuser.guacamole.apache.org%3E

from libssh2.

The ecdsa work is already on a pending PR. Once that is landed by someone other than me I'll work on a PR for 25519 support.

from libssh2.

Still waiting on someone to land the ECDSA work; which is holding up the ED25519 work.

from libssh2.

Maybe you have some deadlines for this issue?

from libssh2.

It's moving forward! :D
#248 (comment)

And support has landed in OpenSSL!
https://www.openssl.org/blog/blog/2018/09/11/release111/

from libssh2.

So openssl supports now ed25519, does libssh2 ? Would compiling libssh2 master branch give support to ed22519 ?

from libssh2.

w00t w00t ! Perfect, just compiled and it works ! Brilliant.

from libssh2.