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

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

>> [F]rom what I've gathered from the list, this could, as far as the
>> core protocol is concerned, be seen as an encryption algorithm that
>> happens to produce ciphertext identical to the plaintext for certain
>> parts of the data stream.
> I wouldn't have a problem with that, but it's not actually the case.
> The base protocol spec assumes that encryption algorithms have a
> block size, and requires that the amount of padding be chosen such
> that the combined size of the length, padding length, padding, and
> payload be a multiple of the block size.

Right - with an artificial block size imposed for stream ciphers.
(Actually, the wording in RFC4253 is not very good; consider what an
implementer reading the "Note that the..." paragraph beginning ten or
so lines into page 8 would do with a cipher using 7-byte blocks.)

> Moving the length out of the encrypted part requires changing this
> behavior.

Why?  As far as I can see, this is so only if (a) the underlying cipher
has a block size that's not a divisor of 4 bytes and (b) you insist on
naïvely treating all the sent-encrypted data as a single data stream
for the encryption engine.

It would be very easy, for example, to use arcfour (or any other stream
cipher) to encrypt all but the length.  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.)

/~\ 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