Re: applying AES-GCM to secure shell: proposed "tweak"

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Also, I just reread section 6 of 4253, and I can't find anything
>> that says the ciphertext from an encryption algorithm has to be the
>> same size as the plaintext, so you could always just save the
>> length, replace it with four random bytes, encrypt as normal, and
>> prepend the saved length.  (Decryption, of course, just throws away
>> the four random bytes.)
> I think what you're effectively suggesting here is that the transport
> layer pad to the "wrong" size (since the length is included but will
> not be encrypted), and then the encryption algorithm add extra
> "hidden" padding to pad it to the right length.

Yes, I think that's a fair rephrasing of my suggestion.

> I think that could work, but note that the number of bytes of
> ciphertext must be exactly equal to four plus the "decrypted" length
> value, since the latter is the only indication of how many bytes the
> transport layer should read out of the TCP stream.

Putting it that way reveals, perhaps, part of the problem.  There is no
particular reason why the code that reads data from the wire data
stream (usually but not necessarily TCP) has to know where packet
boundaries are.  As long as every packet boundary falls at a place such
that the data->encryption->decryption->data pipeline can deliver the
whole packet without needing more input data (which is the point of
padding to a multiple of the blocksize), the protocol can work.  This
does mean that implementations which expect to issue wire data stream
reads for exactly the right amount of data early in packet processing
will be constrained in what encryption algorithms they implement,
though as far as I know no algorithms which would make that a practical
constraint are implemented for ssh (and my suggestion above is not one,
since the encryption algorithm layer can provide the wire length early).

At the very worst, implementations may need internal rework if they
want to implement the new stuff.

> There are likely implementations which expect the "decrypted" length
> to also be the length of the plaintext packet (not counting the
> packet_length and mac), which would have to change.

> OTOH, I would expect support for AEAD-mode ciphers to make it
> necessary for the plaintext and ciphertext to be different sizes
> anyway, so this shouldn't be a major change.

Yes, there are doubtless implementations which assume that encrypted
and cleartext are the same size.  They will need internal rework if
they are to implement any of this stuff, but I don't see that as a
reason to twist the design uncomfortably; it just means implementing it
for them, if done at all, will be more work.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B