Using GPG to create virtual email addresses

[Jacob Anawalt]

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-----
Hash: SHA1

hi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/foF8vdaM6UF7o8YRAlNpAJ4yCyBmuBfCg3zUFMXIU2qe0MH4jwCfV3+e
kvFfNHdoZSOTXm1aSxq2yK8=
=f32U
-----END PGP SIGNATURE-----

>
>  
>
>>In 
>>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?
>>    
>>
>
>See above.
>
>  
>
>>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
>>forged.
>>    
>>
>
>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?

--
Jacob