RE: Binary packet protocol rethink

[Simon Tatham <anakin%pobox.com@localhost>]

Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost> wrote:
> Why? The length just tells you how much to decrypt in one block, what
> you put inside it is up to you. At a lower level, the TCP headers
> already give length information, and if you can deal with that then
> you can just as easily deal with plaintext lengths.

Exactly.

And, at the same time, it's precisely the encrypting of the 'how much to
decrypt' length field which gives rise to all the previous protocol
flaws: an attacker either guesses the true length by correlating to the
TCP headers, or probes it by means of the byte-at-a-time dribbling
attack, or actively corrupts the cipher block containing the length and
waits to see when the resulting MAC failure is reported, and all of
those attacks (unless carefully defended against) give rise to some kind
of data you can use to attack the underlying cipher, like a (plaintext,
ciphertext) pair, or a partial XOR of a plaintext block and the previous
block in the CBC stream, or whatever.

So it simplifies matters enormously if you just don't try: accept that
the enemy _will_ be able to know the lengths of your encrypted blocks.
Then you can send them in clear to avoid all of those subtle
implementation goofs in trying to hide them, and instead, dedicate your
effort to arranging that it _doesn't matter_ if the enemy knows those
lengths, by making sure that the encrypted block boundaries do not also
reveal the length or position of any actually important data, such as a
particular SSH_MSG_anything. Hence, my original suggestion of separating
the two conceptual halves of the current monolithic BPP.

But it's looking so far as if there's not enough interest to pursue it.
Ah well.

Cheers,
Simon

-- 
for k in [pow(x,37,0x1a1298d262b49c895d47f) for x in [0x50deb914257022de7fff,
0x213558f2215127d5a2d1, 0x90c99e86d08b91218630, 0x109f3d0cfbf640c0beee7,
0xc83e01379a5fbec5fdd1, 0x19d3d70a8d567e388600e, 0x534e2f6e8a4a33155123]]:
 print "".join([chr(32+3*((k>>x)&1))for x in range(79)]) # <anakin%pobox.com@localhost>