Re: SSH v3?
denis bider <[email protected]>
| Newsgroups | gmane.ietf.secsh |
|---|---|
| Message-ID | <[email protected]> |
Just going briefly through the EST spec, the way I left it last year, I notice several things I would prefer to change: - I am no longer as much adverse against IETF standardization, as long as someone else beside me is willing to jump through the hoops. - I have a better variable-length integer encoding format now, which I would prefer to use instead of the one presented. - It might be necessary to change EST_HASH to use the full 32 bytes of the HMAC-SHA2-256 construction, instead of just the first 20 bytes. - In the private key format, I'd replace PBKDF2 with Argon2, recent winner of the password hashing competition: https://password-hashing.net/ - Folks here would probably want to standardize "eddsa" instead of ECDSA over secp256k1. - Then again, folks who need to support FIPS would prefer ECDSA. Free high quality implementations of secp256k1 are available: https://github.com/bitcoin/secp256k1 There are probably other tweaks I would make. Currently, the spec is posted as-is, the way I left it before I shelved it. Comments welcome, if you guys want to do this. denis bider <[email protected]> , 12/1/2015 10:01 AM: Very much agreed. Here's my wish: SSHv3 is based on UDP, not TCP. I actually have a whole spec for that ready-made, which includes things like negotiating encryption + authentication as one thing... Heck, if you guys want to work on that, here's the spec: https://www.bitvise.com/files/EfficientSecureTransport.pdf The initial defined algorithms are kinda arbitrary and trivial to substitute. I was going to put in Ed25519 and AES GCM, but I didn't have access to that at the time, so I put in something I had access to. I actually have a platform-independent C++ implementation, too.... Complete, just never tested. Do you guys want to work on this? ----- Original Message ----- From: Damien Miller Sent: Sunday, November 29, 2015 05:48 To: Simon Tatham Cc: Niels Möller ; Simon Josefsson ; [email protected] Subject: Re: Binary packet protocol rethink (was: Re: ChaCha20-Poly1305 for SSH) While we're dropping wishlist items for SSH v.3, here's one of mine: Key exchange negotiates an AEAD rather than a cipher and a MAC separately, and does so from a greatly trimmed set of options. E.g. AES-GCM, chacha20+poly1305 and an AES-CTR+HMAC mode. IMO the AEAD primitive is the right metaphor for the security properties of the SSH transport protocol. Removing the large cartesian product of ciphers x MACs will make testing faster and binaries smaller too. -d