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

Not entirely. While the best cryptography is that which is secure against everyone (duh), there are a vast number of perfectly legitimate use cases for cryptography where it doesn't matter if the NSA can read your encrypted data.


I can't imagine any legitimate use case for crappy cryptography, and any crypto with a backdoor is crappy. If the door is there, anyone with the key can open it. How can you be sure who will get the key, or what their motives will be?

Good, modern cryptography offers a level of security unparalleled in the physical world, and at a processing cost which any computer can handle. Why would you intentionally choose something inferior?


The example often given is "MILITARY GRADE ENCRYPTION" - if tank driver Bob is given commands to shell a target those commands only need to be secret for a short length of time. It doesn't matter if the enemy can decrypt them by taking a week's time, because Bob will have attacked the target and gone by then.

This is, obviously, a really old example, because modern hardware makes encrypting things quick and easy, and decrypting things quick and easy. But imagine strong encryption in the 1980s - you had to balance strength with time with size and then try to cram it into low-specced hardware.


OK, yes, there is such a thing as "strong enough crypto for your purposes", and there are tradeoffs for computing power, etc.

My point was that there's no point in picking something with a known back door when there are perfectly good, non-compromised alternatives.


>How can you be sure who will get the key, or what their motives will be?

You can never be infinitely certain, but nor can you be certain your non-backdoored crypto is secure. There are cases where "the NSA leaks their top-secret backdoor to the internet" is a vanishingly small threat vector compared to other possibilities (e.g. rubber hoses).

>Good, modern cryptography offers a level of security unparalleled in the physical world, and at a processing cost which any computer can handle. Why would you intentionally choose something inferior?

You wouldn't. But if it later turns out the NSA has a backdoor in the algorithm you happened to pick, and for whatever reason you're unable or unwilling to change algorithms now, that still doesn't mean "you've given up already and cryptography is useless to you".


> You can never be infinitely certain, but nor can you be certain your non-backdoored crypto is secure.

True. But "is this algorithm crackable?" is a question that can be answered with experimentation and math. "Has the NSA lost its keys or its scruples, and if not, will they ever?" cannot be answered at all until you know you've been hacked.

> But if it later turns out the NSA has a backdoor in the algorithm you happened to pick, and for whatever reason you're unable or unwilling to change algorithms now, that still doesn't mean "you've given up already and cryptography is useless to you".

Maybe not, but it does mean you value something else more than you value security. Yes, everyone makes cost/benefit decisions about security. But if your answer to "whoops, whoever knows this trick can see all our bank transactions" is "meh, it would take like, a week to fix that," you're placing a pretty low value on security.


use case for crappy crypto: performance. even google uses RC4 for gmail.


RC4 isn't perfect, but it's immune to some attacks (e.g. BEAST) that block ciphers like AES tend to have problems with.

RC4 actually has a huge internal state. You could use a 1600 bit key with it if you wanted to.


I'd rather err on the side of keeping them in the dark all the time. Encrypting data differently based on whether I mind if NSA sees it leaks information. Specifically, that this data doesn't matter but that data does and NSA should focus their efforts on breaking that data or analyzing that social graph affiliated with the data.


Are there? If I knew something had a backdoor, I'd always wonder who else has figured it out.




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

Search: