Re: Encrypted and authenticated(?) packet lengths (was: Re: Terrapin)

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> IIRC, EtM MACs went in to eliminate use of the timing of error
>> replies as a crypto oracle.  [...]
> I'm not really sure what the implications are of this attack.  If
> using ctr mode, attacker can flip any desired bit of the length
> field, and to me it seems the result will be rather predictable.  If
> using some mechanism that mixes the bits more, e.g., old fashioned
> cbc, any bit flip will change the length field in a random looking
> way.  Assuming the implementation's max size is about 2^15, with
> probability about 2^{-17}, result is still a valid length, and with
> probability 1 - 2^{-17}, length will look invalid, and receiver might
> disconnect immediately.

Essentially, yes: it uses the timing of the disconnect (and in some
cases detailed disconnect behaviour) as an oracle for whether the
decrypted length field is valid.  Here's the relevant comment from
moussh's code:

/*
 * Handle input at the lowest layer.  This gets called by net_read()
 *  (through the BPP's input pointer) upon receiving data from the
 *  connection.
 *
 * Mostly unremarkable, but fakepkt() calls for some note.  The cases
 *  that call fakepkt() used to just abort_bpp() and exit.  But that
 *  exposes a protocol weakness which uses that, in conjunction with
 *  certain cipher modes - most obviously, the CBC ones - as an oracle
 *  for the correctness of guesses about ciphertext.  (This essentially
 *  amounts to using the high bits of the packet length as a
 *  known-to-be-0 crib.)  It's not a very practical weakness, but it's
 *  easy to close: if the packet length is invalid, we pick a random
 *  valid packet length instead and use that.  Rather than depending on
 *  the MAC to error out in this case (what if MAC "none" was
 *  negotiated?), we switch the BPP to macalg_fail, which _always_
 *  errors.  See SandPfinal.pdf in ../doc/ (which came from
 *  http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf and may still be there
 *  for all I know), for more about the attack in question.
 */

(In passing, I'm now unsure what moussh does in switching to an
always-fail MAC is a good idea.  If MAC `none' was negotiated, this
opens up a different potential oracle; perhaps I should switch iff MAC
`none' was not negotiated.)

SandPfinal.pdf isn't there now; fetching the URL in the comment returns
a redirect to HTTPS, which I'd have to use a work machine to fetch.  If
there's nothing at the redirected-to place, I can mail copies, or put
it up for fetching from my systems, or you can get it by cloning
git://git.rodents-montreal.org/moussh and reading doc/SandPfinal.pdf.

The attack applies mostly (entirely, I think) to CBC crypto modes; the
reduced popularity of CBC modes is one reason I consider it a
relatively weak attack in practice.  As the paper says, "[e]ven if our
attacks do not lead to reliable recovery of complete plaintext blocks,
have low probabilities, and consume large numbers of SSH connections in
their iterated forms, they do stand in stark contrast to the intended
outcome of using strong cryptography".

Another reason I consider it a relatively weak attack is that can
easily, unilaterally, and compatibly be defeated by, as my comment
remarks, replacing any invalid length field with a random valid length
field; this is mentioned (attributed to Denis Bider) in the third
paragraph of section 6 of the paper.  Not using CBC - or more generally
packet-chaining modes - also defeats it; stream ciphers (including
block ciphers run in counter mode) are examples.

There also is a footnote saying "Note that since the attacker cannot
necessarily detect where one BPP packet ends and the next begins, there
is a chance that this injected block is not processed as the first
block of a new packet.  This is not usually an issue in practice
bceause the attacker can wait until the SSH connection is quiet before
beginning his attack.".  Thus, it is made more difficult by anything
which obscures BPP packet boundaries.  Generating an IGNORE packet, and
sending only a random initial substring of them it, the connection is
idle would give this attack a lower success chance - the attacker would
have to guess at BPP packet boundaries.  That's a change I've wanted to
make to moussh for quite a while, but the way its internal output
queueing works makes it somewhat difficult.

> It seems the robust way to protect the length field would be to give
> it its own MAC.

Assuming it's checked as soon as the full length+MAC is available, that
would affect SandP in ways I can't analyze with only a few minutes'
thought.  It makes erroneous length fields error much sooner, but
reduces the information obtained from them.  The paper mentions this
but does not go into any detail on how it would affect their attack:

	Another approach, suggested by a referee, would be to include
	an extra MAC, calcuated on the length field, just after that
	field in the BPP protocol format.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B