RE: Binary packet protocol rethink
Simon Tatham <[email protected]>
| Newsgroups | gmane.ietf.secsh |
|---|---|
| Message-ID | <[email protected]> |
Peter Gutmann <[email protected]> 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)]) # <[email protected]>