diff options
Diffstat (limited to 'bugs/encryption-improvement-suggestion.mdwn')
| -rw-r--r-- | bugs/encryption-improvement-suggestion.mdwn | 39 |
1 files changed, 0 insertions, 39 deletions
diff --git a/bugs/encryption-improvement-suggestion.mdwn b/bugs/encryption-improvement-suggestion.mdwn deleted file mode 100644 index 1d8dc9f..0000000 --- a/bugs/encryption-improvement-suggestion.mdwn +++ /dev/null @@ -1,39 +0,0 @@ -[[!tag obnam-wishlist]] - - <zeri> liw: I tried out obnam yesterday and noticed you guys - simply call gpg -c --batch for the symmetric encryption part - <zeri> liw: also if I am not misstaken you sort of have a master - key for the repository (64 bit hex number encrypted for all keys - in the repository that is used as passphrase) - <zeri> liw: since you do not sepcify the - s2k-algo,s2k-mode,s2k-count configuration options of gpg as - well as the compression-algo option a gpg.conf that is usually - considered good will slow down obnam to a couple of bytes/sec - <zeri> liw: since keyderivation is of no use if a sufficiently - big random secret is used you might want to consider specifying - --s2k-mode 1 to disable most of the keystrengthening in gpg and - simply hash the password once with a salt ... speeding up the - encryption of every block at least by one order of magnitude - <zeri> (default behaviour is the compute a hash chain of at least - 1024 length up to 65011712 which was in my gpg.conf) - <zeri> also I didn't check whether you do compression in obnam - but gpg can do that for you as well but it was turned off in my - gpg.conf (I used gpg primarily for large tar balls where the one - time overhead doesn't matter) - <zeri> liw: then again I might be totally wrong and overlooked - some switch to do all that without chaning the code :) - <zeri> oh and I didn't emphasise this yet ... this hash chain - i talked about before is computed for every "chunk" which were - between a couple of bytes and 16k in my test ... the effort to - compute this hashchain (to optain encryption/authentication keys) - exceeds the effort to ecrypt 16k with any blockcipher by far - I suppose - <zeri> and it's sole purpose is to prevent weak passwords for - being guesed in short time (since the computational effort to - test a password is equivalent to computing this hash chain thus - slowing bruteforce down by the factor of the length of the chain) - <zeri> "64 bit hex number encrypted" << that should have been 64 - digits :) - - -[[done]] I'm not going to override a user's gpg.conf. --liw |