extra dashes in PGP-related blocks?
When people have been posting their public keys, or encrypted address blocks, to various lists I'm on, all of the "-----BEGIN whatever..." lines seem to have a "- " preppended to them. So, for instance, they look like: - -----BEGIN PGP MESSAGE----- Version: 2.6.2 [stuff] - -----END PGP MESSAGE----- I'm guessing if I really sent a block like that to a remailer, the remailer would hork because of the prepended "- "s. I know that sometimes people's public keys they've posted to a list look like that, and when I try to add them to PGP, it horks, and I've got to go into a text editor and remove the "- ", and then add it to my keyring. Does anyone know what it is that's putting in these "- "s, why it's putting them in, and how to stop it?
From: Jonathan Rochkind
When people have been posting their public keys, or encrypted address blocks, to various lists I'm on, all of the "-----BEGIN whatever..." lines seem to have a "- " preppended to them. So, for instance, they look like:
- -----BEGIN PGP MESSAGE----- Version: 2.6.2 [stuff] - -----END PGP MESSAGE-----
I'm guessing if I really sent a block like that to a remailer, the remailer would hork because of the prepended "- "s. I know that sometimes people's public keys they've posted to a list look like that, and when I try to add them to PGP, it horks, and I've got to go into a text editor and remove the "- ", and then add it to my keyring.
Does anyone know what it is that's putting in these "- "s, why it's putting them in, and how to stop it?
pgp is putting those extra "- " pieces in (guess you didn't read all your pgp docs :-), it does that so that it can tell the difference between pgp begin/end blocks and other stuff, kinda like sendmail "quoting" lines beginning with a dot with an extra dot. the difference here is that sendmail removes any leading dots before delivery and pgp doesn't after removing a signature. yeah, you do have to load it into an editor but mailing something to a remailer shoud not "hork" it. the pgp running on the remailer will just "- " the stuff and include it literally. follow? -- --< "CYBERBOY" >-- andrew@ml.com (Andrew Brown) Phone: 1.212.449.0088 Fax: 1.212.449.8612
-----BEGIN PGP SIGNED MESSAGE----- To: andrew@riskdev.ml.com (Andrew Brown) cc: jrochkin@cs.oberlin.edu (Jonathan Rochkind), cypherpunks@toad.com Subject: Re: extra dashes in PGP-related blocks?
From: Jonathan Rochkind
When people have been posting their public keys, or encrypted address blocks, to various lists I'm on, all of the "-----BEGIN whatever..." lines seem to have a "- " preppended to them. So, for instance, they look like:
- -----BEGIN PGP MESSAGE----- Version: 2.6.2 [stuff] - -----END PGP MESSAGE-----
pgp is putting those extra "- " pieces in (guess you didn't read all your pgp docs :-), it does that so that it can tell the difference between pgp begin/end blocks and other stuff, kinda like sendmail "quoting" lines beginning with a dot with an extra dot. the difference here is that sendmail removes any leading dots before delivery and pgp doesn't after removing a signature. yeah, you do have to load it into an editor but mailing something to a remailer shoud not "hork" it. the pgp running on the remailer will just "- " the stuff and include it literally.
Uhh, this is not at all true. When PGP verifies a message, it will strip out the quoting dashes in the output. This is documented in RFC 822 (I think) about quoting messages. Just run the message through PGP and it will strip out the first level of quoting in the output message, and you should be able to then run PGP on the rest of the message as well. This is not a bug, it is a feature to let PGP know *WHAT* was being signed, so that nested PGP clearsigned-messages don't interfere with each other. If it didn't quote, then if I wanted to clearsign a PGP message, the output would look something like: - -----BEGIN PGP SIGNED MESSAGE----- stuff here - -----BEGIN PGP SIGNED MESSAGE----- more stuff here - -----BEGIN PGP SIGNATURE----- inside signature - -----END PGP SIGNATURE----- - -----BEGIN PGP SIGNATURE----- outside signature - -----END PGP SIGNATURE----- If you have this, how do you deal with it? This is the same as the paranteses-matching-problem: If you are trying to match opens with closes, you have the problem that you could always have so many opens that you overrun your counter before you get to any closes! So, PGP uses the RFC-822 quoting mechanism to quote internal messages. This is perfectly legal. As for MIME: If you are using PGP to secure MIME objects, you should take the _OUTPUT_ from PGP and send that back into the MIME reader. MIME should NOT be going inside the PGP block. So, the behavior you are seeing is perfectly reasonable for a broken mail-reader! Fix your mail reader to run the PGP-secured message through PGP, and then run the output through MIME, and you will be fine! Enjoy! - -derek Derek Atkins, SB '93 MIT EE, G MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) Home page: http://www.mit.edu:8001/people/warlord/home_page.html warlord@MIT.EDU PP-ASEL N1NWH PGP key available -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBuAwUBLuzEuDh0K1zBsGrxAQFcUgLDB1WGn7TQTf4+8FgYyszcNHgcMQTcVd3w aTXunh0K7vPjos4JkVl4p5MQkNICjDxNC2KkgQkxeIs7Yy8VgaACSwIfhDrxs3+K gMalhp2FHO3S/ZvnIo7RSmk= =btQx -----END PGP SIGNATURE-----
From: Derek Atkins
pgp is putting those extra "- " pieces in (guess you didn't read all your pgp docs :-), it does that so that it can tell the difference between pgp begin/end blocks and other stuff, kinda like sendmail "quoting" lines beginning with a dot with an extra dot. the difference here is that sendmail removes any leading dots before delivery and pgp doesn't after removing a signature. yeah, you do have to load it into an editor but mailing something to a remailer shoud not "hork" it. the pgp running on the remailer will just "- " the stuff and include it literally.
Uhh, this is not at all true. When PGP verifies a message, it will strip out the quoting dashes in the output. This is documented in RFC 822 (I think) about quoting messages.
Just run the message through PGP and it will strip out the first level of quoting in the output message, and you should be able to then run PGP on the rest of the message as well.
but is a remailer (or pgp) smart enough to take the output from checking a signature and run pgp over it again? is it going to know to take something and pass it through pgp until pgp can't do anything with it any more? i think that's the problem that jrochkin was addressing. he has a pgp encrypted message and then signs it and then wants to mail it to a remailer so that the remailer can decrypt the message but it won't ecause the encryption is nested... wasn't that it? -- --< "CYBERBOY" >-- andrew@ml.com (Andrew Brown) Phone: 1.212.449.0088 Fax: 1.212.449.8612 $400 million in gold bullion counter-intelligence FBI colonel Kennedy Treasury Honduras jihad Rule Psix Legion of Doom terrorist Khaddafi Uzi South Africa Peking
-----BEGIN PGP SIGNED MESSAGE----- To: andrew@riskdev.ml.com (Andrew Brown) cc: jrochkin@cs.oberlin.edu (Jonathan Rochkind), cypherpunks@toad.com Subject: Re: extra dashes in PGP-related blocks?
but is a remailer (or pgp) smart enough to take the output from checking a signature and run pgp over it again? is it going to know to take something and pass it through pgp until pgp can't do anything with it any more? i think that's the problem that jrochkin was addressing. he has a pgp encrypted message and then signs it and then wants to mail it to a remailer so that the remailer can decrypt the message but it won't ecause the encryption is nested...
Why would it have to? A plain remailer takes the input you give it, and replays it to the output. It doesn't modify the message in any way, so there is no problem. A remailer that signs a message should take what you send it (no matter _HOW_ you sent it), sign that message wholesale, and then send out the signed message. This means that if you send it a PGP-signed message, the output message will have two signatures -- the outer signature being the signing remailer, and the inner signature (which is quoted by PGP at the remailer) is the signature on the original message. This is the correct behavior, and _SHOULD NOT_ be changed. An anonymizing remailer _might_ want to take the output of a PGP message and pass that into the output, but that is a different function altogether. I dont understand why a plain remailer should have to know anything about PGP if it is just doing remailing, and in any case it should never have to verify a PGP-signed message, unless that is the purpose of the remailer. And even if that IS the case, it should only unwrap the OUTERMOST wrapping from PGP -- it *SHOULD NOT* recursively try to collapse the PGP armors. That is NOT a remailer's job. - -derek -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBuAwUBLuzSYzh0K1zBsGrxAQGR3gLDBxPn9cmWWvWwyRdlcYUlRs5LqMHjMkRa lmOggyb2QmFS1+vEqJ2a1oUxdLJHzNcH4JxjBplDKASmG19Ixvkt1nIjkwGi3yzN J02drrVGYJqs426qnQhxI8E= =B6In -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
From: Jonathan Rochkind
My problem was that a user would send me their public key, inside of a signed message, and the "BEGIN PUBLIC KEY" stuff would have the "- " on it. Which means that before I can add it to my keyring, I've got to edit out the extra "- "s, and then save it in a file, and then pass it through PGP, instead of just passing the original message though PGP, or using the Mac "copy" command on a part of the message and sending that through PGP. Or someone sends me an encrypted address block inside a signed message, and I've got to do the same before I can use it.
but wait! you can't actually verify the outer sig until you extract the key from inside the signed message? that's a bit more complicated. pgp will actually recognize a key embedded inside an armored, signed message but it won't (i don't think -- warlord?) play with the key other than tell you it is one. what these people should probably be doing is signing their public keys with their private keys to provide the same functionality (almost). what you have, otherwise, really is a two step process. you will have to strip off the outer sig layer to get the the key.
I now understand why PGP does what it does, but it's still a pain. Perhaps the ideal mail reading program would run my incoming mail through PGP before I even saw it, so I wouldn't have this problem. Well, actually not. My ideal mail reader would check the signatures before I saw them, but would also leave them intact on the message, so I could re-check them myself manually if I wanted. Oh well. It's not a limitation on functionality of any kind, just on convenience.
i believe if you used emacs to read your mail, you might get that sort of functionality since it's very user-customizable (is that a word?). i wrote myself a little perl wrapper to handle signing/encrypting outbound messages so that i don't have to type all the options and redirect the output or move output files. it's a one person thing. to each his own. i prefer to read my mail in a very un-adulterated form and i do all my sig verifying and decrypting by hand too. i'm weird that way. apologies to warload, you are right (imho) about the fundamental behavior of remailers. they shouldn't do things like that except perhaps atttemp to remove the outer armor layer if it is an encrypting/decrypting remailer. peas and goobles! - -- - --< "CYBERBOY" >-- andrew@ml.com (Andrew Brown) Phone: 1.212.449.0088 Fax: 1.212.449.8612 BATF plutonium AK-47 Kennedy colonel nuclear munitions Legion of Doom smuggle World Trade Center arrangements strategic PLO Rule Psix Ortega -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCVAwUBLuzxy7AuBPCxVEQ9AQGylAQAtrcF0ra1aG94Wnac3QFIVL1kmiOsNlGj zCMDAQxXExnBf5UhGct+EkDfO20kZAr2cgYwP5CH3YdcmKJ6J2nk9dvJaujZ2Dhf hPpug+uqnGC7R7V0ZsCcq9onpgYW+9lS4Do+EG1MIfz7j5pg541HBoBVBXOpKRXo nPPB+9OTkLw= =xOk1 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- To: andrew@riskdev.ml.com (Andrew Brown) cc: jrochkin@cs.oberlin.edu (Jonathan Rochkind), cypherpunks@toad.com Subject: Re: extra dashes in PGP-related blocks?
but wait! you can't actually verify the outer sig until you extract the key from inside the signed message? that's a bit more complicated. pgp will actually recognize a key embedded inside an armored, signed message but it won't (i don't think -- warlord?) play with the key other than tell you it is one.
Actually, PGP wont even do that. If the key is not in your keyring, it will complain about not finding it and output the de-armored message. If you want to add the key, you need to run it through PGP once to de-armor it, save off the output, and then add that output message to your keyring.
what these people should probably be doing is signing their public keys with their private keys to provide the same functionality (almost). what you have, otherwise, really is a two step process. you will have to strip off the outer sig layer to get the the key.
This is exactly what people should do. People should _never_ clearsign a public key block. If you want to sign it, sign the key inside the keyblock. When someone clearsigns a keyblock, they are making two passes over it to create it, which requires you to make two passes to read it in! - -derek -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBuAwUBLuz4Lzh0K1zBsGrxAQGSTgLDBtb7BWTSXbk5s8taH+2V8/MHpz/1BYIi AesXunQmFmJ+WXGNHbkfDK5CF2VzwiYyBaDxTkY90PwEV7cUAoNg3yCI8QJbsGX/ ZkO1kxTih46a1LucIe6U4EE= =Ov0C -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
From: Derek Atkins
but wait! you can't actually verify the outer sig until you extract the key from inside the signed message? that's a bit more complicated. pgp will actually recognize a key embedded inside an armored, signed message but it won't (i don't think -- warlord?) play with the key other than tell you it is one.
Actually, PGP wont even do that. If the key is not in your keyring, it will complain about not finding it and output the de-armored message. If you want to add the key, you need to run it through PGP once to de-armor it, save off the output, and then add that output message to your keyring.
yep, you're right (like i'm surprised or something, judging from your handle) pgp won't recognize it if you don't have it on your keyring. i do work from a sun and play at home on a linux system. i have too many keys at home to make my play testing easy and i got caught in that trap. it's just too easy to add a login and start playing with pgp in a simulated multi-user environment that doesn't have the pitfalls of the real world. - -- - --< "CYBERBOY" >-- andrew@ml.com (Andrew Brown) Phone: 1.212.449.0088 Fax: 1.212.449.8612 genetic Soviet fissionable plutonium DES Kennedy nuclear terrorist Waco, Texas NSA Qaddafi Marxist FSF ammunition South Africa -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCVAwUBLu0aY7AuBPCxVEQ9AQF7mwP9GY+DQtdjPLrF6XS+yJIXXhCaZELt1cDl HHscvAeJL1SQplYcrmCtE5N2QLPVtQh5Dty/6qjYZ21fs4nA5CrK+6Z0Mxfxqc4V eSKk1OVvtT6HjcNx7cFzNjrF0C8eWcnpd256Zgdjfn6DhSY4Jal9X+w4MZiSvCQS MRYy6GvfQho= =xCcd -----END PGP SIGNATURE-----
THUS SPAKE jrochkin@cs.oberlin.edu (Jonathan Rochkind): # # Does anyone know what it is that's putting in these "- "s, why it's putting # them in, and how to stop it? They're part of RFC934 and they are the correct standard way to encapsulate messages inside messages, short of using MIME. Many mailers produce & handle these correctly. The extra "- " are due to "Character-Stuffing the Encapsulation Boundary". What you&we need is filters to extract encapsulations that unstuff nested encapsulations. Relevant excerpt from RFC934 follows. --strick -- -- -- Network Working Group Marshall T. Rose (Delaware) Request for Comments: 934 Einar A. Stefferud (NMA) January 1985 Proposed Standard for Message Encapsulation ... Message Encapsulation ... Definitions: a draft forwarding message consists of a header portion and a text portion. If the text portion is present, it is separated from the header portion by a blank line. Inside the text portion a certain character string sequence, known as an "encapsulation boundary", has special meaning. Currently (in existing digestification agents), an encapsulation boundary (EB) is defined as a line in the message which starts with a dash (decimal code 45, "-"). Initially, no restriction is placed on the length of the encapsulation boundary, or on the characters that follow the dash. ... 2.3. Encapsulated Messages Each encapsulated message is bounded by two EBs: a pre-EB, which occurs before the message; and, a post-EB, which occurs after the message. For two adjacent encapsulated messages, the post-EB of the first message is also the pre-EB of the second message. Consistent with this, two adjacent EBs with nothing between them should be treated as enclosing a null message, and thus two or more adjacent EBs are equivalent to one EB. ... Character-Stuffing the Encapsulation Boundary It should be noted that the protocol is general enough to support both general forwarding of messages and the specific case of digests. Unfortunately, there is one issue of message encapsulation which apparently is not addressed by any forwarding agent (to the authors' knowledge) in the ARPA-Internet: what action does the forwarding agent take when the encapsulation boundary occurs within a the text portion of a message being forwarded? Without exception, this circumstance is ignored by existing forwarding agents. To address this issue, this memo proposes the following character-stuffing scheme: the encapsulation boundary is defined as a line which starts with a dash. A special case is made for those boundaries which start with a dash and are followed by a space (decimal code 32, " "). During forwarding, if the forwarding agent detects a line in the text portion of a message being forwarded which starts with the encapsulation boundary, the forwarding agent outputs a dash followed by a space prior to outputting the line. During bursting, if the bursting agent detects an encapsulation boundary which starts with a dash followed by a space, then the bursting agent does not treat the line as an encapsulation boundary, and outputs the remainder of the line instead. This simple character-stuffing scheme permits recursive forwardings. ... -- -- -- strick <...!{ihnp4,akgua,allegra,gatech}!techwood.org!strick> echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc --keithv@cs.berkeley.edu(?) --
participants (4)
-
andrew＠riskdev.ml.com -
Derek Atkins -
jrochkin＠cs.oberlin.edu -
strick＠techwood.org