3
$\begingroup$

I am (perhaps naively) evaluating the security considerations of using the following code to create BIP39 seed phrases (on a read-only and offline Raspberry Pi).

Apparently, using jot -r 1 1 2048 is not ideal and I would like to leverage the HRNG (/dev/hwrng) on Raspberry Pi hardware.

printf "%s\n" "Create random 24-word BIP39 seed phrase…"
seed=()
for i in $(seq 1 24); do
  seed+=($(sed "$(jot -r 1 1 2048)q;d" "/path/to/bip39.txt"))
done
echo ${seed[@]}
$ cat bip39.txt | head     
abandon
ability
able
about
above
absent
absorb
abstract
absurd
abuse

Edit: this approach would not work given BIP39 seeds use last word as a checksum (see spec).

$\endgroup$
12
  • 1
    $\begingroup$ Jot uses arc4random and see Is arc4random secure enough? from infosec. Stick to /dev/urandom $\endgroup$
    – kelalaka
    Mar 6 at 16:40
  • $\begingroup$ Thanks @kelalaka. According to man jot, when a seed is provided, random is used vs arc4random. Given the seed has enough entropy, that would make randomness more cryptographically secure right? $\endgroup$
    – sunknudsen
    Mar 6 at 16:52
  • $\begingroup$ If you believe the marketing hype/NSA/your state of mind, RPis have an embedded TRNG based around a secret implementation. scruss.com/blog/2013/06/07/… $\endgroup$
    – Paul Uszak
    Mar 6 at 16:59
  • 2
    $\begingroup$ @PaulUszak If the NSA controls your hardware, it doesn't matter whether you use its random generator or not. They'll know what you did anyway. Trusting everything on the platform except its random generator is silly. $\endgroup$ Mar 6 at 17:31
  • 2
    $\begingroup$ This question is mostly off-topic since it's about a specific tool (jot) and a specific (unspecified) operating system. I've focused my answer on the on-topic part, which is "how do I read documentation to figure out whether a random generator is secure". For future reference, a site such as Unix & Linux, where Unix scripting tools is on-topic (easily determined from the site description) and security-related answers are usually good (not easily determined, but I claim that it's generally good – much better than Stack Overflow or Super User). $\endgroup$ Mar 6 at 17:33
2
$\begingroup$

There are different versions of jot, and they use different sources of randomness. The Debian man page states:

Random numbers are obtained through random(3).

s defaults to a seed depending upon the time of day

random is not cryptographically secure. This is not explicitly mentioned in the documentation, so it's a good guess that it isn't¹. Even if it was, The seed being the time of day is very predictable. So jot on Debian is not at all suitable to generate a key or anything else that needs to be secure.

The OpenBSD man page states:

Random numbers are obtained through arc4random(3). Historical versions of jot used s to seed the random number generator. This is no longer supported.

arc4random on OpenBSD is secure, as documented in the man page². So on OpenBSD, your script generates a passphrase securely, with $24 \log_2(n)$ bits of entropy where $n$ is the length of the word lists (assuming the word lists has no duplicates).


If you have GNU utilities, use shuf. It can be instructed to use secure randomness:

--random-source=file Use file as a source of random data used to determine which permutation to generate. See Random sources.

By default these commands use an internal pseudo-random generator initialized by a small amount of entropy, but can be directed to use an external source with the --random-source=file option. (…) The set of available sources depends on your operating system.

On Linux, /dev/urandom is secure except on a freshly installed system that doesn't have a hardware random generator. Since your platform has a hardware random generator, you don't need to worry about the initial seeding of the system random generator.

So with GNU coreutils, your script can just be

shuf --random-source=/dev/urandom -r -n 24 <bip39.txt

¹I confirm that guess.
² Historically, arc4random used RC4, which is now broken. The output is biased, which would reduce the entropy of the resulting key, but not enough to break it. In any case OpenBSD switched to a different algorithm (currently ChaCha20), so arc4random is safe. Other modern BSD variants have switched arc4random to be secure as well, but beware that older releases of FreeBSD and NetBSD were insecure..

$\endgroup$
3
  • $\begingroup$ Thanks so much for sharing your knowledge! Very insightful! $\endgroup$
    – sunknudsen
    Mar 6 at 18:25
  • 1
    $\begingroup$ it's possible to reconstruct the seed (and therefore the whole output) given enough partial output – RC4 is horrible, but this is simply not true. The main problem is that the keystream has severe biases. The only way to reconstruct the seed is if you have multiple keystreams encrypted with multiple keys that differ only in a few bits (think WEP with its fixed key and 24-bit random IV). But there is no known way to compute the RC4 state array given only the keystream, no matter how much of it you get. $\endgroup$
    – forest
    Mar 7 at 5:09
  • $\begingroup$ @forest Thanks, I'd misremembered the recent improvements to RC4 cryptanalysis. $\endgroup$ Mar 7 at 13:02

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.