Taher Elgamal, the father of SSL, discusses how asymmetric cryptography was first used to secure web transactions and how those same protocols have now been adapted to rid the world of passwords.

How Taher met Jim Clark

So I knew Jim Clark since my Stanford days. I was a grad student and he was teaching classes. He will not remember me at Stanford because I was one of many students, but I remember him and I wanted to know what the world had to offer and get to understand things so I went to an IDC conference in late 1994. 

I actually pinged Jim after and I said, "Hey Jim, you may or may not remember me, but I was one of your students. Why do you talk about cryptography? Your presentation had a lot of errors in it." So he invited me to his office. The company was called Mosaic Communications at the time. 

We chatted and I ended up consulting a little bit. The company changed its name to Netscape and I ended up joining as a chief scientist in early 1995. And then the company says, "You know, by the way, we're going to put transactions on the Internet," and we're looking at each other and say, "How on earth are we going to do that?" 

Building SSL

We ended up building the SSL protocol as a solution to that problem. SSL survived until now, it was modified a few times to answer security issues. We forgot one thing. We didn't pay a whole lot of attention to who the consumer actually is. 

We had an option in the SSL protocol for the Amazons, for the server side, for the shopping cart, to ask that consumer who they are and that resulted in the password dilemma that we have today. So this is actually the number one security issue in the digital world today by far, and if you look at any threats, any breaches, anything that happened in the entire world in terms of security issues, 99% of them were because of a password problem. 

At the time we just did not picture what the world would look like in the year 2020. We also did not picture attacks that were developed later on. We did not know that social networking was going to be a thing, none of that stuff existed. There were no mobile phones when this thing was done.

We did not claim that the solution was going to solve every single security problem that will come later on because we did not know what these would be, but we focused on solving the most important security issue when you're actually conducting a transaction. You want to make sure it is the right amount, the right person, the right entity, the right account number, and basically conduct the transaction, and that's what we focused on. 

The system was already designed to understand the new certificates and you know your certificates are used for authentication in the SSL protocol but certificates can also be used to sign things and signatures, which is actually the nature of what a certificate is, are perhaps longer term things. 

Self-assigning keys: a novel idea

So the idea of self assigning a set of keys for each user to choose a bunch of keys and build their own certificate, so I can sign things and send them to you, is actually novel. We've always built certificates based on somebody, a trusted third-party issuing certificates always, because I couldn't do a certificate for myself and claim to be Bank of America and show it to. How do you know if I'm Bank of America or not? So the trusted third-party was actually very important in terms of authenticating the entity, the server side. 

We thought we had to do that with the client side and the nature of this new idea is that we actually don't. The only thing you need to do is to register the key with the backend that you care about and then when you continuously use the same key you know that this is the same entity. 

So the idea of the self-signed certificate on the user side, so that the user gets to decide which devices they own and they control their own keys and their own identities and their own data is kind of awesome. 

Now we're in a privacy driven world now there's so many privacy things. So anything that is user driven is going to be looked at very favorably. So the fact that we can enable each user to be their own certificate authority and in the language we use and issue their own keys, register the keys they want with whoever they want to register with, you've done the initial step and then you can prove yourself ongoing by just showing showing the key—not showing the key itself but showing the effect of the key, which SSL does actually. 

Like Albert Einstein used to say, "When you arrive at the simplest way to solve a problem, you know you got something."