Re: How to verify the file was successfully encrypted...
> > How about if you append a hash of the file to the file, and encrypt that > > too? Then have the remote machine do the trial decrypt-and-check-hash. If > > all is OK the remote machine can then tell the local one to delete the > > original; and if it's not OK, it can scream at you. > > 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... Wasn't the original poster looking for something which didn't require trusting one particular piece of software? If they're happy to go with gpg, or to use two different PGP implementations at the two ends, then sign+encrypt would indeed appear to cover it. (Of course, it's not quite true signing, in the sense that it's only there as a check against corruption, and the signing key will be visible on the source machine.) -- Dr George D M Ross, School of Informatics, University of Edinburgh Kings Buildings, Mayfield Road, Edinburgh, Scotland, EH9 3JZ Mail: [EMAIL PROTECTED] Voice: +44 131 650 5147 Fax: +44 131 667 7209 PGP: 1024D/AD758CC5 B91E D430 1E0D 5883 EF6A 426C B676 5C2B AD75 8CC5 pgpvmdXJWngTW.pgp Description: PGP signature ___ 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...
Why do you need to use gpg for this task when you only need a symmetric cipher. You would be better off going to CPAN (perl) and download AES (Advanced Encryption Standard) module and use all of the features coming with it or use libcrypt (used by gnupg) and use this. The other solution, I can think off (if you use linux), is making encrypted pseudo file system (file) of requested size (size of CD/DVD or other backup medium) and copy the data on this file system (it is transparent). When you finis this move the pseudo file system (file) to your backup medium. Regards Martin Poz ___ 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...
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.
>
> 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.
My suggestion:
On your server, calculate a hash for the unencrypted data file.
Encrypt the data file & transfer the encrypted file to a secure box
which has your secret key.
Decrypt the file on that secure box & compare the hash to the hash
created on the server. If the hashes are the same then all is well &
you can delete the files on the server.
This can all be scripted & it keeps your private key off the server.
I hope this helps,
Bob
{My apologize if this doesn't thread correctly]
___
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, Jul 13, 2006 at 08:31:39PM -0400, Vladimir Doisan wrote: > The user base of GnuPG is huge, and any serious bugs in the code will > be weeded out very quickly by the beta testers and early adopters. > Invalid encryptions is a VERY serious bug. Sadly this is not true enough, as has been illustrated recently by some people asking about corrupted large encrypted files generated on windows with (if I remember correctly) the "-e file" option some time before. I think it was possible to restore the data by doing some manual bit fideling in the encrypted binary... (But I do not remember.) HTH, //Samuel ___ 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
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 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...
George Ross wrote: >>> 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. > > How about if you append a hash of the file to the file, and encrypt that > too? Then have the remote machine do the trial decrypt-and-check-hash. If > all is OK the remote machine can then tell the local one to delete the > original; and if it's not OK, it can scream at you. > 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... -- Alphax Death to all fanatics! Down with categorical imperative! OpenPGP key: http://tinyurl.com/lvq4g signature.asc Description: OpenPGP digital signature ___ 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, Jul 12, 2006 at 10:59:52AM -0600, Benny Helms wrote: > 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: > > > 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. return code every unix code returns an numerical code which by convention means the state of operation just done, 0 - success. 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. Alex ___ 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...
> > 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. How about if you append a hash of the file to the file, and encrypt that too? Then have the remote machine do the trial decrypt-and-check-hash. If all is OK the remote machine can then tell the local one to delete the original; and if it's not OK, it can scream at you. -- Dr George D M Ross, School of Informatics, University of Edinburgh Kings Buildings, Mayfield Road, Edinburgh, Scotland, EH9 3JZ Mail: [EMAIL PROTECTED] Voice: +44 131 650 5147 Fax: +44 131 667 7209 PGP: 1024D/AD758CC5 B91E D430 1E0D 5883 EF6A 426C B676 5C2B AD75 8CC5 pgp9ydtfBXjOc.pgp Description: PGP signature ___ 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...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You will have to just trust GPG as I do not think that such checking is possible to do in a secure manner. At my org, I am using GPG to encrypt all backups. To ensure that the code does not contain bugs, I wait for ~ a month before upgrading the GPG release. After an upgrade, I perform several backup+encrypt+decrypt+restore+check to make sure nothing is borked. I lock in the version and use that for a while. I do not worry about daily backups, but each quarterly backup, I encrypt it, decrypt it and verify it manually. The user base of GnuPG is huge, and any serious bugs in the code will be weeded out very quickly by the beta testers and early adopters. Invalid encryptions is a VERY serious bug. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEtuXrNR4PQ6HVpW0RAkGuAKDflrwOXTRc521Mhj0StDSriiaDdgCg1JMD kkmh4QPGGJ45njeUsC4Cry8= =R6vH -END PGP SIGNATURE- ___ 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, Jul 12, 2006 at 10:59:52AM -0600, Benny Helms wrote: > 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: > > > 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. 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 ___ 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...
Benny Helms wrote: > On Wed, 2006-07-12 at 15:13 -0400, Jeffrey F. Bloss wrote: >> Benny Helms wrote: >> >> > >> 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? > .asc files are immune to mangling of CR/LF characters which may be present in binary data, which often happens when you transfer via email or FTP. -- Alphax Death to all fanatics! Down with categorical imperative! OpenPGP key: http://tinyurl.com/lvq4g signature.asc Description: OpenPGP digital signature ___ 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...
This might be a hard one. When you encrypt to a public key, there is no way gpg can decrypt it, to verify that it can be decrypted, unless it can unlock the private key with your password. The only way i see, is that gpg would have to encrypt 2 times and compare the results. But then again, the same error might happen twice. Does this make any sense? i don't know, this was just what im thinking. ___ 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: > > > 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
Re: How to verify the file was successfully encrypted...
On Wed, 2006-07-12 at 13:11 -0500, Jonathan Rockway wrote: > > 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...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jonathan Rockway wrote: > BTW, why are you encrypting these files anyway? If someone broke into > your computer they could just steal the crypto key too. True, unless the private key isn't kept on the same machine. Which also would negate the ability to decrypt the file on the server to verify that the encryption was successful. :) - -- ToddOpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp == Those who have been intoxicated with power... can never willingly abandon it. -- Edmund Burke -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iG0EARECAC0FAkS1SQQmGGh0dHA6Ly93d3cucG9ib3guY29tL350bXovcGdwL3Rt ei5hc2MACgkQuv+09NZUB1otkgCgnP7KTsByYiIOddJmAG7HNyB+JA4AniX2DvJw d0uPX2K0oA+DO8iZ5K4x =YnXM -END PGP SIGNATURE- ___ 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...
Benny Helms wrote: First off, I hope you've considered that gpg is doing what it's suppose to do and you're really trying to break it. If your encrypted files are "corrupt" at a later date, maybe you have another problem and don't *want* to make it just go away. IOW, be cautious that a solution doesn't weaken your security. ;) > 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. 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. :( -- Hand crafted on 12 July, 2006 at 14:36:55 EDT Outside of a dog, a book is a man's best friend. Inside of a dog, it's too dark to read. -Groucho Marx signature.asc Description: PGP signature ___ 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...
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 and compare. If you wanted to be really sure that GPG didn't mess something else, try decrypting it with some other OpenPGP implementation. If you're using perl, use Crypt::OpenPGP. (And Text::Diff to do your diff, and File::Slurp to read in the files for Text::Diff :) BTW, why are you encrypting these files anyway? If someone broke into your computer they could just steal the crypto key too. Regards, Jonathan Rockway ___ 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, 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 and compare. David ___ 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 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 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 12:25 +0200, Janusz A. Urbanowicz wrote: > On Tue, Jul 11, 2006 at 01:38:23PM -0600, Benny Helms wrote: > 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 Tue, Jul 11, 2006 at 01:38:23PM -0600, Benny Helms wrote: > 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. What is your actual threat model here? The simplest answer is to check gpg's rc after the encryption run. ___ 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...
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? > 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. If you're already sitting at your desk at 3AM doing encryptions, then doing a decryption shouldn't be a terrible additional step. If you've got a Perl script that's doing the encryptions, then have your Perl script do the verification step, too. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
