GPG Problem - invalid radix64 character

[Jerome Baum]

On Mon, May 16, 2011 at 17:32, Turbo Fredriksson <turbo at bayour.com> wrote:

> Now, I tried to just remove the binary chars, but that ended up with a line
> which is shorter than the others which I doubt will work (it would take me
> almost a day to find out - slow USB1 disks), so any idea on how to proceed
> would be much appreciated.
>

Most likely won't work. Data definitely looks corrupted. Can you reduce the
size of the overall data, so there's less to work with?

In the worst case, you may be looking at loosing everything from the
corruption point onwards, assuming some kind of stream compression. This is
IIRC the default for GnuPG when it encrypts. Otherwise you may be able to
recover all but this part by just filling in zeroes ("A" IIRC). Haven't
looked in too much detail at the data but it looks like there's many, many
bytes filled with scrap so looks like more than one line. So, start at the
beginning of scrapped data (with a copy, of course), fill in "A"s until you
reach the 76 (or 80) limit, fill in a line break, continue with "A"s, repeat
until nothing left.

GnuPG may choke on an incorrect checksum, but there should be an override
option or it might just spit out the file anyway.

For the future, look at alternative ways to run this backup. Why
ascii-armor? Why gpg? Encrypting w/ gpg has a huge potential for data loss
in case of corruption -- of even a single bit. This isn't really an issue
with gpg, it simply doesn't _by default_ operate in a manner designed for
this. You may be able to tweak it, but how about this instead:

1. Encrypt your data symmetrically using a salt -- openssl enc using openssl
rand output as key file.
2. Split encrypted data.
3. Encrypt key file using gpg, or whatever you want to do with it.
4. Transmit (possibly ascii-armor each split file).

I find gpg is very well-suited for the tasks it's designed for. I don't
think this kind of backup falls into that category.

-- 
Jerome Baum

tel +49-1578-8434336
email jerome at jeromebaum.com
-- 
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20110516/2e309ce9/attachment.htm>