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

[nisse%lysator.liu.se@localhost (Niels Möller)]

Tim Polk <tim.polk%nist.gov@localhost> writes:

> (1) does the exposure of the ssh packet length have significant
> security implications for ssh itself?

I don't think so.

> (2) were applications that rely on ssh for security designed to take
> advantage of the encrypted packet length?

My gut feeling is that it's a good thing to be able to hide message
boundaries. I do my best to take advantage of this, and try to stick
to one or a few fix sizes of TCP segments, with the boundaries between
TCP-segments typically in the middle of the payload of an
SSH_MSG_IGNORE message.

> (3) does the change in padding length calculation (caused by excluding
> the packet_length from the ciphertext) impose a significant impediment
> to migrating existing implementations?

Supporting two different modes for the transport protocol of course
iplies some additional complexity.

My experience with handling of encrypted length fields is that it's
not very complicated, it's about the same complexity or less as the
handling of padding.

I admit that I haven't done any deep thinking of attacks based on
partial decryption. We're comparing these two processes:

1. Read first block, decrypt, get length field, read rest of message
   (if larger than one block) and mac, decrypt, check MAC. (It's of
   course imperative to not act on anything in the message beyond the
   length field until the mac is properly verified)

2. Get unencrypted length field, get rest of message, decrypt, check
   MAC.

In the first scenario, the attacker could mount the following attack:
Send a first chosen ciphertext block, then slowly send more data. Then
the attacker can then find out what the first four bytes of the
decrypted block are, by obserrving how much data it can send before
the ssh implementation in the othher end disconnects. Actually, with
high probability, it will disconnect immediately, because a length
field exceeding the maximum size is a protocol error; at least that's
how my implementation behave. So the setup is somewhat liek on oracle
telling thhe attacker whether or not the first two bytes of the
decrypted block are zero.

But since (1) this is an attack only on the session key, and (2) it
can be mounted only once per connection, I doubt the attacker can
derive any useful information (useful would meen: Sufficient to get a
little information about cleartext previously sent over the same
session). And any decent block-cipher should have reasonable resistant
also to a general chosen-ciphertext attack, right?

Are there any other relevant attacks? Anything that's specific to AEAD
(which I'm not familiar with)?

Regards,
/Niels