IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



--On Wednesday, April 08, 2009 07:28:45 PM -0400 der Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
[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.)
I read that paragraph as normative, and having the effect that SSH cannot 
operate with ciphers having a block size of 3, 5, 6, or 7 bytes.  If you 
really wanted to use such a cipher, the document describing its use with 
SSH would have to artificially increase the "block size" to something 
larger than 8 bytes.
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.
OK, I'll grant that it's not necessary when using a stream cipher, or a 
block cipher with a block size of 1, 2, or 4 bytes.  But I don't think 
there are any of the latter.
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.)
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.
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.  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.






Home | Main Index | Thread Index | Old Index