Re: complete vs. detached GPG signatures
On Wednesday 14 January 2004 01:41 pm, Pigeon wrote:
...
> It doesn't specifically list an option to "make a complete signature". I had
> assumed that gpg -s was the "complete signature" option as the other options
> call themselves something different. I may be wrong here. The results I get,
> signing a particular text file of length 13021 bytes, are:
>
> "Make a detached signature":
> original-file.txt, 13021 bytes
> -- signing process -->
> original-file.txt + separate signature file, length 65 bytes, named
> "original-file.txt.sig", containing binary data
>
> "Make a clear text signature":
> original-file.txt, 13021 bytes
> -- signing process -->
> modified file, named "original-file.txt.asc", length 13340 bytes,
> containing original text + signature in
> "ascii-armoured" form, as for an inline-signed
> email
>
> "Make a signature":
> original-file.txt, 13021 bytes
> -- signing process -->
> original-file.txt + separate signature file, length 5105 bytes, named
> "original-file.txt.gpg", containing binary data
>
> From this, it looks to me as if "Make a clear text signature" corresponds to
> your definition for "complete signature", and we also have two different
> types of "detached signature", a short form which actually is called a
> "detached signature" and a much longer form which is just a "signature".
The original-file.txt.gpg file is complete; you could send it to someone
and it would be readable using GPG and your public key. It's only 5105
bytes because files are compressed before encryption (signed files are
encrypted with your private key, decryptable by anyone with your public
key). By signing and not clear-signing, you force anyone who wants to
read your message to use the tool that will also verify authenticity.
By clearsigning, you make signature verification optional.
> However, when I try it with a binary file, the results differ:
They don't really differ.
> "Make a detached signature":
> original-file.gif, 65166 bytes
> -- signing process -->
> original-file.gif + separate signature file, length 65 bytes, named
> "original-file.gif.sig", containing binary data
>
> "Make a clear text signature":
> original-file.gif, 65166 bytes
> -- signing process -->
> modified file, named "original-file.gif.asc", length 65448 bytes,
> containing original data in binary form +
> signature in "ascii-armoured" form
>
> "Make a signature":
> original-file.gif, 65166 bytes
> -- signing process -->
> modified file, named "original-file.gif.gpg", length 65377 bytes,
> containing original data modified in some way
> (the magic bytes indicating a GIF file are no
> longer identifiable) + signature (presumably!)
>
> So here it looks as if "Make a signature" _does_ correspond to "complete
> signature", but also modifies the data in some way; "make a clear text
> signature" is basically the same with the signature in "ascii-armoured" form
> and the data unmodified; and "make a detached signature" still makes the
> "short form" of detached signature.
This is the same as your text case; it's just that the .gif data wasn't
compressible.
> And why are there apparently two forms, short and long, of the "detached
> signature"? Is it that the "long" form actually contains the text as well as
> the signature, but the text is no longer recognisable as such because it has
> been compressed? And the GIF file, being compressed already, can't be
> compressed further, so it looks as though something different has happened
> when in fact it is doing the same thing?
Yes.
Most encryption first compresses the data both to hide underlying patterns
(good compression is virtually indistinguishable from random data) and
to reduce the amount of data to encrypt. Further, compression of
well encrypted data is not possible (encrypted data also appears to be
random), so compression done first is the only way to save space and/or
bandwidth.
--
Rob
Reply to: