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
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 sa
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
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 serve
-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 abili
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
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
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 (file
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 newl
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 d
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 encrypt
On Wed, Jul 12, 2006 at 12:02:12PM +0100, Mark Brown wrote:
> On Tue, Jul 11, 2006 at 10:03:20PM +0100, Tony Whitmore wrote:
>
> > I'm running Ubuntu Dapper. Am I right in thinking the entries in
> > /proc/bus/usb/XXX/XXX should be modified to match the rules (i.e. group
> > scard, mode 644)? Beca
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 alter
On Tue, Jul 11, 2006 at 10:03:20PM +0100, Tony Whitmore wrote:
> I'm running Ubuntu Dapper. Am I right in thinking the entries in
> /proc/bus/usb/XXX/XXX should be modified to match the rules (i.e. group
> scard, mode 644)? Because they don't seem to be:
Current systems with udev should use somew
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 t
On Wed, Jul 12, 2006 at 09:05:58AM +0200, Werner Koch wrote:
> On Tue, 11 Jul 2006 20:16, Tony Whitmore said:
>
> > Is there a compatibility list of drivers supported by GPG's internal
> > card reader driver, other than the relevant part of the HOWTO? Do
>
> No there is no such list. This is bec
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
On Tue, 11 Jul 2006 20:16, Tony Whitmore said:
> Is there a compatibility list of drivers supported by GPG's internal
> card reader driver, other than the relevant part of the HOWTO? Do
No there is no such list. This is becuase the driver implements the
CCID specification with a few limitations
18 matches
Mail list logo
