<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