1
$\begingroup$

Suppose an embedded system without a true random number generator peripheral, but nevertheless it is necessary to generate a secret key. Suppose also that this embedded system has an analog-to-digital converter connected to a signal with a low/moderate level of noise. Finally, suppose that it is somehow possible to estimate what this level of noise is -- for simplicity, suppose that e.g. the RMS noise is such that it corresponds to a noise of 2 bits. Note this does not imply that the least significant 2 bits of each readout are uniformly random, and could be simply masked out and composed to create a secret key.

Conceptually speaking it should be possible to somehow combine e.g. 64 readouts to obtain a 128-bit key. What is an efficient and preferably standardized (e.g. NIST, ISO, RFC, etc.) way to perform this? Lacking this, what is the general best practice for this?

For now my thought is to use SHAKE-128 to absorb these 64 readouts, and then squeeze 128 bits from it. However SHAKE is known to be somewhat slow (or at least slower than say ChaCha20 or other lightweight ciphers). A second possibility that I see, but I'm less confident in, is to encrypt the readouts using a block or stream cipher, whose output is going to be larger than 128 bits, say 512 bits assuming an 8-bit ADC. Then, split this into 4 128-bit blocks and XOR them together. Is this technique vulnerable to any known attacks?

$\endgroup$
5
  • $\begingroup$ A problem with "encrypt the readouts using a block or stream cipher" is: how do you chose the key of that cipher? $\endgroup$
    – fgrieu
    Commented May 15 at 14:41
  • $\begingroup$ @fgrieu It's common to use a publicly known key. So just make one up. $\endgroup$
    – Paul Uszak
    Commented May 15 at 15:27
  • $\begingroup$ @PaulUszak: it's unusual for a symmetric cipher to use a public key. And if that's done in the question's context to encipher readouts of an ADC, that can be a problem (especially with a stream cipher). $\endgroup$
    – fgrieu
    Commented May 15 at 15:36
  • 2
    $\begingroup$ To me you are jumping right to the algorithms. Conceptually you need a Key Based Key Derivation Function (KBKDF) that allows for key extraction (HKDF has this as a separate stage). Or you could of course implement your own DRBG for a more generic option as many algorithms require random values anyway. In that case it should of course run on generic seed information rather than a key, or you might need to run the KDF in advance. Using a XOF like SHAKE as a KDF is kind of a shortcut - it isn't necessarily a bad one but other KDF's are possible. $\endgroup$
    – Maarten Bodewes
    Commented May 15 at 15:42
  • $\begingroup$ Don't forget to check if it is feasible to execute side-channel attacks against your noisy signal... $\endgroup$
    – Nite
    Commented May 16 at 12:44

1 Answer 1

6
$\begingroup$

The standardised way to obtain such a key is leveraging the Left Over Hash lemma. In short it says that if you use say MD5 to hash 256 bits of entropy, you'll get a NIST approved 128 bit key with a bias $\le 2^{-64}$. That part's easy.

Where you'll have to devote more time and effort is in measuring the entropy being generated by your signal. Is it just mains hum? Could it be Taylor Swift's latest from the local radio station? And then is it auto-correlated as there's no trivial way to measure min. entropy from general sources? You'll actually find though that even a simple sinusoid will produce ~1 bit/sample of entropy via quantisation error.

So yes this can be done and there are tools to help.

$\endgroup$

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.