RE: AEAD in ssh

[email protected] <[email protected]> writes:

>That said, the paper does raise questions about how to effeciently use such
>counermeasures and requires a bit more thinking on my part.

It was a real eye-opener, it points out that the simplistic mechanism built
into both TLS and SSH for (attempting to) defeat traffic analysis pretty much
doesn't work.  There's been a bit of earlier work in this area (the work on
Bayesian classifiers, notably used by the Tor folks) but this is a 2nd-gen
study that looks at how to defeat countermeasures that that initial 1st-gen
work inspired.

I agree that there may be issues of applicability to SSH, but a bigger
question is the usual WYTM (what's your threat model), you need to figure out
what you're trying to defend against in order to evaluate your defences.  It'd
be nice to have some rigorous model like the random oracle model or standard
model in crypto.  The pad-the-packets approach doesn't really have any threat
model except that it seems like a good thing to do, what they've pointed out
is that it's ineffective against traffic classifiers.  Hopefully there'll be
more work on this in the future (although the previous papers were from 5-10
years ago)...

The tl;dr version, from a comment in my code:

  Padding in order to defeat traffic analysis is extremely problematic.  The
  simplistic approach of adding random padding provides little more than warm
  fuzzies since it falls almost trivially to statistical classifiers like
  Bayesian or support vector machines.  In fact almost any attempt to defeat
  traffic analysis with low overhead, including random padding, linear padding
  (padding to the nearest 128 bytes), exponential padding (padding to the
  nearest power of two), mice/elephant padding (padding short packets to 128
  bytes and long ones to the MTU), straight padding to the MTU, and padding by
  a random multiple of 8 or 16 bytes, doesn't work (see "Peek-a-Book, I Still
  See You: Why Efficient Traffic Analysis Countermeasures Fail" by Dyer,
  Coult, Ristenpart and Shrimpton).

  It's only when quite complex traffic morphing, sending fixed-length packets
  at fixed intervals and the like, is applied and reaches an overhead of 400%
  that things start getting tricky for an attacker, or at least an attacker
  using a straightforward Bayesian or SVM classifier.

  This doesn't leave much choice in the way of padding, since no matter what
  we do it won't be terribly effective.  The best option is to choose the
  variant with the lowest overhead and use that, since it has at least a small
  amount of effect.  This is linear padding, but we pad to 64 bytes instead of
  128 because we're typically used in embedded environments which both use
  shorter messages and often have bandwidth constraints.

Peter.