Using GPG to create virtual email addresses
Sat Oct 4 10:41:01 2003
Ingo Klöcker wrote:
>On Thursday 02 October 2003 03:21, Jacob Anawalt wrote:
>>Jacob Anawalt said:
>>>Maybe there is some
>>>'light signature' option that would work better.
>>Let me expand on this idea a little more. It seems that a signature
>>must have something that says what encryption was used and some info
>>that allows the unencoder to know who's signature it is and then an
>>encoded hash of the data it is signing. When I sign a lot of data the
>>signature is large. When I sign very little data, it is small.
>That's wrong. The signature has a fixed size because it's just a hash of
>fixed size, e.g. an MD5 hash is always 128 bit and a SHA-1 hash is
>always 160 bit. This means in base64 encoding (which has to be used
>because email header must only contain 7-bit ascii data) the size of
>the signature is at least 22 bytes (MD5) or 27 bytes (SHA-1).
You're right. I don't know how I thought I saw what I did. My test
signature seems to have 64 characters, CRLF, 24 characters, CRLF, five
characters. I have no idea which part is the hash and which is the key,
or if it is all a key of the hash. If there were no data to hash, how
small could this be? Only 22/27 bytes smaller?
-----BEGIN PGP SIGNED MESSAGE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
-----END PGP SIGNATURE-----
>>either case there seems to be a substantial amount of header data.
>>If we pre-agree on an algorithm and we know externally the claimed
>>'owner' of the signature by looking at the MAIL FROM value, how small
>>can the signature be? Could it fit within (64 - size of GPG id + 1)
>>and be only local-part compliant data?
>>I would much prefer the double encrypted data idea, but if that is
>>out of the question then I would at least want a piece of signed data
>>accessable by the RCPT TO stage to help show the MAIL FROM was not
>For each key that is used for encryption the session key has to be
>encrypted with this key. This means that for each encryption key you
>have to at least add the size of the session key (which is at least
>another 128 bit, i.e. 22 bytes in base64 encoding).
So at least 44 of the 64 total bytes are just for the session key. That
doesn't leave much.
In my first email I said that protection of the data is not the issue. I
don't really care if my username is hidden, infact it may be
advantageous if it is not hidden. What I am looking for is a virtual
username (email address local-part) that is unique per sender/reciever
pair, and the identity of that pair is some combination of the two's GPG
information. Short of that, I would like a virtual username that has the
recievers identity and the assurance that the sender is who they say
they are built into it before making the decision to send a 4xx/5xx or
say 250 OK and accept the data portion of the SMTP transaction.
Somehow I would like to use or tie back into the PGP/GPG trust system.
Maybe I need to think of some parallel system where virtual email
mapings are stored and somehow those mappings are signed by the users.
>>There hasn't been a response yet so I wonder if I'm asking in the
>>wrong place or if people are reading this and rolling their eyes.
>>Even a quick note to say I'm way off base or looking in the wrong
>>direction would be appreciated. ;)
>Check out http://www.ietf.org/rfc/rfc2440.txt for more information.
This full scope of this document is a bit beyond my comprehension at the
moment. That is why I asked on this list. I am having a hard time
gleaning the answer to my question(s) from it. I did read that
implementations should not assume that the key ID is unique, so I won't
count on that.
Am I just hoping for something that isn't going to work?