Using GPG to create virtual email addresses
Fri Oct 3 14:34:01 2003
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).
> 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).
> 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.