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:
parent
602baae12e
commit
00fc21bfec
6 changed files with 41 additions and 19 deletions
|
@ -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
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue