[onerng talk] Extra OneRNG anti-tamper feature

[Peter Gutmann]

Paul Campbell <paul at taniwha.com> writes:

>Below is the initial comment from the code I've currently written (but not
>tested) - comments would be much appreciated

You asked for it :-).

//              b) encrypt a 2 block nonce of random data 'R' (32 bytes) -> 'ER'

This is in effect acting as an IV, but in that case why not just use an IV,
and why two blocks?  In addition since you're encrypting a fresh nonce, there
isn't really any need for an IV.

//              d) encrypt (chained) the final 32:95 bytes of the region 'S'(64 bytes) -> 'ES'

What's the purpose of S?  I can't see what it contributes, or why you need 64
bytes of it.

//              e) decrypts 'ER' using 'K' giving nonce 'R' (discarded)

So this is effectively an IV again...

//              h) reencrypts 'R'+'T'+'S' using 'K' giving 'ER'+'ET'+'ES'

Is this a new IV?  The previous text says 'R' was discarded, but this implies
it's reused, in which case the encryption would be the same as what you
received.

//      8) User compares 'ES' from user's OneRNG with value that OneRNG delivered in step 5d)

If these are supposed to be the same value, couldn't someone impersonating the
server just reflect the client's data back at them?

So there's all sorts of stuff going on there that doesn't really make much
sense.  Here's a much simpler protocol that does the same thing with mutual
authentication using a single AES block.  The ID and nonce are 64-bit
quantities.

  Server                    OneRNG
  ------                    ------
   <------------ ID -------------
   ------ E( ID || nonce ) ----->
   <-- E( ID || nonce ^ 0xFF ) --

The client identifies itself, the server responds with the client ID and a
nonce (decrypting and verifying the ID proves the server knows the shared
key), the client then responds with the re-encryption of the ID + bit-flipped
nonce which proves knowledge of the shared key and demonstrates freshness. You
can replay the server message unless you include a nonce with the client ID,
but since the point is to verify the authenticity of the OneRNG via the shared
key I'm not sure what that gets you.  If it's a concern you could use:

  Server                        OneRNG
  ------                        ------
   <--------- ID || nonce1 ----------
   --- E( ID ^ nonce1 || nonce2 ) -->
   <------- E( ID || nonce2 ) -------

Peter.