Hacker News new | past | comments | ask | show | jobs | submit login

Here are several reasons why we should never do that.

The first reason is that those IDs would then become massive theft targets. Because they're uniform, it provides economies of scale for criminals to figure out how to extract the private key from the ID, then pickpocket IDs and extract the private keys from them (or worse, figure out how to do it from across the room when it's in your pocket) and then we're back to square one.

Associating public keys with names, which is in general completely unnecessary (the key itself is the identity), also becomes a separate centralized single point of failure. Anyone who compromised that system could associate their own public keys with your name, and the more centralized the system is the more powerful the likely attacks against it would be because compromising it then has a higher payout.

A large centralized system like that is also inherently slow to change, which would result in a catastrophic failure if a vulnerability was ever discovered in the cryptosystem it uses or its implementation, because not only would every system relying on that system become simultaneously vulnerable, they would all have to be updated, which for a large bureaucratic system could take months or years. In the meantime you're forced to choose between continuing to operate the vulnerable system and being subject to an unlimited amount fraud, or shutting it down and having systems across the country offline for a lengthy period of time while everyone reimplements their interfaces with it.

A universal public key is also itself a huge privacy vulnerability. We already have this problem with social security numbers, which were never intended to be used outside of social security but have already entered use as a means to correlate surveillance data about a person. But social security numbers at least are considered sensitive data because they're used as shared secrets. A public key authenticates by use of the associated private key, so knowing the public key doesn't impair its security properties which would almost certainly lead to relaxed security requirements for their disclosure, and thereby further enable problematic public and private mass surveillance by using the public key as a universal database index.

The far better solution is to use public key cryptography, but have a separate keypair for each relationship. So you have a bank card and it has your private key associated with your bank account, which allows you to authenticate to your bank. Your employee ID allows you to authenticate to your employer. But then nobody can steal money from your bank account with your employee ID or break into your office with your bank card. And a general compromise of the security used by the DMV doesn't allow criminals to break into power plants and airports and banks and police stations, because they're not all using the same system. This vastly reduces the scope of compromise.




> figure out how to extract the private key from the ID,

I never said the private key would be embedded inside the ID. In fact, I would think a paper copy at home would be most appropriate.

> Associating public keys with names

DMV, Passports, Banks, RealID already get our fingerprints. In fact, these could be SALT to the private key kept separate.

I hear your argument about centralization, but that genie is already out of the bottle. Making it better is a good idea, no? Also, if any vulnerability occurs, I can go back to DMV and register a new PP pair.

Still, I do like your idea of having PP pairs beyond just centralized entities.. start using them everywhere you have an account.


> I never said the private key would be embedded inside the ID. In fact, I would think a paper copy at home would be most appropriate.

As soon as such a thing existed, people would want to start using it for everything, and nobody is going to want to do cryptography with pen and paper. It would end up in a card or device people would carry on their person so they could use it and then it would be a huge theft target.

> DMV, Passports, Banks, RealID already get our fingerprints.

It's the same problem, you'd have a central database mapping public keys to fingerprints and then it's a single point of failure/compromise. The attacker could get your fingerprints from the DMV, associate their public key with them and then start impersonating you using two factor authentication because they have your fingerprints and the corresponding private key to the public key the DMV has on record for you.

Let each entity maintain the mapping themselves. Your employer has a computer that says the ID badge with public key 1234 is yours. You don't need the DMV to do anything there, and then nobody can cross-correlate anything and if anybody breaks it they only compromise one system.

> I hear your argument about centralization, but that genie is already out of the bottle. Making it better is a good idea, no?

Getting rid of it is a better idea. Or start by making the centralized system worse and more restrictive so people use it for fewer things and replace existing uses with decentralized alternatives, and then get rid of it.

> Also, if any vulnerability occurs, I can go back to DMV and register a new PP pair.

They stole all your money, broke into your company and stole the trade secrets, filed separate fraudulent claims against your home, life, car and medical insurance policies, took out a second mortgage on your house, sold the title to your car and gained access to your computer where they found some information they're now using to blackmail you.

You can go to the DMV and change your public key, but that's closing the barn door after the horse has bolted. Better that only one of those things happen than all of them, no?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: