Weak tarsnap keys generated on FreeBSD 11-CURRENT

[Colin Percival <cperciva@tarsnap.com>]

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