-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Everybody,
The people affected by this should have seen the FreeBSD mailing list post already, but in case anyone missed it: FreeBSD 11-CURRENT (but not any of the releases or stable branches) has had randomness issues since October 30th: https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054580.html If you have tarsnap keys which were *generated* on FreeBSD 11-CURRENT with an affected kernel, it is probably possible for me, Amazon, or the NSA to decrypt archives stored using those keys. See below for instructions on key rotation. Merely *using* tarsnap on an affected system is not a problem; the only place tarsnap uses the broken entropy-generation path is during key generation. Using keys generated on an affected system does not (a) allow me, Amazon, the NSA, or anyone else to create archives which tarsnap will accept as being validly signed (there is a signing key which is created without the broken entropy code path), or (b) allow anyone else to read, write, or delete your data (the tarsnap API authentication keys are created without the broken entropy code path). Obviously, people who have never used FreeBSD, or have only ever used FreeBSD releases or stable branches are unaffected. Technical details - ----------------- The FreeBSD kernel has several internal "entropy pools" which are used for different purposes. This bug resulted in the arc4random(9) entropy pool not being securely seeded, which has cascading effects into arc4random(3) and then OpenSSL's entropy pool. The only place where tarsnap relies on OpenSSL for randomness is during the generation of RSA keys used for block encryption and archive signing. This was a choice I made for ease of implementation: I would have preferred to not rely on OpenSSL for randomness at all, but I wanted to use OpenSSL's code for RSA key generation. Every other use of entropy in tarsnap -- API authentication keys, the block MAC key, deduplication parameters, ephemeral AES keys, the encrypted tarsnap client-server protocol, transaction nonces, and hash tables -- makes use of tarsnap's internal HMAC_DRBG PRNG, which is seeded from /dev/urandom and not affected by the FreeBSD bug. Key rotation - ------------ If you have been using keys generated on an affected FreeBSD system, you can re-encrypt your data with new (securely generated) keys. First, run # tarsnap-keyregen --keyfile key-file --oldkey old-key-file --user user-name --machine machine-name to generate new encryption keys which are "compatible" (for deduplication purposes) with the old keys. (This is the same command line as tarsnap-keygen except that it's tarsnap-key*re*gen and there's an added --oldkey parameter.) Then run # tarsnap-recrypt --oldkey old-key-file --oldcachedir old-cache-dir --newkey new-key-file --newcachedir new-cache-dir to download, verify, decrypt, re-encrypt, and re-upload your data. - -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlTj6h8ACgkQOM7KaQxqam73igCgqs5KEhABJP4x3gSwMVUxzslY e3QAoJAQfmv6dKst5cv+TB79avK2zhfE =EFnG -----END PGP SIGNATURE-----
