PEM also reveals who signs messages, even when the message is encrypted. In other words, if I send you a PGP encrypted message which I also signed, the signature is hidden under the encryption. You do not know who sent you the PGP message (assuming a cypherpunks remailer or equivalent was used) until after you decrypt the first "packet" and gaze inside. PEM, on the other hand, reveals in the clear who signed the message, outside of the encrypted portion. Also note that to be PEM compliant, you *must* always sign your messages. So much for anonymous encrypted messages... There is something to be said for the PGP encapsulated approach...
PEM, [...] reveals in the clear who signed the message, outside of the encrypted portion. Also [...] to be PEM compliant, you *must* always sign your messages.
Perhaps it's time we polished the edges, added a few of the features that are lacking, and wrote up up an RFC for the PGP message format. Some features I'd like to see in PGP are: The ability to send an encrypted message to multiple recipients without duplicating the entire message. The most logical way to do this would probably be to encrypt the random IDEA key once for each recipient. There needs to be a facility for having multiple signatures on a single document without making the signers sign each others signatures. Besides the obvious application of removing a signature from a document, this would also facilitate things like petitions where many people could asynchronously sign a single document, and latter assemble all the signatures together. It should be possible (though certainly not mandatory) to hide the recipient's identity entirely. The message format needs to allow for alternate forms of encryption (besides IDEA). Furthermore, the (shared key) algorithm used to encrypt a message should be hidden in the RSA encrypted part of the message along with the shared key. Ideally, a list of algorithms could be given which would allow the message to be optionally compressed before being encrypted, or encrypted two or more times with different algorithms. If I'm confused and the PGP message format already supports some of these features, please correct me. brad
Perhaps it's time we polished the edges, added a few of the features that are lacking, and wrote up up an RFC for the PGP message format.
This is being worked on....
Some features I'd like to see in PGP are:
The ability to send an encrypted message to multiple recipients without duplicating the entire message. The most logical way to do this would probably be to encrypt the random IDEA key once for each recipient.
This has been in PGP since version 2.2! Read the docs! To use this feature, you just execute: pgp -e filename user1 user2 user3... And it will encrypt the file to all users, using the same IDEA key and RSA-encrypting it to the different recipients.
There needs to be a facility for having multiple signatures on a single document without making the signers sign each others signatures. Besides the obvious application of removing a signature from a document, this would also facilitate things like petitions where many people could asynchronously sign a single document, and latter assemble all the signatures together.
This has been discussed. It is possible to do this in the PGP protocol, but it has not been implemented. What this means is that you could write the code to generate the proper packets to do this, since those packets are legal, but this code has not yet been written. It is in the works, but I wouldn't expect to see it in the 2.4 version.
It should be possible (though certainly not mandatory) to hide the recipient's identity entirely.
This, too, is in the works, albeit a little more difficult to accomplish.
The message format needs to allow for alternate forms of encryption (besides IDEA). Furthermore, the (shared key) algorithm used to encrypt a message should be hidden in the RSA encrypted part of the message along with the shared key. Ideally, a list of algorithms could be given which would allow the message to be optionally compressed before being encrypted, or encrypted two or more times with different algorithms.
This is already supported. There is a byte that represents the secret-key algorithm (and there is a byte that represents the message-digest algorithm as well). It would be simple to add, say, triple-DES to PGP as an alternative encryption algorithm. As for hiding the encryption algorithm, this is a possibility but I don't see it happening. The data structures, I don't believe, allow for this currently. (I'd have to go back and double check this one).
If I'm confused and the PGP message format already supports some of these features, please correct me.
Thats why this message was composed. Enjoy! -derek
participants (3)
-
Brad Huntting -
Derek Atkins -
remail＠tamsun.tamu.edu