Let me try to reformulate the problem, as it might help a bit. The requirements are the following:

  1. At the beginning of their connection, the two end-points perform a Diffie-Hellman to derive with a common key $K$.
  2. Then EP1 needs to generate a random 48-bit value $R$ and send it to EP2. This random value needs to have the following two properties: (a) an attacker is not able to guess the next random values that EP1 generates and (b) EP2 is able to verify that $R$ is indeed coming from EP1.
  3. The two end-points also share a timing information value $T$, which is like a timing counter and is 64-bits. I don't know more, I just know that this value is unique in each association and is known by both EPs.
  4. By association I mean the full sequence of steps 1-4 above. If the EPs disconnect they run those messages from the beginning but both EPs delete the key $K$ and establish a new one in the next association.

So, to modify a bit my answer above, I was thinking of the following solution:

EP1                                    EP2
1.s1 = AES-CTR(K,T||counter,K) --------->|
2.R1 = s1 XOR K------------------------->| 
                                         | 3. s1' = AES-CTR(K,T||counter,K)
                                         | 4. R1' = s1' XOR K
                                         | Verify R1' == R1

In step 1, EP1 uses AES in CTR mode, with key $K$, the nonce/counter field to be a concatenation of $T||counter$, and the message to be encrypted is again $K$.

In step 2, the random-looking value $s_1$ from step 1 is xored with the same key $K$ and the last 48-bits are sent to EP2. I am reusing $K$ as the input message simply because it is a known value to EP2 and so it can check the encrypted value. But do let me know if this is a bad practice.

In steps 3 and 4, EP2 performs the same computations since all values are common and in step 5 checks whether $R_1'==R_1$. If so, this means that EP1 is authenticated because it must be using the correct key $K$, and also $R_1$ values should not be predictable.

Do you see any flaws or redundancies in my scheme? Would it achieve the requirements mentioned at the beginning of my post?

  • $\begingroup$ The timing info can be guessed, it is only useful against replay attacks I suppose. Can we assume that the seed is somewhere between 128 and 256 bits? I guess that for a CSPRNG, we can assume that the first 3 steps are no better than RNG(timing info | seed) by the way (concatenation of both seeds). $\endgroup$
    – Maarten Bodewes
    Commented May 9, 2022 at 15:35
  • 1
    $\begingroup$ @MaartenBodewes, thanks. Timing info is sent in clear and can be intercepted by anyone. The seed can be between 128-256 bits. The first three steps are actually a slight adaptation of the ANSI X9.17 standard. Pasting here from wikipedia: Obtains the current date/time D to the maximum resolution possible. Computes a temporary value t = TDEAk(D) Computes the random value x = TDEAk(s ⊕ t), where ⊕ denotes bitwise exclusive or. Updates the seed s = TDEAk(x ⊕ t) $\endgroup$
    – Jimakos
    Commented May 9, 2022 at 19:00
  • 1
    $\begingroup$ Perhaps tangential, but how do you ensure they stay synchronized? EP1 sends data to EP2, but EP2 never receives it. EP1 advances its state, but EP2 doesn't. $\endgroup$ Commented May 9, 2022 at 21:58
  • $\begingroup$ TDEA (i.e. triple DES) is a block cipher, a PRP, not an RNG. So in that case the separate steps do make more sense. Of course that would also mean an 8 byte seed, which is detrimental to security, but the main difference is of course the $k$ in there: a key that provides the security. For a key-less RNG the scheme makes less sense. $\endgroup$
    – Maarten Bodewes
    Commented May 9, 2022 at 22:42
  • 1
    $\begingroup$ @AmanGrewal I haven't included all parts of the protocol, simply because I am completely ignorant to it. We can just assume that timing info is there to synch the two end-points. $\endgroup$
    – Jimakos
    Commented May 10, 2022 at 5:59


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.