Score:0

Crypto

Synchronized random number generation

Jimakos

9/9/23, 3:24 PM

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

At the beginning of their connection, the two end-points perform a Diffie-Hellman to derive with a common key $K$.
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.
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.
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?

0 + 0

encryption

random-number-generator

randomness

Maarten Bodewes

9/9/23, 3:35 PM

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).

Jimakos

9/9/23, 7:00 PM

@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](https://en.wikipedia.org/wiki/Cryptographically-secure_pseudorandom_number_generator#Standards): 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)

Aman Grewal

9/9/23, 9:58 PM

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.

Maarten Bodewes

9/9/23, 10:42 PM

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.

Jimakos

9/10/23, 5:59 AM

@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.

Jimakos

9/10/23, 6:06 AM

@MaartenBodewes indeed, this is why I didn't explicitly put TDEA but rather a generic RNG that can accept bigger seeds. However, isn't it so that I can just use AES-CTR in 128/256 mode as an RNG? In that case I can use the available key (seed) as key input to the algorithm and maybe a 128/256bit hash(timing_info | seed) as the other input. What do you think?

Maarten Bodewes

9/10/23, 8:28 AM

I think that it would not leave much of the original scheme in place, and that the `seed` input parameter isn't needed anymore, as the random values are already fully dependent on the `seed`. It also means that the seed should comply with the requirements of a symmetric (AES) key (being fully randomized) which may put additional requirements on the scheme. Any security analysis should then be performed separate from the original scheme.

Jimakos

9/10/23, 6:21 PM

I have reformulated the question completely, can you please check this version as it might make things more clear?

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Synchronized random number generation

TH: การสร้างตัวเลขสุ่มที่ซิงโครไนซ์

RO: Generare sincronizată de numere aleatoare

RU: Синхронизированная генерация случайных чисел

VI: Tạo số ngẫu nhiên được đồng bộ hóa

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.