Rosewater

repudiating non-repudiation

One of the most frequently sited benefits of public-key based digital signatures is that they are theoretically non-repudiable. Unlike conventional cryptography, where the same key is used to encrypt and decrypt, public key crypto uses a pair of keys: one that encrypts and one that decrypts. The advantage of this is that the originator can create a key pair, keep one key private and make the other public. When the holder of a private key encrypts a document with the private key, people can verify the that the encrypted document came from the holder by simply decrypting it with the public key from the key pair. In practice, digital signatures are a bit more complicated, but that's the core of it. With conventional crypto, the encrypter would be able to deny having encrypted the message: the sender has to know the encryption key in order to decrypt it, so they might also have been the one to encrypt the document. With public key crypto, the holder can't deny having creating the encrypted document -- only they have the private key, after all. Very cool, right? Unfortunately, that's just the theory. The practice is significantly less elegant. To turn the theory into practice, your ability to rely on non-repudiation hangs on your ability to do three things right: implement the technology, put in place proper business practices and agreements, and make your case in court. So, there are three questions you should ask: Relative to other means, how much does using digital signatures lower my risk over other technologies? how much will it cost me to setup up and operate a the business end? how will my chances in court be affected? If you're not put off by your answers to the first two questions, then you should definitely take a long, hard look at the third question. While the signer may not be able to deny that their private key was used to sign the document, they may be able to repudiate the signature on a host of other grounds: They didn't keep their key secure and someone stole it; they didn't understand their obligation under their user agreement to keep the key secure; they didn't understand what authority they had granted signatures generated with their private key, etc. I suspect you'd have better luck enforcing an agreement built around usernames and passwords than you would one built around private keys and digital signatures. So, what technology would give you the biggest return (reduction of risk) on your investment? The theory of non-repudiation is great, in practice, it tries to do something that is unnatural: it tries to transfer all the risk of a transaction to one party -- the signer. My bet is that you get better returns by accepting a more natural distribution of risk.

The history of your threat model

Ian Grigg posted a screed about how the threats SSL is intended to counter (network eaves dropper) are not the most common threats that web users actually face (trojans, worms, and other host-based security problems). He talks about the need for page based security, rather than connection based security. Historical note: at one point there was a page-based alternative (SHTTP) but it was more expensive and not backed by the winning team. Due Diligence provides a history of the SSL threat model, blaming it on bad business strategy. Unfortunately, the account is factually wrong on several points. STT wasn't Microsoft's answer to SSL. Microsoft already had, actually, already implemented SSL. In fact, Microsoft and Netscape had even managed to do some interop testing by the time STT was under way. STT was a joint project between Visa and Microsoft. It was Microsoft's attempt to get a piece of each credit card transaction on the Internet; it was Visa's effort to beat MasterCard to the punch and gain market share. Rumor had it that Visa had given Microsoft some favorable terms in exchange for an exclusive arrangement. Not to be left out, MasterCard teamed up with IBM, Netscape, GTE, and Cybercash to create their own protocol, SEPP. As it happens, MasterCard and Visa are both directed by the banks they serve, and those banks (many of whom offered both Visa and MasterCard), weren't keen on implementing two similar technologies (especially given all the infrastructure they required). It quickly became clear that this was not an area where Visa and MasterCard were welcome to compete. And, thus, SET was born -- even American Express and Discover were invited to the table. It was initially was a simple merging of the two protocols, but quickly expanded to cover all the specific requirements of each of the credit card associations. And this was it's downfall, because, at the end of the day, the card associations weren't the customer for this: the merchants and the member banks were. While SET did a great job of covering the risks the card associations were worried about (e.g. merchant fraud, stolen cards), it did nothing for the banks or the merchants, who were expected to pay the majority of the cost to implement SET. It didn't help SETs case that it was slow out the gate: by the time it was ready, consumers had ample opportunity to become comfortable with the risks of the internet (which, in point of fact, were small -- merchant's eat fraudulent transactions on internet and phone orders). Merchants had also gotten a sense for what fraud would cost them and found that there were cheaper ways to mitigate the risk (e.g. checking for real email and street addresses) than SET. So, SET was DOA. I know this because I had a small to role to play in these events -- a great experience to have early in my career. Great lessons learned, the most significant of which was cool technology is nice, but if you don't know who your customers are and understand their needs, you're wasting your time. WRT to Ian Griggs post: From my point of view, SSL was never really intended to address the risks we know of today. The funny thing was that the risks that people were afraid of on the internet were largely not an issue -- already well handled by the credit card processing model (which distributes risk to those who benefit the most and are in the best position to make informed decisions). SSL was just the placebo for the thing that people found most unnerving -- dangling their private bits out on the new and unknown internet.

taxes and gifts to children

Last month, my wife and I had our first child (Kate). I'm looking at trying to get a college fund set up, possibly with a cash gift that might be a nice deduction for us. I found this page which seems to have some useful links:

Fool.com: Gifts To Children