I was talking to a colleague at work earlier this week & realized something awesome with crypto a...

[G+_John Mink]

I was talking to a colleague at work earlier this week & realized something awesome with crypto/authentication.  After discussing it further, it occurred that it may be what Steve has been teasing us with.  While I don't have the knowledge, influence, or desire to propose a formal spec & make it as detailed as Steve's will be, I want to get my idea out there before Steve says his!

 

The answer to username/password problem is public/private key!  How's this work for authentication? It's not a huge stretch. When you create an account (say a gmail account) you would give your public key as the "credentials to authenticate".  Then google creates a public key/email association, so your public key would be tied to that gmail account. This means that your email is easily encrypted & only you (with your private key) could actually read the email.

Now what happens when I want to send an email to Yahoo (who, in this theoretical scenario, also has this public key credentials)?  Easy, Google & Yahoo simply have a public key exchange, so they can easily/quickly exchange public key/email address pairs as needed and without needing to trust ANY 3rd party.

 

This keeps anybody out because even Google/Yahoo don't have our private key, only our public key (and that’s supposed to be known)!  So there's NOTHING hackers/spies (be they white or black hat) can get from them that they cannot get from tapping the open internet!

 

Now, if you're worried about something like a public library with key loggers, there is a work around for that too.  So far we're using the private key as a password, but that's non-ideal as it remains the same. 

Instead, we should only use it for the initial setup.  This setup will use a strong set of one time passwords, each of which has the details for the next password.  So when you create your account with your public key, you negotiate a pad of one-time passwords…or even a single one time password.   Using a onetime password, you could send a message or whatever and also agree on the next one time password. This means there’s no keyring to save or hide!

If you get out of sync you simply hit the "Forgot my password" which would be replaced with "lost my one time password(s)" and that would be inherently authenticated with your private key & the cycle continues!  Of course, if you lose your private key....that's a problem!

It occurs to me as I’m writing this idea out that email addresses would act like a domain name to the public key IP, meaning they would simply be a lookup.  You could “link” email accounts via simply showing they have the same public key.

Like I said, not 100% fleshed out, you’d need a good open source program to generate the public/private key.  Then you’d need a universal algorithm for encryption/decryption, or ideally a set of algorithms & let the services negotiate the strongest available algorithm, as already exists on other protocols.Finally you’d need a way to change your public/private key in case it the algorithm grows weak over time & needs to be changed…or is otherwise compromised.

 

I’m sure I’m missing a million points, but the more I think about it, the more it makes sense.

 

As always, the trick is getting the industry to adopt such a standard, and I hope Steve can pull that off!

[G+_John Mink]

Very true, but it is letting the servers do a bunch more work, making the user experience easier.

 

Plus with the current PGP setup we still have passwords & account credentials & whatnot, so it's not making anything easier...this would (if applied to everything) also remove last-pass since you'd only need to remember your private key.

[G+_Dory Goldberger]

John Mink if you can remember your private key, you probably need a better and longer key.?

Also under this idea how would google monetize if the servers can't sniff it for ad placement?

[G+_John Mink]

Dory Goldberger that's a good question, i suppose it'd work in a similar way as it does now, where you https or something to Google & then they do the encryption on sending. Of course this breaks encryption, but I don't see how else the current business model will work with encryption. Maybe if they focus on metadata?

[G+_John Mink]

Dory Goldberger true, but isn't that true of passwords too, honestly?

[G+_Dory Goldberger]

Is gmail really the place for you secure communication?

If google wanted to they could do like yahoo and offer a paid gmail service. While yahoo just adds some functiins like pop access, adding a tier that was properly secure for the times when you need it to bewould be interesting. Buisness deals and house purchase documents are very different then asking my wife whats she wants for dinner. So everything has a place.

 

As for the private key I would rather store a very strong key in something like keepass that I can put a strong but memerable password on as well as a key file for a second factor if nessasary.

[G+_John Mink]

Dory Goldberger just picked then because they're a well known service... But that's certainly a point about my ability to pick examples.

 

Also, no reason you couldn't have your private key in keepass. Then you remember the password & get the key when you need it... That could certainly work. ?

 

I do like the secure tier, but it's alot of work for an occasional message.