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.

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.

So I managed to, as a proof-of-concept, replace curve25519-sha256@libssh.org 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

Yes!

Also, thanks.

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 127.0.0.1 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.