10

I've been looking at ways to generate a strong 256 bit/32 byte symmetric key for the HMAC_SHA256 algorithm. I stumbled upon the /proc/sys/kernel/random/uuid file.

According to man random(4): "The read-only files uuid and boot_id contain random strings like 6fd5a44b-35f4-4ad4-a9b9-6b9be13e1fe9. The former is generated afresh for each read, the latter was generated once."

The string from cat /proc/sys/kernel/random/uuid looks ideal for this purpose. I can remove the '-' chars and end up with a 32 bytes of randomness.

Is this a valid approach to generate a cryptographically strong source of keying material?

CodesInChaos
  • 106,488
  • 23
  • 218
  • 262
pfarber
  • 141
  • 2
  • 5
  • possible duplicate of [Is Perl Data::UUID a strong symmetric key source?](http://stackoverflow.com/questions/5873332/is-perl-datauuid-a-strong-symmetric-key-source) – Paul Nathan May 03 '11 at 19:05
  • 1
    I don't think it's a duplicate. Here I'm proposing a different tack of using /proc/sys/kernel/random/uuid as a source of randomness. According to the documentation for random(4) the contents of the uuid file is a random number derived from /dev/random which is an interface to a hardware based entropy pool for Linux. – pfarber May 04 '11 at 14:47
  • 1
    A version 4 (variant 1) random UUID contains 122 random bits. https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_(random) – PM 2Ring Jul 25 '22 at 09:24

3 Answers3

13

An old question but in case anyone stumbles on it, I wouldn't advise this.

/proc/sys/kernel/random/uuid is a type 4 (random) UUID with certain semantics - it's not just a string of random hex characters. For example you'll see the first digit in the third group is always a 4.

For 256 random bits just read 32 bytes from /dev/random (uses external entropy, can block) or /dev/urandom (never blocks).

Tombart
  • 30,520
  • 16
  • 123
  • 136
helloPiers
  • 658
  • 7
  • 13
0

o172.net is the best answer, would comment on it directly but cannot.

/proc/sys/kernel/random/uuid is based on urandom but it is best to grab from urandom directly.

This below is how to get it from the shell, the following gets 32 ascii hex bytes:

echo $(tr -dc a-f0-9 < /dev/urandom | dd bs=32 count=1 2> /dev/null)

You can change the char set via the tr params, the bytes by the 

dd bs=
or not use tr

and get random binary.

Unheilig
  • 16,196
  • 193
  • 68
  • 98
mycal
  • 61
  • 1
  • 2
-3

Would you rely on a well-defined deterministic pseudo-random algorithm for key generation? That's the question basically.

I'd say, take the UUID as a base for your key, but do one pass of encryption on it using a secret key of yours.

Aviad P.
  • 32,036
  • 14
  • 103
  • 124
  • what would be the point of doing one pass of encryption on a string that is already guaranteed to be perfectly random? – pfarber May 04 '11 at 14:48
  • 4
    It's not perfectly random, in fact it's perfectly NON random. There's a deterministic algorithm that generates it. – Aviad P. May 04 '11 at 17:22
  • 1
    If you already have a good secret key, why use a UUID as a "base" for it? Use the key itself, or encrypt any arbitrary bitstring with the key to generate a new key - the result will be just as random as if you encrypted a UUIS. – amalloy Jul 25 '22 at 20:44
  • Because the longer a key remains in use the higher the risk of compromise, so you have to rotate keys periodically, and to generate your "arbitrary string" you are well justified in using a guid. – Aviad P. Jul 26 '22 at 06:09