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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.