losing meaningful whitespaces in an encrypted file

[David Shaw]

On Thu, Sep 06, 2007 at 06:55:59AM -0700, paladino wrote:
> 
> Hi, I'm sorry to jump right in with a dumb question, but I've tried doing
> some research myself and I have to confess to much of this being way over my
> head.
> 
> I work for a University that uses GnuPG to encrypt files to send out to
> various vendors.
> 
> We're having a very odd situation right now with one of our files.
> 
> We are sending a file that has a header line that ends with 13 spaces. We
> are encrypting the file from the command line, on a unix machine, with
> GnuPG.  Here's the actual command our guys are using:
> /usr/local/bin/gpg -v -r XXXXXXXX -f &filename 

Are you sure about that?  There is no '-f' option in GPG.

> We are then transmitting the file to a vendor who is unencrypting it with
> the windows version of PGP.
> 
> When I look at the file here, immediately before it is encrypted, the 13
> white spaces are still there. When I look at the file at the vendor,
> immediately after decryption, the 13 spaces are gone.
> 
> I haven't had any luck with getting more information from the vendor about
> what kind of options they are using.  I do know they are using a windows
> version, and the guy says he basically just double clicks on it, types in a
> password, and it unencrypts the file.
> 
> Is there anything obvious that could be causing something like this?  Which
> end is it more likely the problem is at?

This is a mini-bug sort of thing, based on historical practice in the
OpenPGP community and two different versions of the OpenPGP.
Basically, OpenPGP specifies both binary and text transports.  Binary
is just that - a binary image of the file, with no changes.  Text is
canonical text, and there are rules for the canonicalization (change
line endings to CRLF, etc).

When the OpenPGP spec was written, a piece of 'incorrect' language
crept in: that whitespace at the end of a line would not be included
in canonical text.  PGP already worked fine and never changed their
code to match the language in the spec.  GPG came along later and
followed the spec exactly.  For various reasons, this mismatch in
canonicalization wasn't really a problem in practice, but
nevertheless, in the process of writing the updated OpenPGP spec
(which is with the RFC editor now, so it'll be out soon), this was
resolved.  The new canonicalization rule is the historical one: change
line endings, and do nothing to trailing whitespace.

It is hard for me to give you exact advice on what to do from here
without a few piece of information:

1) What version of GPG are you using?  (gpg --version)
2) The command line you are using (I'm fairly sure the one above is
   not correct, as GPG has no '-f' option).

David