How to verify the file was successfully encrypted...
dshaw at jabberwocky.com
Wed Jul 12 20:06:41 CEST 2006
On Wed, Jul 12, 2006 at 11:57:21AM -0600, Benny Helms wrote:
> On Wed, 2006-07-12 at 13:23 -0400, Mark Hardman wrote:
> > If you're using bash, can't you just script it like this...
> > 1. encrypt to gpg
> > 2. decrypt to text (or whatever it was originally) with altered file
> > name (filename.test_decrypt)
> > 3. do a diff between the original file and the newly decrypted file
> > (versions of diff I've used work on binary files, too, but you might
> > want to test this)
> > 4. if there are no differences, delete original file and test decrypt
> > file, leaving only the encrypted gpg file
> > Would that get what you're looking for?
> > Take care.
> > mark
> Thank you for the reply, Mark. Yes, that would definitely do the trick.
> I guess I need to go to the FAQ to discover how to safely put a password
> into a scripted activity since each decryption requires a password.
> Check me on this, though. Is there any error checking in gnupg when
> creating a file? Is it safe to assume that if the job completes, the
> file is usable? This method you've described will definitely work, but
> it seems like a lot more CPU cycles and a lot more time involved in the
> script than should be necessary. Should I be submitting a "wish" to the
> developer list?
There is no way to design such a self-check. This isn't a lack in
GnuPG, but a design impossibility for any program. Think about it: a
"check mode" would try and account for a bug in GnuPG and warn you
that the file was not encrypted properly. However, if you're
presuming a bug, then who says you should trust the check mode?
If GnuPG completes successfully, that means it succeeded. If you want
more assurance than that, the only way to do it is to decrypt the file
More information about the Gnupg-users