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
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
Benny Helms wrote:
SNIP
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
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
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:
snip
What is your actual threat model here?
The simplest answer is to check gpg's rc after the
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
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
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
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
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
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:
snip
What is your actual threat model here?
The simplest answer is to check gpg's rc after the
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
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
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,
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
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
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
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
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
Benny Helms wrote:
snippage
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
-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
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
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
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
Benny Helms wrote:
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
25 matches
Mail list logo
