Re: Authenticated cipher modes

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

On Thu, 21 Apr 2005, Henrick Hellström wrote:

[ Using counters as nonces in authenticated ciphers ]

> I'd say that is not a good idea. The best way is to use random per packet 
> nonces sent explicitly by the sender, and process the sequence number as 
> implicit unencrypted header data. This operation is supported by Helix, CCM 
> and EAX. (OCB doesn't support processing of unencrypted header data, but is 
> designed for nonces that are sequence numbers).

As far as I can see, CCM and EAX aren't interesting, since they're no 
cheaper than using a separate block cipher and MAC.  That suggests that we 
should be concentrating on OCB and Helix at present, which appear to have 
rather different requirements from one another.

> I am not sure exactly how you would implement your solution, but there are 
> two things to keep in mind:
>
> * There are differential attacks against Helix that exploit repeated nonces. 
> Given the nature of differential attacks and how the nonce is processed by 
> Helix, I guess the only safe way to prevent them would be to use 
> independently random nonces. Simply incrementing the nonce by one for each 
> packet would result in nonces with a pair-wise low hamming difference. That 
> gives me chills rather than a warm fuzzy feeling.

Having read Muller's FSE2004 paper, I agree -- feeding related nonces to 
Helix looks like being a bad idea, though this is obviously not a problem 
for OCB.

Thus, I think we have two situations:

For OCB, the nonce can be a counter (initialised by the IV from KEX), and 
the SSH sequence number need not be directly handled by OCB at all.

For Helix, the nonce needs to be effectively random.  I see two obvious 
ways of achieving this:

1: Generate a random nonce for each message and send it with the nonce.
   This adds extra data to each packet, but is probably relatively cheap.
   It requires that the SSH sequence number be processed as header data by
   Helix.

2: Feed a counter through a one-way function (either a block cipher or a
   hash) to generate the nonce.  This is more expensive (at least if you
   use a hash), but saves on network traffic and means that the sequence
   number is implicit in the nonce so that it need not be processed by
   Helix (though it may as well be, since doing so is cheap).

--
Ben Harris