0
$\begingroup$

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?

Improve this question
$\endgroup$
8
  • $\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 ♦
    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
    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$
    – Aman Grewal
    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 ♦
    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
    May 10, 2022 at 5:59

0

Reset to default

Your Answer

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