2
$\begingroup$

I am looking for a DRNG/DRBG (cryptographically secure) algorithm/function (which I can program into js). I am looking to use a DRNG as a seed generator for generating multiple, identical AES keys on separate client devices, sharing the seed for the DRNG securely between users. Basically, I trying to see if there are any simple mathematical ways to achieve this. Any suggestions are greatly appreciated!

$\endgroup$
0

1 Answer 1

1
$\begingroup$

With access to AES-256, and if the seed is a 256-bit secret about uniformly random value, a simple method that fits is to use that 256-bit secret as AES-256 key, and encipher a 128-bit counter (initially zero, incremented after use) until sufficient output has been produced; that is $n$ (resp. $\lceil 3n/2\rceil$, $2n$) times to produce $n$ AES-128 (resp. AES-192; AES-256) keys.

That's the method used internally by AES-CTR to generate it's keystream, except that here we set the IV at zero. That change introduces the theoretical possibility of a multi-target attack, but it does not matter because a 256-bit key is so large. Further, in the use case, having many client devices with keys derived from the same secret seed does not make multi-target attack easier (having many different seeds would be necessary for that).

Importantly in a JS context, there's no arithmetic on secret data (outside AES, assumed secure). There's some arithmetic for the counter, but it's value is public.

Note: With access to AES-256-CTR, we can even remove the counter arithmetic by using AES-256-CTR decryption of all-zero data, with an all-zero IV.

Perhaps importantly in the context, it's easy to generate the key for one particular user without the cost (time and space) of generating the keys for the other ones; that is, we have an addressable PRNG/DRNG.


If the seeding material was low-entropy, that's another matter. We must use key stretching, preferably memory-hard, and improvising that from AES is not trivial.

$\endgroup$
4
  • $\begingroup$ With this method, is there any possibility for attacks because each key is derived from the counter? Since the attacker knows the counter value, does this reduce the time to brute force using known plaintext attacks (assuming sufficient entropy of the seed)? Also, I read that AES-CTR uses nonce + counter, is this necessary? $\endgroup$
    – Randusr
    Commented Jan 24, 2023 at 18:11
  • $\begingroup$ @Randusr: For a seed taken among $n$, whatever the method, brute force is going to take an expected $n/2$ steps, and that's infeasible for $n=2^{256}$ as in this scheme, so there's no worry to have. What I call IV in the answer is the nonce you read about (or perhaps the nonce with some zero bytes added on the right). It needs to have some value, and I propose all-zeroes when we want to compute all the user keys at once. $\endgroup$
    – fgrieu
    Commented Jan 24, 2023 at 20:25
  • $\begingroup$ Is this method perfectly secret (perfect forward secrecy) if the message space >= key space? My understanding is that perfect secrecy requires no information to be revealed about the plaintext from the ciphertext, so the message length has to be >= key length. Does it make sense to add some kind of padding to messages of shorter length? Does this make the system perfectly secret for all messages? $\endgroup$
    – Randusr
    Commented Jan 24, 2023 at 21:00
  • $\begingroup$ @Randusr: this method is not information-theoretically secure (a.k.a. perfectly secure, secure against arbitrary powerful adversaries); but AES (or almost anything actually used) is not, as soon at more message is encrypted than the key size. Since there is no notion of session or key change over time, I don't see how we can define (perfect) forward secrecy (which is disconnected from perfect secrecy). $\endgroup$
    – fgrieu
    Commented Jan 24, 2023 at 21:19

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.