Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Why the fuck would you ever insert a government-provided USB key into any computer you actually cared about, much less actually use any government-provided key? The national government is the prime adversary. I mean, seriously, Alice and Bob want to communicate, and your solution is that they should use Eve as a courier!??


FWIW: your point--and it's a good one--is better made without the yelling.

And to answer you, though I don't speak for the person you were relying to: the U.S. government isn't even in my threat model. If the Eye of Sauron points my way, I lose. And so, given that as a prior, a universally trustable third party is not a bad idea. The implementation might totally suck (and I think it's a better practice to have a wide set of vendors and making the acquisition of such a key subsidized, rather than directly provided, by the .gov), but the central point of trust doesn't, and it isn't inherently a problem for it to be state-operated.


James Mickens has an awesome point roughly along these lines. It is one of my all time favorite lines about security up there with some Gene Spafford stuff.

""" If your adversary is the Mossad, YOU'RE GONNA DIE AND THERE'S NOTHING THAT YOU CAN DO ABOUT IT. The Mossad is not intimidated by the fact that you employ https://. If the Mossad wants your data, they're going to use a drone to replace your cellphone with a piece of uranium that's shaped like a cellphone, and when you die of tumors filled with tumors, they're going to hold a press conference and say "It wasn't us" as they wear t-shirts that say "IT WAS DEFINITELY US," and then they're going to buy all of your stuff at your estate sale so that they can directly look at the photos of your vacation instead of reading your insipid emails about them. """


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.


Not everyone is using encryption to stand up to the man... the national government isn't everyones prime adversary...


I wonder if there's a niche for a USB firewall dongle that you can plug anything in with and it will guarantee it's only treated as a file system or something else benign.


The device could be something like a modified USB condom, but with more processing power. It would have to have all drivers locked unless a sensor verified that nothing was plugged into the suspicious end, and use a fundamentally limited set of drivers. On connection, it looks for any filesystems on the suspicious device, mounts them, and offers them up by proxy as filesystems to the host machine. Nice idea.




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

Search: