0

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?

Patriot
  • 3,162
  • 3
  • 20
  • 66
Ethin
  • 33
  • 5

1 Answers1

2

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

poncho
  • 154,064
  • 12
  • 239
  • 382