re: Non-Repudiation Discussion
Ryan Pierce / Townsend Analytics Ltd. / Archipelago LLC
7 Apr 2003 5:14PM ET> Hello,
> I read the power point presentation written by MR Towsend and there is one point understand.
>
> “Accidental” disclosure of private keys makes non-repudiation close to impossible to achieve.
>
> How is it possible?
>
> From what I know, non-repudiation in PGP and in SSL is provided by digital signature. The message goes through a hash function that produces the digest and the digest is encrypted with the Private key of the sender.
> The recipient decrypt the digest with the sender's public Key, and then compares it with the one himself has computed with the hash function. and that provides non repudiation.
>
> Is this sensitive for private key disclosure?
Non-repudiation means that someone cannot falsely deny having made a transaction. Over time, my opinion has changed, and I really do not believe that non-repudiation is possible with today's technologies.
Assume that I use my 2048 bit PGP key to sign a transaction to buy a large quantity of a stock, send the order to you, you check my PGP signature, see that it is valid, and then execute the trade. That stock later becomes immediately worthless due to a surprise bankruptcy. Having bought it on margin, I'm in considerable financial trouble, and I need to do anything possible to (fraudulently) contest the transaction.
Is your firm safe? Yes, you think, because you have my digital signature on the transaction. That proves I made the transaction, right?
NO! Here lies the fundamental misconception of public key cryptography. That digital signature DOES NOT prove that I signed the document. I certainly cannot memorize my private key, nor can I perform the RSA operation in my head. An RSA signature only proves that a microprocessor with access to my private key signed the document. This is a subtle, but crucial, difference.
There are several ways that a document could be signed with my private key, without my knowledge or consent:
1. Someone could have factored my public key to obtain my private key. With a 2048 bit key, that's considered computationally infeasible. (It makes sense to require big keys of your counterparties, since doing so generally eliminates any serious claim they can make that their keys were factored.)
2. Someone could have stolen my private key.
3. Someone could be exploiting a weakness or trojan horse in my encryption software, and could be tricking my computer into signing an order that I've never seen.
So I can take my private key and anonymously post it all over the Internet. Then I can stand up in front of a judge and claim that my system was compromised, an attacker stole my private key, and entered the losing trade. While you can certainly can prove that some microprocessor in posession of my secret key signed the losing order, you cannot prove to an impartial judge that I directed the microprocessor to sign the order.
Now this doesn't mean that digital signatures have no value. Rather than speaking of non-repudiation, I find it more useful to discuss ease of fraudulent repudiation. For example, in a situation where there are no digital signatures, I could fraudulently adjust my logs so that a buy order on a losing trade would appear as a sell order. At this point, it would be my word against my broker's word. I can blame my broker, and I don't have to admit to any fault.
With, say, RSA signatures on each message, in order to repudiate a transaction fraudulently, I'd have to admit that my private key was hacked. This would inevitably mean that I'd lose quite a lot of face.
So while digital signatures can't guarantee non-repudiation, they can help shift the scales substantially to make fraudulent repudiation of transactions much more unattractive.
> Why do we have to sign FIX messages with a shared secret instead of private key when we use PGP-DES-MD5?
This was implemented because doing a public key computation is generally a slow process. Signing every order with PGP would likely result in a substantial slowdown of many firms' FIX engines, while an MD5 hash of an order and a shared secret can generally be computed fairly quickly.
Even SSLv3/TLS generally reserve actual public key computations to session negotiation; it's my understanding that SSLv3/TLS uses a similar approach of hash functions with shared secrets exchanged through RSA.
