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

I take your point - though I was not intending to yell, but to represent my state of alarm and bafflement, as the original poster's worldview is both alien and frightening. It's as though someone were circulating one of those "modest proposals" to improve automobile security by installing a sharp metal spike on the center of every steering wheel, without realizing that these things are supposed to be jokes.

A universally trustable third party key provider might not be a bad idea in itself, but a national government - any national government, I was not specifically referring to the US government - seems about as non-trustworthy as any third party gets. To my way of thinking, the whole point of cryptography is to allow the weak to protect themselves from the powerful, and giving the organization which is at least nominally the most powerful agent operating in one's area the opportunity to poison your crypto before you even begin seems... counterproductive.




There's a power curve though, yeah? That most powerful agent can just drag you off and apply rubber-hose cryptography. Or just drone your ass. At some point, worrying about what else they can do is kind of a whateverburger.


They can do that, but it'snot cheap for them. Giving the government total, automated access to your communications - and that's what we're talking about here IMO - lets them (and you, admittedly) avoid the whole beating scene. In real terms, it would drastically change the balance of power.


> Giving the government total, automated access to your communications

Hello no. Absolutely not.

We're talking here about a state distributing USB keyz with a certificate to each citizen. The certificate is 'vouched' by the CA, it confirms the name of the citizen and it can be used to sign stuff thanks to private key cryptography.

One usage could be to access public websites, and use that USB key to log in and confirm your identity.


You're correct, I was distracted by some posts in this chain that seemed to be talking about using the key for encryption, not identification.

So the primary threat would be impersonation by the trusted party, which would erode the trust pretty quickly. I'm still a bit wary of this approach - do you think we'd manage to keep the keys from also being used for message encryption?

Where I live, there's actually a system somewhat like this in place - banks etc. can provide identity verification to websites upon request. You log in to the bank's system with your account and one-time pad they provide, and the bank tells you what information it will pass on to the requester. It seems pretty decent, and might actually be better than the USB key approach.


Certificates use asymmetric keys, they allow to exchange encrypted messages, among other things.

Now, that doesn't mean that we have to encrypt stuff. It could be used for the authentication/identification only if that's all one wants to do.

> It seems pretty decent, and might actually be better than the USB key approach.

Same thing. Look at RSA SecurID keys, they do certificate + OTP generators. I've had those at a previous organization, it was well integrated and nice to use.

The certificates provide the identity. A private key or an OTP allows for authentication.

There are multiple ways to handle the identity and the authentication with 2 factors. Exactly what to distribute and who will distribute it is an implementation details.


Sure, so the point is to avoid their notice. That's harder to do when they can snoop on your communications.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: