0
$\begingroup$

So I've read stack overflow questions like this one. What I'm wondering is a bit more specific though: I'm really liking what I'm seeing with BLAKE3. (I suspect that this hash function is relatively unknown, though that's not surprising given its newness.) This would, however, also apply to BLAKE2 (and maybe BLAKE, I'm not sure). BLAKE3 defines a third mode of operation, derive_key. As the paper indicates, it takes a hardcoded context string and key material and derives a key using that information. My question, to be precise, is this: assume that I am in an embedded system with a BLAKE3 implementation available, and I want to derive a key for encryption/decryption purposes. Would it be safe to use an architecture-level instruction like RDRAND or RDSEED (x86) or RNDR (ARM) to generate this key material, and then derive a key that way?

$\endgroup$

1 Answer 1

2
$\begingroup$

Would it be safe to use an architecture-level instruction like RDRAND or RDSEED (x86) or RNDR (ARM) to generate this key material, and then derive a key that way?

Would you need to derive the same key twice (for example, you're using the key to encrypt data from Alice to Bob, so both Alice and Bob need to derive the key; or if you're using the encrypt stored data, so you need to derive the key both when you store the data and when you retrieve it)?

If so, then RDRAND won't give the same data twice, hence you won't derive the same key.

If not, that is, you are generating the key only once (and storing it if you need to refer to it later), then it should be safe. On the other hand, there may be little reason to bother with a key derivation function at all; just invoke RDRAND, and use that as your key...

$\endgroup$
2
  • $\begingroup$ Following the end of your answer, if I were to use just RDRAND/RDSEED for my key, I see over here that RDRAND is a pseudorandom number generator, whereas RDSEED uses the TRNG in the processor. Despite the fact that RDSEED is designed to be used to seed other RNGs, would it be safest to use RDSEED to extract my key because that uses the hardware noise source directly instead of an intervening PRNG? $\endgroup$
    – Ethin
    Sep 20, 2020 at 19:41
  • $\begingroup$ @Ethin it usually doesn't make sense to worry about the difference between "pseudorandom" and "true random" in real applications. The fundamental question is, what are you going to do with the key? If the answer is "encrypt a potentially long message" or "encrypt potentially many messages", then you're already relying on the assumption that it's safe for e.g. AES to generate many random bytes from a single key. If that assumption fails, your app will be broken, regardless of whether your key is "truly random". Same argument: mail-archive.com/[email protected]/msg04763.html $\endgroup$ Nov 28, 2020 at 17:56

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.