Re: How to verify the file was successfully encrypted...
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
Re: How to verify the file was successfully encrypted...
On Sat, 2006-07-15 at 00:05 +0930, Alphax wrote: Better than that, if you get GPG to sign the file when it encrypts it (using a passwordless key/subkey) and/or use the MDC option, you'll be able to do this more reliably... Thank you, Alphax! I'll look into that. Benny ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to verify the file was successfully encrypted...
On Thu, 2006-07-13 at 23:15 +0200, Samuel ]slund wrote: If I read this thread right you actually wnt to make a decryption and compare the results and you do _not_ want to keep the private key on that machine. Could you do something creative with --show-session-key to be able to decrypt each file once w.o. risking your private key? HTH //Samuel Interesting idea, Samuel. Thank you! I'll give it a whirl. Benny ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
How to verify the file was successfully encrypted...
Hi folks. I've read the man page. I've read the FAQ's. I'm not seeing what I'm looking for. Using something like zip, you can use a -T to test the integrity of the file. Note: this is not testing that nobody has altered it, or that it came from a specific user; it is only testing whether it is a good gpg file and whether it can be decrypted. All I can find in gpg is a way to verify the integrity vs. a signature file. I'm looking for a way to gpg encrypt a file, test that the encryption was good and that the file can be extracted, and then to delete the original file. Even better would be a way to automatically remove the original when the encrypted version has been successfully created, if such a parameter exists. At the very least, though, a way of testing that the file encryption was successful without having to sit at my desk at 3AM running 'gpg --decrypt filename' to test it would be very helpful. Is this something I'm just not seeing on the man page and in the FAQ's? Thanks! Benny Helms ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to verify the file was successfully encrypted...
On Wed, 2006-07-12 at 12:25 +0200, Janusz A. Urbanowicz wrote: On Tue, Jul 11, 2006 at 01:38:23PM -0600, Benny Helms wrote: snip What is your actual threat model here? The simplest answer is to check gpg's rc after the encryption run. Before deleting original file, I must make certain encrypted version is in good shape so I can open it at a later date and obtain data. If it is broken, I'm in deep monkey muffins. That's the threat model. 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. Thanks! Benny ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to verify the file was successfully encrypted...
On Wed, 2006-07-12 at 05:14 -0500, Robert J. Hansen wrote: Benny Helms wrote: I'm looking for a way to gpg encrypt a file, test that the encryption was good and that the file can be extracted, and then to delete the original file. Forgive a silly question, but what's wrong with decrypting the file as a way of verifying the encryption worked? Sorry. I guess I should have given more details. I was just hoping the bare minimum info would be enough because somebody would say, Oh, that's easy! All you do is... I have a server with files that are created on a daily basis. Many files. I've reached a point where I want to have those files encrypted each night to prevent security breaches. My intent is to encrypt the file and delete the original. However, if I do that, and then go back a week later to obtain some data from that file, and it says, Whoa, dude! This gpg file seems to be hosed. I can't open it!, I'm absolutely screwed because our contract requires eternal data retention on some if this stuff. Losing data is unacceptable. But at the same time, having an encrypted version and an unencryted version is equally unacceptable. Basically, I'm looking for a *scripted* way to verify that the newly created gpg file is in good condition and I'll be able to open it at a later date if needed, BEFORE I delete the original file. Frankly, I'm surprised that's not a standard built-in function in gpg. Bzip2 will bzip a file, and only after successfully completing the task, it will automatically delete the original and leave only the bz2 version in place. That's the basic functionality I'm looking for. And I definitely want it to be able to do the job in a script because I don't have a life as it is, let alone sitting here manually decrypting file after file to test their usability in the wee hours of the morning when I should be home with my family. Make sense? If you've got a Perl script that's doing the encryptions, then have your Perl script do the verification step, too. I'm doing this with a plain old bash script. Basically... for file in list of files do gpg -r username -z 9 --encrypt $file pseudo code here; if the encryption went well, and the file is a \ good one, delete the original; otherwise email the the hosed file\ name so I can manually encrypt it when I get to work in the morning done Benny ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to verify the file was successfully encrypted...
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? Benny ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to verify the file was successfully encrypted...
On Wed, 2006-07-12 at 13:11 -0500, Jonathan Rockway wrote: snip BTW, why are you encrypting these files anyway? If someone broke into your computer they could just steal the crypto key too. Excellent question! Truth be told, as soon as they are encrypted, they're being moved to another server in another location, and then are being burned to CD and moved to a safety deposit box. Benny ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to verify the file was successfully encrypted...
On Wed, 2006-07-12 at 15:13 -0400, Jeffrey F. Bloss wrote: Benny Helms wrote: snippage Don't know if this will help or not, but I just did a quick test with GnuPG 1.4.4 and the --dry-run command line switch seem to work fine. Outputs to stdout rather than writing a file to disk. I changed a single bit in an encrypted (armored) file and tried it, and got a CRC error without entering any pass phrase at all. That's with -vv set in my options file, FWIW. And bleeding edge hash/cypher algorithms. Additionally, you can enter a pass phrase on the command line with the --passphrase switch. I tested it with both known good and known bad encrypted files, and if you enter a bogus/incorrect pass phrase for a known good file you get a bad passphrase error. With a known bad encrypted file you get the same CRC error. Neither one requires any user input, which is what you want. IOW, if you... gpg -d --dry-run --passphrase boguspassphrase bad-file.asc You get the CRC error, but if you... gpg -d --dry-run --passphrase boguspassphrase good-file.asc You get the bad passphrase. The down side is, both are exit code '2', so you'd have to grep for the verbal response to tell the difference. But that's not a major hurdle and it should be trivial to if $? grep return codes into something useful. The other down side is this doesn't explicitly tell you if you have a *good* encrypted file, it only picks out a couple errors. To do that you'd have to either be sitting there entering pass phrases, or include them in your script. Probably not where you'd want to go with this. :( Thanks Jeffrey. Excellent suggestion. This worked well with a .asc file, but not with a .gpg file. Does anyone on the list have a preference for .asc vs .gpg output? Pros? Cons? The size is almost twice as big as a .gpg at this time, which is a definite con. But there are probably some serious pros as well. Input? Benny ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
