ASCII versus BINARY ftp of encrypted file -- post ftp fixup?

[Steve Butler]

After doing an xdd dump of the file, it appears the parity bit came through.
Since the originating system is a windows box, I'm wondering if the only
change was to drop the <CR> and keep the <LF>.

Now, I've already tried inserting a <CR> everywhere I found an <LF> but that
left the file in worse shape (don't worry, the original, as received, is
still available).  It appears there are 360 places where the <LF> occurs.  I
guess it's experiment time to see which ones actually had a <CR> in front of
them.

When driving gpg from the command line it does leave a rather large section
of the file decrypted.  Inspecting this output leads me to believe there may
be only one <CR> that should be inserted rather late in the file. 

Is there a spot late in the file where OpenPG requires a line break (which
on a Windows box would be <CR><LF>)?

Now, if the sender would just return my phone calls -- my usually contact is
on vacation <<sigh>>.

-----Original Message-----
From: Ricardo SIGNES [mailto:samael-gnupg@lists.manxome.org]

On Mon, Jan 28, 2002 at 08:27:29PM +0100, Janusz A. Urbanowicz wrote:
> Steve Butler wrote/napisa?[a]/schrieb:
> > Has anybody played with doing a post-FTP fixup of such a file?
Suggestions
> > on how we might recover the file without having the sender ftp it again?

> I don't think it is possible. Make him use ascii armor.

I agree with Alex.  Once that 8th bit is gone, it's gone.  There's no
parity.

-- 
rjbs

CONFIDENTIALITY NOTICE:  This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.