Pure-Rust asynchronous SSH library, both client and server

#71 Bring back NIST P-256 as feature

Opened by Harrycane on February 17, 2022
Harrycane on February 17, 2022

Hi, I hope this request isn’t too out of question.

I have a device that uses OpenSSH 6.0 and as such will not be able to utilize the curve25519-sha256@libssh.org key exchange. However, as documented in the source code:

// We used to support curve "NIST P-256" here, but the security of
// that curve is controversial, see 
// http://safecurves.cr.yp.to/rigid.html

NIST P-256 was once available in the crate(?) and it’s also available in OpenSSH 6.0. Is it possible to bring back support for NIST P-256? If only as a specific feature.

Sadly, updating the device is not an option, at the moment I’m just looking for alternatives.

pmeunier on February 17, 2022

Yes, if feature-gated, this could indeed be a possibility. If you want to contribute the feature, I’m open to reviewing and merging it.

Harrycane on March 1, 2022

So I managed to, as a proof-of-concept, replace [email protected] with NIST P-256 using this crate and then ran into the following problem:

Could not find common key algorithm, other side only supports Ok(“ssh-rsa,ssh-dss,ecdsa-sha2-nistp256”), we only support [Name(“ssh-ed25519”)]

This was solved easily enough by enabling openssl feature and adding ssh-rsa as acceptable key algorithm. This was not the end however as I then ran into this problem:

Could not find common cipher, other side only supports Ok(“aes128-ctr,aes192-ctr,aes256-ctr”), we only support [Name(“chacha20-poly1305@openssh.com”)]

So my question now is: would you be open to adding feature-gated support for aes128-ctr?

This would make the crate compatible with OpenSSH 6.0

pmeunier on March 1, 2022


Also, thanks.

ta32 on April 28, 2022

Hi I think this will also make it compatible for libssh clients. I got the following error in the trace.

Ok(“aes128-ctr,aes192-ctr,aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-cbc,aes128-cbc,blowfish-cbc,arcfour128,arcfour,cast128-cbc,3des-cbc”), we only support [Name(“chacha20-poly1305@openssh.com”)]

I had a go at adding support for aes-256-cbc and it not as simple as I thought. I get the following error ( I forced my openssh client to use that cipher )

“Unable to negotiate with port 22: no matching MAC found. Their offer: none”

I think this is because this cipher is not a AEAD cipher - so the SSH protocol is expecting a MAC to implement authentication.