Generate ciphers with a better entropy.

Unless highRandomQuality=false (or --fast) is set, use Libgcypt's
'GCRY_VERY_STRONG_RANDOM' level by default for cipher generation, like
it's done for OpenPGP key generation.

On the assistant side, the random quality is left to the old (lower)
level, in order not to scare the user with an enless page load due to
the blocking PRNG waiting for IO actions.
This commit is contained in:
guilhem 2013-04-05 21:06:16 +02:00 committed by Joey Hess
parent 602baae12e
commit 00fc21bfec
6 changed files with 41 additions and 19 deletions

View file

@ -23,10 +23,15 @@ The basis of this scheme was originally developed by Lars Wirzenius et al
[for Obnam](http://liw.fi/obnam/encryption/).
"""]]
Data is encrypted by gpg, using a symmetric cipher.
The cipher is itself checked into your git repository, encrypted using one or
more gpg public keys. This scheme allows new gpg private keys to be given
access to content that has already been stored in the remote.
Data is encrypted by GnuPG, using a symmetric cipher. The cipher is
generated by GnuPG when the special remote is created. By default the
best entropy pool is used, hence the generation may take a while; One
can use `initremote` with `highRandomQuality=false` or `--fast` options
to speed up things, but at the expense of using random numbers of a
lower quality. The generated cipher is then checked into your git
repository, encrypted using one or more OpenPGP public keys. This scheme
allows new OpenPGP private keys to be given access to content that has
already been stored in the remote.
Different encrypted remotes need to be able to each use different ciphers.
Allowing multiple ciphers to be used within a single remote would add a lot