RE: Binary packet protocol rethink (was: Re: ChaCha20-Poly1305 for SSH)

On Fri, 27 Nov 2015, Peter Gutmann wrote:

> I've asked for this in the past too.  SSL/TLS have used unencrypted lengths
> for twenty years without there being any (known) attack or weakness based on
> this.  OTOH SSH has used encrypted lengths for nearly the same period, and
> there have been several attacks/weaknesses based on that.  Security-wise, it
> has the opposite effect of the one intended, it makes the protocol weaker, not
> stronger.

There have been quite a few fingerprinting attack against websites
using object sizes, e.g. Vincent Berg's work.

> My real issue with it though is that, as you've pointed out, it makes it
> impossible to create an efficient streaming implementation.  With TLS you read
> the length at the start, stream the rest into the target memory location, and
> decrypt in place.  With SSH you have to read a single block, decrypt it, make
> sure you're not providing an oracle for the attacker, copy what's left around,
> read more encrypted data onto the end, decrypt the remainder, ugh.
> 
> I would really like to see a protocol that:
> 
> 1) Doesn't encrypt the length so you can create an efficient streaming
>    implementation.
> 
> 2) Uses encrypt-then-MAC for security rather than MAC-then-encrypt.

OpenSSH has had this for some time in our *-etm MAC modes.

https://anongit.mindrot.org/openssh.git/tree/PROTOCOL?id=b1d6b397#n54

-d