Re: Authenticated cipher modes

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

In article <000001c5443b$88312ad0$d7b7fea9@devel.testdomain> you write:
>[Ben Harris]
>
>> 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.
>
>The problem is that a higher-level layer can rely on the SSH sequence number
>- for example, it is used in SSH_MSG_UNIMPLEMENTED, so it must be there and
>must be authenticated, or replaced by something 100% equivalent. Therefore
>any Helix-in-SSH draft needs to spell out what happens to the SSH sequence
>number:

The obvious approach is that it effectively becomes part of the nonce.  To
avoid too much wheel-reinvention, I'd make the nonce the same as the counter
used by newmodes, so you could extract the sequence number by:

seq(pkt) = nonce(pkt) - nonce(NEWKEYS) + seq(NEWKEYS)

(where seq(x) is the sequence number of packet x, nonce(x) is the nonce of
packet x (as an integer), and NEWKEYS is the SSH_MSG_NEWKEYS packet that
started the use of this key.  nonce(NEWKEYS) is the IV generated by the KEX
algorithm.)

Of course, you wouldn't actually do that -- you'd just keep a counter the
same way you do now and increment it when you received a packet MAC'ed with
the next nonce in sequence.

I'm still not entirely sure that this is safe, or that all
authenticated-encryption modes have this kind of nonce, but then I'm also
not sure they all have the facility to MAC data without also encrypting them.

-- 
Ben Harris