IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Albrecht/Paterson/Watson's attack
Simon Tatham <anakin%pobox.com@localhost> writes:
> (a) the subject of the whole paper, i.e. an attack on the encryption
> which involves substituting an initial cipher block and inferring
> from the subsequent failure mode some information about the
> length field to which it decrypted. Putting the length field in
> cleartext rather than in the first cipher block defeats this
> attack.
If you said that the attacker can infer information about the initial
cleartext, *after* the length field, then a cleartext length field might
be an improvement. I imagine that attacks like that might be possible
with CBC mode, but is seems highly unlikely if using something like
aes-ctr or salsa20.
But if the problem is leaking information about the length field itself,
a change to instead send that information totally in the clear cannot be
an improvement.
To adress leaking of length info to active attackers, one would need a
redesign where information about the length never reveals anything
sensitive, a bit like what you sketched.
I guess I ought to read the paper myself, but I don't have the time to
do that right away.
> Option (3), encrypting the packet length and MACing it separately,
> defeats both types of attack as far as I can see.
Given the close connection between ssh transport packets and packets for
the userauth and connection protocols, I think it's desirable to encrypt
the length (and in general, try to hide message boundaries).
But an additional MAC gives a significant additional overhead. Maybe one
could get away with a short MAC for the first block (including the
length), provided that the MAC at the end of the cryptotext covers the
complete message?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
Home |
Main Index |
Thread Index |
Old Index