2 ms·
I'm not too fond of printing out passwords. If I forget, and I'm extremely forgetful, that's just a disaster waiting to happen. I know my brain and I know it ca
by eksith 14y ago
I'm not too fond of printing out passwords. If I forget, and I'm extremely forgetful, that's just a disaster waiting to happen. I know my brain and I know it can't be trusted with physical security. Also, I'd rather use /dev/urandom instead of simply /dev/random.
Considering my aversion to using a stranger's computer to login to my accounts and the fact that I never use an open WiFi connection for anything without Tor, I'm much happier using a local copy of the encrypted file or at the very least a secure offline mirror(s) to download a copy of the encrypted file if I don't have it handy.
- TheNewAndy 14y agoNot really the issue, but /dev/urandom is weaker than /dev/random, it is urandom which never blocks (try "hd /dev/random" and note that it blocks, then jiggle your mouse a bit and it will come back to life)
- KMag 14y agoThis is true on some systems, but not others. On FreeBSD (and OSX, as I remember) /dev/random and /dev/urandom act identically. The underlying CSPRNG, Yarrow, is designed to recover from a compromised state vector. Unfortunately, Yarrow relies on entropy estimates to time its re-seeding. I've said it before: entropy estimates are a fiction. Ideally, /dev/random and /dev/urandom would both offer non-blocking access to an underlying Fortuna implementation (using a cryptographic hash function instead of a cipher, to avoid export/import restrictions).