How to verify the file was successfully encrypted...

[Benny Helms]

On Fri, 2006-07-14 at 15:07 +0200, Janusz A. Urbanowicz wrote:
> > Can you please explain what you mean by "check the gpg's rc after the
> > encryption run?"  I'm unfamilar with the meaning of "rc" in this case.
> 
> return code
> 
> every unix code returns an numerical code which by convention means
> the state of operation just done, 0 - success.

Understood.  I call that return status.  Too many acronyms in our industry.  :-)


> I find your explanation of the threat model not very consistent. You
> don't trust gpg, but you trust the filesystem code, network transfers
> or storage media. It is possible to any element of the chain fail and
> corrupt your precious files.
> 
> If they're so important as you state, you should invest in some decent
> hardware like RAID-s and backups and disaster recovery planning, and
> site physical security policy and procedures. And irreliability of gpg
> is your least problem.

Interesting.  Perhaps I'm not clear.  That happens.

An encrypted file is absolutely useless if it cannot be decrypted.  In
fact, it's flat out dangerous!  It's like carrying a gun around for
protection, and when you suddenly need it, discovering it has no ammo
and the barrel has been blocked.  All the backups in the world, all the
RAID, DR policies, etc., will not help if the encrypted data is corrupt
and you do not have the original.  To me, that sounds very "consistent".
And the fact that I'm trying to certify that the file is a solid,
working encrypted file before deleting the original should have told you
that I wasn't being frivolous with my procedures and security measures.

As a Unix SysAdmin with many years on the job, I do my backups
faithfully, I'm running RAID, we have a DR policy in place and test it
on a regular basis.  Firewalls are many, strong and in place.  What
these items have to do with whether I can trust that an encrypted file
can be decrypted to return my "precious data" when I need it is beyond
me.

And yes, I also take into account the data transfer, the storage media,
etc.  I already have procedures in place for all of that.  What I don't
have, and what makes everything you offered irrelevant, is the certainty
that the encrypted file is decryptable so I can safely remove the
original that I wanted to protect in the first place.  That was the only
question I put on the table because I've already handled the rest, and
don't need assistance in those areas.  I only asked for assistance with
gpg because I haven't used it in this way in the past.

Thanks for your input, though.

Benny