11–20 of 138 posts
"In contrast, when a system has end-to-end encryption, losing a password is catastrophic; it means losing all data in the user’s account." Um... what? Can't the user just reset his/her password, instead of a website emailing him/her the old password?...
From the article: "And while most types of software get more user-friendly over time, user-friendly cryptography seems to be intrinsically difficult. Experts are not much closer to solving the problem today than they were two decades ago." I'm not sure I agree that user-friendly cryptography is "intrinsically difficult." It doesn't seem like it would be hard for email clients and even the Gmail frontend to pop up a m…
Jeremy Kun recently wrote a good article summarizing some recent advances in encryption that make your statement somewhat less-than-entirely-accurate (scan for "differential privacy"):
http://jeremykun.com/2013/06/10/why-theoretical-computer-sci...
And, all you have done is make damn sure they keep your metadata records. Somewhere I read that sending encrypted email is an automatic flag, in the same category as using words that incite violence.
So to truly make it effective, encrypted email has to be the norm, not the exception.
Why doesn't anyone use it? The FIRST question is: Is it really a solution? The answer to that: NO, see: https://news.ycombinator.com/item?id=5879308
From the article: "And while most types of software get more user-friendly over time, user-friendly cryptography seems to be intrinsically difficult. Experts are not much closer to solving the problem today than they were two decades ago." I'm not sure I agree that user-friendly cryptography is "intrinsically difficult." It doesn't seem like it would be hard for email clients and even the Gmail frontend to pop up a m…
And where is the private key stored? On Google or Microsoft's server? What then would be the point? (I assume you'll answer that it'll be done client-side, but JavaScript cryptography is a whole mess of fail. But that's a separate issue.)
As for using js for public key encryption, I've implemented it for a client and didn't have much trouble. There are libraries that workaround the usual problems. What have you seen out there that would cause a problem?
Earlier quoted context omitted.
And if it is stored client-side, what happens when the user inevitably loses their key? You and I might have backups in multiple places, and on an encrypted USB stick in a bank vault, but my dad doesn't, and the next time he spills wine on his laptop, there goes literally all of his e-mail.
It's stored client-side, and as a back up on the central server, with a passphrase that is the users responsibility.
And there's the rub. "What do you mean, I can't ever see my data again? Why can't you reset my password?"
We know that true security means only the user has the key. But users don't all want that responsibility.
Why doesn't anyone use it? The FIRST question is: Is it really a solution? The answer to that: NO, see: https://news.ycombinator.com/item?id=5879308
This simply isn't true. Even if you (with likely a few orders of magnitude margin) overestimate total world computing capacity at 1e21 decryption operations per second it's going to take you about age-of-the-universe seconds to brute force a single 128 bit key. No amount of money or supposed 'exponential technology growth' is going to let any government brute force these anytime soon. And those are the smallest symme…
Earlier quoted context omitted.
And where is the private key stored? On Google or Microsoft's server? What then would be the point? (I assume you'll answer that it'll be done client-side, but JavaScript cryptography is a whole mess of fail. But that's a separate issue.)
Client-side, with a passphrase. A backup could be stored on the server or in your dropbox or wherever you'd like. It would be important, as part of the onboarding process, to communicate the need to keep the key safe and what happens to your old emails should you lose it. As for using js for public key encryption, I've implemented it for a client and didn't have much trouble. There are libraries that workaround the u…
That's the question about all this thing that I don't know how to anwer. Just extend it a bit... There are OSs that won't give root access to the NSA, encryption that the NSA won't be able to read and cloud services that the NSA won't be able to access even with cooperation of the CEO. Why none of them are widely used? And I don't accept the answer on the article as suficient. Yes, a few things are harder when you wa…
While that is an influencer, the reality is a bit more complex. That social drive we've been going through for the last ~5 years means that developers focus on customer value. Also, while there's little new after Snowdens' leak - other than absolute proof - there's not been much demand, and hence incentive to make things secure.
Earlier quoted context omitted.
This simply isn't true. Even if you (with likely a few orders of magnitude margin) overestimate total world computing capacity at 1e21 decryption operations per second it's going to take you about age-of-the-universe seconds to brute force a single 128 bit key. No amount of money or supposed 'exponential technology growth' is going to let any government brute force these anytime soon. And those are the smallest symme…
Can you back these calculations up with a known scientific source?
The only feasible thing against AES 128 right now would be if a flaw was discovered. This is also why it doesn't matter whether you use 128, 192, 256, or higher. If one is flawed, they all are. The reason we even have higher than 128 is simply because the government loves excessive amounts of redundancy. It lets them sleep easier at night, even if it's completely unnecessary.