Subject: RE: AEAD in ssh

From: Peter Gutmann <[email-masked]>
Date: Thu, 25 Feb 2016 04:17:40 +0000

denis bider <[email-masked]> writes:

>I'm tempted to implement fixed-bandwidth SSH_MSG_IGNORE padding, just so I 
>can point to an existing client and server which thwart traffic analysis, 
>and need encrypted lengths.

You'd need to point to actual analysis (of the kind done in Peek-a-boo) to
show that it works.  That's the problem with SSH's encrypted lengths, twenty
years ago Tatu decided it was a good idea to use CRC32 as an ICV, RC4 as a
cipher, and encrypted lengths.  Since then we've had attacks on CRC32, RC4,
and encrypted lengths.  The response was to drop CRC32, drop RC4, and keep 
using encrypted lengths even though the only thing they've demonstrably given
us so far is security vulnerabilities.

The current discussion with AEAD is trying to perpetuate this cargo-cult 
protocol design with increasingly awkward Rube-Goldberg hacks to try and 
keep using something that was probably a mistake to begin with.  Sure, it 
was a well-intentioned mistake, but it doesn't do what people think it does 
while at the same time creating real security vulnerabilities.

>If my implementation consistently sends one ethernet frame (say 1450 bytes) 
>every 10 ms, this defeats traffic analysis at a cost of ~ 1.1 Mbps of fixed 
>bandwidth.

So maybe we could do a profile for a special allegedly traffic-analysis 
resistant SSH, let's called it Data-oriented SSH or DoSSH, where you flood a 
network link with unnecessary traffic.  So if you wanted to DoSSH someone's
network you'd use that version, and everyone else could use standard SSH.

Peter.

---

From: denis bider <[email-masked]>
Date: Wed, 24 Feb 2016 21:52:34 +0000

Peter - see bottom.

Niels:

> What do you think of the way it is specified in the draft?
> Which is well defined for an arbitrary AEAD, but boils
> down to plain CTR mode for typical AEAD block cipher
> modes, and boils down to plain cacha encryption
> for chacha-poly1305?

I think the intent is good, but the description is overly clever. You seem to recognize this:

"For many AEAD algorithms, this seemingly complex procedure boils down to ..."

Also, the described mechanism does not boil down exactly to CTR mode. The counter is initialized differently. It seems to me plain CTR would be better.

It might be better to just ditch the complex description, and specify a separately-keyed instance of the underlying stream cipher. This might be either the cipher itself for ChaCha20; or a block cipher in CTR mode in the case of AES.

> should lengths conceptually be packed back to back into
> a stream to be encrypted four bytes at a time [...],
> or should we use one underlying "block" per message? 

One underlying block per packet is slightly simpler with a block cipher.

Back-to-back is more efficient - +0.25 or fewer additional block transformations per packet, instead of +1.

I'm not sure that either option is problematic in terms of a timing side channel. A decent fixed-bandwidth implementation would be sending a fixed amount of data on a fixed timer.

Back-to-back would make most sense with a stream cipher. It seems consistent to use the same with a block cipher in CTR mode.

Peter:

> encrypting the length provides no security benefit at all.
> See for example "Peek-a-Book, I Still See You: Why Efficient
> Traffic Analysis Countermeasures Fail" by Dyer, Coult,
> Ristenpart and Shrimpton.

This paper points out an inherent tradeoff between efficiency and pattern hiding. It says nothing about when efficiency does not matter, because you can maintain a fixed bandwidth.

The problem with plaintext lengths is that they don't just defeat efficient countermeasures. They defeat ALL countermeasures to traffic analysis.

In a time of always-on TV streaming, it's increasingly conceivable to maintain a fixed bandwidth for not only 10 second bursts, but for the entire connection.

I'm tempted to implement fixed-bandwidth SSH_MSG_IGNORE padding, just so I can point to an existing client and server which thwart traffic analysis, and need encrypted lengths.

I can then point to AES-GCM in our help text, and say: "This algorithm is not resistant to traffic analysis. It is counter-productive to enable it in conjunction with fixed-bandwidth connection padding."