IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
AEAD in SSH: Toss block alignment requirements
Hey everyone,
while implementing the "fixed-bandwidth" proposal, I realize we ought to get rid of block alignment requirements.
Using AES-CTR and hmac-sha2-256, it's straightforward to pad outgoing packets to some aligned size, e.g. 1024 bytes, using the following construction:
SSH_MSG_CHANNEL_DATA ciphertext - 16-byte aligned
SSH_MSG_CHANNEL_DATA mac - 32 bytes
SSH_MSG_IGNORE ciphertext - 16-byte aligned
SSH_MSG_IGNORE mac - 32 bytes
All lengths are 16-byte aligned, so we can always target an aligned total size.
If we try to do the same with hmac-sha1, there's a problem. But hmac-sha1 is deprecated, so maybe that's not an issue.
But with AEAD, we run into the issue again:
SSH_MSG_CHANNEL_DATA length - 4 bytes
SSH_MSG_CHANNEL_DATA ciphertext - 16-byte aligned
SSH_MSG_CHANNEL_DATA tag - 16 bytes
SSH_MSG_IGNORE length - 4 bytes
SSH_MSG_IGNORE ciphertext - 16-byte aligned
SSH_MSG_IGNORE tag - 16 bytes
The result isn't 16-byte aligned. This means we can't target a consistent total size, unless we ALWAYS add an SSH_MSG_IGNORE packet.
But there is no actual reason to have block size alignment with AEAD - or even CTR.
I propose the following:
- For inclusion in Niels's draft with AEAD guidelines, discourage or prohibit unneeded block alignment for packet receivers.
Optionally, we COULD also deprecate compulsory alignment for existing modes that don't need it, i.e. CTR. However, there is currently no recommended CTR + MAC combination where this would be a problem, since all plausible non-deprecated MACs are 16-byte aligned.
denis
Home |
Main Index |
Thread Index |
Old Index