Re: Authenticated cipher modes

[Ben Harris <bjh21%bjh21.me.uk@localhost>]

In article <42637455.9060703%streamsec.se@localhost> you write:
>While trying to figure out how to support CCM, EAX and OCB cipher modes 
>or the Helix cipher (http://www.schneier.com/paper-helix.pdf), I spotted 
>an issue with SSH-TRANS. These cipher modes have built in data 
>integrity, but the SSH-TRANS algorithm negotiation mechanism clearly 
>isn't designed to handle such encryption.

I'd noticed this too, and was planning to address it once I'd got my current
SSH projects out of the way.  I'm glad to see that someone else is working
on it.

>1. If the server and the client negotiate this encryption, they MUST 
>also negotiate a designated data integrity name, which is specified to 
>be coupled with the encryption in question. There is no point in adding 
>a second layer of data integrity to e.g. Helix encryption. This is 
>unfortunately not consistent with the algorithm selection mechanism 
>specified in section 7.1 of SSH-TRANS.

My feeling about this is that the simplest way is to have the definition of
helix%streamsec.com@localhost and friends include a rule like this:

  If the negotiated cipher algorithm for a direction is helix%streamsec.com@localhost,
  the negotiated MAC algorithm for that direction shall be ignored and the
  integrity protection provided by Helix be used instead.

Note that this _isn't_ the same as just using Helix for the MAC, since the
MAC and encryption keys in SSH are usually different.

>2. The processing rules of section 6.4 "Data integrity" of SSH-TRANS 
>MUST be integrated into the encryption processing, if e.g. Helix 
>encryption is selected. That is, the message counter should be processed 
>by the encryption as unencrypted header data, in accordance with the 
>Helix specification. (One should note that CCM mode is less of an issue 
>in this respect, since an implicit message counter is part of the mode 
>itself. Selecting CCM mode and the "none" data integrity algorithm would 
>result in the desired state.)

My understanding was that the nonce in Helix and OCB had the same purpose as
the sequence number in the usual SSH MAC, so as to make the latter
technically unnecessary if using those modes.  It doesn't really matter, of
course, since feeding an extra four bytes into the MAC is hardly going to
kill performance.

-- 
Ben Harris