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"



>> [...decoupling wire data reads from decryption...]
> Of course, that introduces some interesting buffering requirements to
> allow a NEWKEYS message to result in a pipeline flush, but it
> shouldn't be unreasonable.

Or, rather, a pipeline back-up-and-reprocess. :-/

> Hrm, except the MAC is unencrypted, so they can't be completely
> decoupled.

That's true.  Hm, I wonder how I dealt with that in moussh; when I read
the packet reading code for an upthread message, they sure looked
pretty decoupled.

*rummage*  *read*

Ah.  My downcall to the cryptosystem implementation has semantics that
amount to "here's a buffer of input ciphertext, a ciphertext amount, a
buffer for cleartext, and a maximum amount of cleartext I want; if I'm
providing excess ciphertext, don't consume more than is necessary to
provide all the cleartext I'm asking for", addressing both the MAC
issue and the NEWKEYS issue.

> Interestingly, if we can agree that using plaintext lengths does
> _not_ require changing the way the size of the padding field is
> determined, then it becomes possible for an encryption algorithm to
> use plaintext lengths without changing the base protocol, the
> modularity argument goes away, and the need to enable negotiation of
> cleartext lengths independently of the encryption algorithm becomes
> less pressing (but possibly still desirable).

Agreed on all counts.

> It does mean that if we do both, we need to point out that
> implementations which support both such an algorithm and
> algorithm-independnet cleartext lengths not inadvertently send both
> the length and the _next_ 4 bytes in plaintext. :-)

Right - they may well end up sending the length (in the clear) twice if
they get careless, but I don't see any need to make it impossible to
negotiate wasteful combinations of settings.

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



Home | Main Index | Thread Index | Old Index