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 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users