rfc 4880 // armor headers and footers

[vedaal at nym.hush.com]

Rfc 4880 section 6.2
( http://tools.ietf.org/html/rfc4880#section-6 )
lists the following header as one of the acceptable ones:

BEGIN PGP MESSAGE, PART X/Y 
(It assumes ----- before BEGIN and after Y)

GnuPG doesn't recognize this, and gives an error message of:

$ gpg /cygdrive/c/hflt3dCH.txt.asc
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information
gpg: no valid OpenPGP data found.
gpg: processing message failed: eof

It does this even when the message is a simple unsplit symmetric 
message, with only the header and footer changed.

here is the file:

-----BEGIN PGP MESSAGE, PART 1/2-----
Version: GnuPG v1.4.11 (Cygwin)
Comment: passphrase = sss

jA0EAgMIUjoRauj6Ll9gyS0XpeAXFWQEVfkClC8b7e1YDMpyZsXpa+Hm+N8DZMOd
90PmxTwGso5sgWm+TNw=
=kYAM
-----END PGP MESSAGE, PART 1/2-----

(It decrypts as expected when changing the header and footer back 
to the standard one).

This PART X/Y header is used for pgp commandlines 2.x - 6.x
(maybe even current pgp, I don't know, lost my copy of 8.x, and 
only have 2.x and 6.x) when wanting to break up a long armored 
message and send it out as parts.

Have played around with this, and have managed to send out an 
armored  symmetrically encrypted PGP message of a 500mb truecrypt 
container file using gmail.

Disastry's pgp2.x symmetrically encrypted it and split it into 99 
parts each of  about 110 k lines, and gave a suffix to each part, 
(.a01 .a02,  ... , .ao99), and after copying each into the same 
folder, successfully restored and decrypted it, with only a simple 
command:

pgp -filename.a01 

(After the correct passphrase for the symmetric encryption was 
given, it concatenated, decrypted, and restored the original 
truecrypt container.)

Nowadays, with larger e-mail storage, and when people don't trust 
the 'cloud' for file storage, it might be useful to have gnupg 
sign, encrypt, armor, and split large files, send them through e-
mail, and then decrypt, verify and restore them.

just a thought for a 'feature request'  of being able to split and 
reconstitute large files...


Thanks,

vedaal