(I am not subscribed to this list, so please cc me in replies.)
I tried to use cgd yesterday, and was pretty by the man pages and the
use of cgdconfig; I also stumbled across some bugs in cgdconfig. I am
not a cryptographer, and thus am unqualified to give cryptographic
advice, but I thought it might be worthwhile for the man pages to be a
little clearer on the disk format -- enough to write programs that
read and write it -- and to mention some cryptographic limitations of
cgd.
Attached is a patch to HEAD that fixes some errors in the
implementation and documentation. However, I eventually gave up on
trying to use cgdconfig[*], so I wrote my own trivial utilities (at
<http://mumble.net/~campbell/tmp/cgdutil-20101127.tgz> for the time
being, for anyone curious) to serve its function, when combined with
external tools such as scrypt <http://www.tarsnap.com/scrypt/>.
Comments? I would submit a PR for the patch, but, as I said, I am not
a cryptographer, so I am interested more in review on the patch (and
corrections to my misconceptions about cgd, if any) than just in
applying the patch.
[*] Aside from having a usage model that confused me, cgdconfig lacks
any cryptographic integrity checks -- a passphrased parameters
file is not actually bound to a particular key, so, for instance,
if you `cgdconfig -G' up a new parameters file, mistype a
passphrase, and delete the old one, cgdconfig won't (can't!)
notice, and your cgd will be lost and gone forever. In contrast,
an scrypt file is cryptographically bound to its contents, so
scrypt can say whether you typed the correct passphrase or not.
Attachment:
cgd-20101127.patch
Description: Binary data