Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: GnuPG: users

Mismatch between binary and ASCII-armored output for encrypted message

 

 

GnuPG users RSS feed   Index | Next | Previous | View Threaded


lists at chrissutton

Sep 30, 2009, 2:27 AM

Post #1 of 4 (887 views)
Permalink
Mismatch between binary and ASCII-armored output for encrypted message

Hi,


I'm using the GPG command-line tool to generate test data for a system
and I'm having trouble with the binary and ASCII-armored output not
seeming to correspond for encrypted messages. If anyone could point out
where I'm going wrong or what I've misunderstood, I'd really appreciate it.


What works
----------

When I generate private and public keys, I can export them in binary
form and then use a base64 encoder (in this case
http://base64.sourceforge.net/) to generate a base64-encoded version. I
can also export them using GPG's -a option to generate the
base64-encoded version directly.

If I remove the '-----' header and footer, and the checksum, the two
blocks match. Similarly, if I use the corresponding base64 decoder to
decode GPG's ASCII-armored block, the binary file it produces matches
GPG's binary output.

So far, so good!


What doesn't work
-----------------

I was under the impression that exactly the same process should work for
a message encrypted using GPG. I pass in a plaintext file with the -e
and -r options, and generate the binary and ASCII-armored versions as
above. However, when I base64 encode the binary, or base64 decode
the ASCII, the result does not match GPG's other version.

It appears as if GPG is putting slightly different binary data into the
ASCII-armored version as into the direct binary output. Is this possible?


Any advice would be much appreciated,

Thanks,



Chris Sutton


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


dkg at fifthhorseman

Sep 30, 2009, 6:38 AM

Post #2 of 4 (834 views)
Permalink
Re: Mismatch between binary and ASCII-armored output for encrypted message [In reply to]

On 09/30/2009 05:27 AM, Chris Sutton wrote:
> It appears as if GPG is putting slightly different binary data into the
> ASCII-armored version as into the direct binary output. Is this possible?

OpenPGP encryption is a hybrid model:

first, a random session key is generated.

then the random session key is used with a reasonable stream cipher
(3DES, AES, etc) to symmetrically encrypt the data in question.

then the session key is asymmetrically encrypted (once for each
recipient's key).

The resultant block is the concatenation of the ciphertext and the
encrypted session keys.


Note that the first step involves some randomization (as it should!) --
this means that each encryption of the same cleartext will yield
radically different ciphertext.

I suspect this difference is what you're seeing, not any issue with
base64-encoding.

does this make sense?

--dkg
Attachments: signature.asc (0.87 KB)


lists at chrissutton

Sep 30, 2009, 6:53 AM

Post #3 of 4 (837 views)
Permalink
Re: Mismatch between binary and ASCII-armored output for encrypted message [In reply to]

Hi Daniel,


Thanks for your reply, that does make perfect sense. In theory I do
understand how PGP works, but this is the first time I've gotten my
hands dirty so things are still clicking into place!


The actual problem I was debugging is why the binary output decrypts
okay in another crypto library, but my base64-decoded version of the
ASCII-armored output does not. I over-simplified my test case to
expecting the two to be identical!

I've now tracked this down as a problem with compression/decompression
which I was able to fix.


Thanks again,



Chris



Daniel Kahn Gillmor wrote:
> On 09/30/2009 05:27 AM, Chris Sutton wrote:
>> It appears as if GPG is putting slightly different binary data into the
>> ASCII-armored version as into the direct binary output. Is this possible?
>
> OpenPGP encryption is a hybrid model:
>
> first, a random session key is generated.
>
> then the random session key is used with a reasonable stream cipher
> (3DES, AES, etc) to symmetrically encrypt the data in question.
>
> then the session key is asymmetrically encrypted (once for each
> recipient's key).
>
> The resultant block is the concatenation of the ciphertext and the
> encrypted session keys.
>
>
> Note that the first step involves some randomization (as it should!) --
> this means that each encryption of the same cleartext will yield
> radically different ciphertext.
>
> I suspect this difference is what you're seeing, not any issue with
> base64-encoding.
>
> does this make sense?
>
> --dkg
>

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


email at sven-radde

Sep 30, 2009, 1:43 PM

Post #4 of 4 (830 views)
Permalink
Re: Mismatch between binary and ASCII-armored output for encrypted message [In reply to]

Hi!

Chris Sutton schrieb:
> What doesn't work
> -----------------
>
> I was under the impression that exactly the same process should work for
> a message encrypted using GPG. I pass in a plaintext file with the -e
> and -r options, and generate the binary and ASCII-armored versions as
> above. However, when I base64 encode the binary, or base64 decode
> the ASCII, the result does not match GPG's other version.

If you encrypt the same file twice, the output will be almost totally
different, as GnuPG uses a "session key" for encryption that changes
randomly for each call to GnuPG.
This will be true even for two subsequent encryptions of the same file
with both being either binary of ASCII mode.

When exporting a public/private key once as binary and once as ASCII,
you are processing the very same block of data using two different data
representations. Converting should work here.

HTH, Sven

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

GnuPG users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.