(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.
Description: Binary data