http://qs321.pair.com?node_id=246481


in reply to Re: Re: Affero
in thread www.Affero.com and interview from slashdot

The difficulty with signatures (both digital and not) is that they can be duplicated, and even beyond that accepting one involves a lot of trust. In essence, a signature is not a way to ensure that a particular document came from someone in particular, but a way to establish a paper trail in case there is ever any doubt or whatever.

When I write a cheque, and sign at the bottom, the teller at the bank who eventually looks at it doesn't know for sure that is my signature. In fact, I knew someone who had her credit card stolen, and the thief used it four times, signing in four completely different ways. So a physical signature is just a way to say "Until someone says otherwise, this document is from Lai."

Thing with digital signatures is, they're digital. Therefore, they can be instantly copied with 100% accuracy given just one example of the original. The fact that in order to make a signature at all useful you need to give it to people, means that even security through obscurity is impossible. You can't copy-protect anything because the act of giving someone a document is copying it.

So, digital signatures can't be used to identify documents as coming from a specific source, unless they hold a reference to a database somewhere (either belonging to the signer or some third party) which keeps track of every document legitimately signed with that signature. Without a way to verify that not only is that signature on that cheque identical to mine, but that I personally made a record of having signed it, the signature is about as secure as the one at the bottom of this post. Then we get into ways of ensuring that the database you're checking is in fact a valid one...

crypt('LAI','Na') crypt('__END__','Cl')

Replies are listed 'Best First'.
Re: Affero
by Abigail-II (Bishop) on Mar 28, 2003 at 15:47 UTC
    A digital signature is quite different from a normal signature. Someones normal signature is always the same, and independent of the document signed. However, a digital signature is different for different documents. It's closely related to encrypting the document, except that in this case, you don't encrypt the plain text, but you encrypt a digest, and attach the encrypted digest to the document. The digest can be decrypted using your public key (assuming you are using some well-known public/private key encryption technique, like PGP).

    Assuming the encryption algorithm can't be broken, and your key isn't compromised, noone else can create the signature. The signature can be copied, but the signature is worthless without the plain text, copying to another document doesn't sign it. Also, if the original text is modified, it no longer matches the signature, so it prevents someone from modifying the original document and pretending you signed it.

    Abigail

      ++Abigail-II for clarification of some of the details

      I know you're right, comparing digital signatures to analog is a bit like comparing apples and oranges. The main point I was trying to make, though, was that of server involvement, and I was kinda tripping over myself writing half a sentence at a time while working. Let this be a lesson to me to post only when I can dedicate a few minutes to writing and when I can put in more brain power and attention than not :o)

      LAI

      __END__
Re: Re^3: Affero
by zby (Vicar) on Mar 28, 2003 at 15:23 UTC
    The thing is that the digital signature is inherently paired with the message it signs - so it won't work for any other message. You can copy it together with the orignal message but this would not make any harm to the poster.

      Update: I realize I'm doing sort of an apples-oranges thing talking about server-client relationships and signatures. Please ignore my brainfarting i.e, this node) until I manage to get my wits together and express myself more clearly.

      Of course the signature is paired with the message. But the logic that says "This signature matches that document" can't be on the client side, or it can be faked. That's why I suggested something like a database connection to verify authenticity. It's the digital equivalent of my bank calling me up and saying "Hey, did you write a cheque for $100 to the EFF?"

      Rule #1 of any client-server based encryption work or security-related programming: Don't trust the client.

      LAI

      __END__
        Rule #1 of any client-server based encryption - you have to trust someone.

        The normal flow of events is to sign a message digest with a private key. Given the corresponding public key, I can be gaurenteed the message is valid and it is from the person who sent it --- as long as I trust the public key. Now you could distrust the public key and do some type of db lookup. But PKC is set up so that as long as you trust the signer of the public key (the cert authority), you can trust the public key. The only time you would need to do any type of lookup was either the sender did not include the public key or if you failed to trust the sent public key. You could then do some type of database (ldap) lookup to retrieve a known, trusted public key for the sender.

        -derby