Re: Albrecht/Paterson/Watson's attack

> One thing that SSH would then need to do is to stop encrypting the
> header (that is, the length information) so you can run the MAC over
> the packet without having to pick apart bits of it via decryption
> first,

This is actually not quite true.  It would need to do so to implement
EtM as outlined in the descriptions I've found, but I see no particular
reason to slavishly follow them.  There's no reason you can't encrypt
the whole thing, including the length, but then MAC the resulting
ciphertext.  You have to decrypt a little before you can tell how much
to run the MAC over, but that's hardly a big deal.

Personally, if I were worried about such things, I would probably MAC
the cleartext, MAC the ciphertext, and append both MACs to the
encrypted packet.  I might even encrypt the cleartext's MAC along with
the payload before running the ciphertext MAC.

> If you still need to run crypto ops before you can verify the MAC
> you're not actually doing EtM, or at least not getting the security
> benefits that it provides.

What benefits _does_ it provide?  Why do they outweigh exposing packet
sizes?

It seems to me that the Bellare/Namprempre paper has a number of
weaknesses for our purposes[%], mostly amounting to mismatches between
its assumptions and the world of SSH.  In particular, the only
arguments I see against E&M, such as SSH uses, are based on the MAC
leaking information about its input.

It would be nice to use a construct that has some kind of proof of its
security - other things being equal.  Here, they are not; using their
EtM construction demands exposing information the current paradigm does
not expose.  Furthermore, the only flaws I see described in the current
construction are based on assuming weaknesses in the underlying
algorithms.

But I recognize your name enough to know you're not stupid.  This leads
me to expect I'm missing something important.

What?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

[%] For example, it appears to assume that message lengths are
    unprotected in all variants; as I understand it, that's one of the
    main arguments against EtM for SSH.  The paper also does not
    consider different types of brokenness different, such as
    implementation bugs that can break an algorithm in some ways but
    not others - an example is the "what if the key is corrupted"
    spectre which has been invoked as justification for choosing E&M.
    (Any paper whose results depend on implementations being bug-free
    needs a very careful read-over before it can be considered to apply
    to real software.)  It also considers possibilities such as a MAC
    leaking information about the data it is applied to.