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

[Niels Möller <nisse%lysator.liu.se@localhost>]

Mouse <mouse%Rodents-Montreal.ORG@localhost> writes:

> IIRC, EtM MACs went in to eliminate use of the timing of error replies
> as a crypto oracle.  That is a weaker attack than this one, though, and
> furthermore it can be defeated - unilaterally - by the implementation
> replacing any unacceptable packet length with a random acceptable
> packet length.  Is there any other need for EtM?

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.

It appears rather subtle to exploit this practically, are there any
references that explain how severe that is?

It seems the robust way to protect the length field would be to give it
its own MAC. Like, read a fixed size AEAD-encrypted packet length, then
use that length to read the AEAD-encrypted packet payload. Which
obviously adds singificant overhead on the wire for small packets.

Depending on the analysis of the implications of the attacker modifying
the length bits, maybe a short MAC is sufficient? Say we prefix each
encrypted binary packet with k octets of a truncated hmac-sha256 of the
4 length bytes, with k maybe 4 or 8 rather than the 32 octets of a full
hmac-sha256. (I've not followed recent developments of TLS, is TLS
attempting to add any encryption of its packet headers?)

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.