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.

1 files changed, 9 insertions, 4 deletions

diff --git a/doc/design/encryption.mdwn b/doc/design/encryption.mdwn
index 45eb43cc9..6a380abe1 100644
--- a/doc/design/encryption.mdwn
+++ b/doc/design/encryption.mdwn
@@ -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