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

| improve this answer | |
$\endgroup$
  • $\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 at 19:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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