3 ms·

Lest anyone seriously consider this, keep in mind that the success of cryptography is that you don't need any "blind faith". Properly designed crypto systems ar

Lest anyone seriously consider this, keep in mind that the success of cryptography is that you don't need any "blind faith". Properly designed crypto systems are those which don't force you to lean on any pillar that might give way unexpectedly. "Just trust the server to avert its eyes" is untenable. It's untenable because it's unnecessarily risky. We as a community can do better than to use someone else's design full of holes merely because it seemed to work. Crypto systems seem to work until they don't. And when they stop working, it's likely you'll never realize. But your adversary will.

jtheory 13y ago
"Unnecessarily risky" depends on what options you have available to you. The problem here (as I mentioned) is that a more solid solution is probably still years away -- and even then, email is a very difficult thing to secure end-to-end, so the possibility of user error exposing an email you imagined private will not go away for a very long time. My main point above was that while the original Lavabit did require you to trust Lavabit (who could be legally compelled to start logging passwords...), a roll-your-own version would shift that trust burden from a US company to you or whoever sets up your server. I'm not claiming it's the final solution -- just that it would be significantly better than nothing. There's value in continuing to push for full solutions; but that doesn't mean there's no value in options like this, just as yes, you're a fool if you rely on security by obscurity, but that's not the same as saying that it can't add to your security in a real world situation.
- sillysaurus2 13y ago
  that doesn't mean there's no value in options like this Actually, your proposal has negative value, because the danger is you might actually go on to implement the broken design and trick people (along with yourself) into believing it's trustworthy. a roll-your-own version would shift that trust burden from a US company to you or whoever sets up your server. You've shifted the burden, but away from commercial pressure is almost always a bad idea. Now instead of having a team of people thinking about security issues 24/7 and paying strict attention to their server configurations and minimizing their attack surface, you have only yourself. You may be capable, but most people aren't. And even the very best of us make mistakes. Once your server is breached, the security offered by this design drops to nil. Compromising the server compromises the security. That's a fatal flaw. It's no accident that all modern cryptosystems are based around the idea of "Here's your secret key. Don't let it get stolen." It's the strongest guarantee we have. It's incredible that it's even possible to get such a strong security guarantee: "As long as you don't let your private key get stolen or get MITM'd, it's impossible for anyone to eavesdrop on you." That's incredible! Governments for thousands of years have been wishing for such a thing, and now our generation finally has it, because we live in the future... and you're going out of your way to give it up. Your design is literally "transmit your secret key to the server while hoping it's still under control of friendlies." This kind of thinking is dangerous precisely because it tries to frame blind faith / hope / "probably won't happen to me" as a security pillar. But it's not a pillar. You can't trust hope. Your trust is the very first thing any adversary will subvert. In fact, if the cryptosystem is designed properly, adversaries won't have any realistic route of attack short of physically compromising the boxes you're receiving secret messages on. By fooling yourself into believing in the myth of "better than nothing", you've opened up an attack vector for the adversary. If you were to use a proper cryptosystem, then the adversary wouldn't be able to attack you. And since you're opening doors for the adversary, it would not be unfair to characterize that as "you're doing the adversary's job for them." I apologize for the negativity. Usually when people pick apart an idea, they're expected to present a better alternative. In this case I don't know what the better solution is, because it hasn't been invented yet. But you're talking about a cryptosystem. Cryptosystems fail silently, because adversaries break them without informing their victim. So all it takes is one misstep to completely lose: the adversary will be able to intercept everything, and you'll be none the wiser. By transmuting the trust guarantee from "don't lose your secret key" to "trust this central server," it exposes dozens of attack vectors. Every vector that leads to a server breach is now a vector that can subvert you.
  - xerophtye 13y ago
    I agree with your views, but i am a little confused by something (probably due to my lack of experience in web dev). When i log in to any site, don't i always transmit my password over SSL? I know good security systems match the hash of my password. But that means they store a hash, right? or does that mean i also transmit a hash? I think we transmit the actual password because this way, if someone breaks into their servers, and steals the passwords, they'd only have he hashes and not the passwords. And that point is moot if the server takes the hash as input. Please enlighten me.
    - jtheory 13y ago
      Yes, with probably no exceptions, all of the sites you currently sign into will at some point have your username and cleartext password in memory on the server. The server "averts its eyes", hashes the password and compares it to a stored hash to check it. If you're lucky. If you're less lucky, your password is just in cleartext in the database. Note: if a website can send you a "password reminder", as many of them can, this is the case. Furthermore, your data won't normally even be encrypted (or with some, e.g. Dropbox, they will be encrypted with keys that are available to the server even without your password). Hosted Lavabit was a flawed system -- they were vulnerable to the NSA forcing them to start logging passwords/private keys, and they were vulnerable to the NSA capturing all of their SSL traffic then demanding their SSL private key. They were also vulnerable to a malicious employee or other person with legitimate access to the server code who snuck in a bit of logging code. But they were still far more secure than just about any other web application you'll encounter. If they had configured their SSL for perfect forward secrecy, the NSA could have even confiscated their servers but would have been unable to get any user's emails. They could have installed any code they wanted on the servers, but still would only have been able to break into accounts where the users actively signed in beyond that point. If someone managed to steal a data backup from Lavabit, it would not have revealed any data. That's not true of almost any other site. That's part of why I find it frustrating when I try to point out the value of a private, fixed up Lavabit and am scorned for advocating an imperfect solution. Well, yeah! But it'd be miles ahead of where your email is now....

jtheory 13y ago

"Unnecessarily risky" depends on what options you have available to you. The problem here (as I mentioned) is that a more solid solution is probably still years away -- and even then, email is a very difficult thing to secure end-to-end, so the possibility of user error exposing an email you imagined private will not go away for a very long time. My main point above was that while the original Lavabit did require you to trust Lavabit (who could be legally compelled to start logging passwords...), a roll-your-own version would shift that trust burden from a US company to you or whoever sets up your server. I'm not claiming it's the final solution -- just that it would be significantly better than nothing. There's value in continuing to push for full solutions; but that doesn't mean there's no value in options like this, just as yes, you're a fool if you rely on security by obscurity, but that's not the same as saying that it can't add to your security in a real world situation.

sillysaurus2 13y ago
that doesn't mean there's no value in options like this Actually, your proposal has negative value, because the danger is you might actually go on to implement the broken design and trick people (along with yourself) into believing it's trustworthy. a roll-your-own version would shift that trust burden from a US company to you or whoever sets up your server. You've shifted the burden, but away from commercial pressure is almost always a bad idea. Now instead of having a team of people thinking about security issues 24/7 and paying strict attention to their server configurations and minimizing their attack surface, you have only yourself. You may be capable, but most people aren't. And even the very best of us make mistakes. Once your server is breached, the security offered by this design drops to nil. Compromising the server compromises the security. That's a fatal flaw. It's no accident that all modern cryptosystems are based around the idea of "Here's your secret key. Don't let it get stolen." It's the strongest guarantee we have. It's incredible that it's even possible to get such a strong security guarantee: "As long as you don't let your private key get stolen or get MITM'd, it's impossible for anyone to eavesdrop on you." That's incredible! Governments for thousands of years have been wishing for such a thing, and now our generation finally has it, because we live in the future... and you're going out of your way to give it up. Your design is literally "transmit your secret key to the server while hoping it's still under control of friendlies." This kind of thinking is dangerous precisely because it tries to frame blind faith / hope / "probably won't happen to me" as a security pillar. But it's not a pillar. You can't trust hope. Your trust is the very first thing any adversary will subvert. In fact, if the cryptosystem is designed properly, adversaries won't have any realistic route of attack short of physically compromising the boxes you're receiving secret messages on. By fooling yourself into believing in the myth of "better than nothing", you've opened up an attack vector for the adversary. If you were to use a proper cryptosystem, then the adversary wouldn't be able to attack you. And since you're opening doors for the adversary, it would not be unfair to characterize that as "you're doing the adversary's job for them." I apologize for the negativity. Usually when people pick apart an idea, they're expected to present a better alternative. In this case I don't know what the better solution is, because it hasn't been invented yet. But you're talking about a cryptosystem. Cryptosystems fail silently, because adversaries break them without informing their victim. So all it takes is one misstep to completely lose: the adversary will be able to intercept everything, and you'll be none the wiser. By transmuting the trust guarantee from "don't lose your secret key" to "trust this central server," it exposes dozens of attack vectors. Every vector that leads to a server breach is now a vector that can subvert you.
- xerophtye 13y ago
  I agree with your views, but i am a little confused by something (probably due to my lack of experience in web dev). When i log in to any site, don't i always transmit my password over SSL? I know good security systems match the hash of my password. But that means they store a hash, right? or does that mean i also transmit a hash? I think we transmit the actual password because this way, if someone breaks into their servers, and steals the passwords, they'd only have he hashes and not the passwords. And that point is moot if the server takes the hash as input. Please enlighten me.
  - jtheory 13y ago
    Yes, with probably no exceptions, all of the sites you currently sign into will at some point have your username and cleartext password in memory on the server. The server "averts its eyes", hashes the password and compares it to a stored hash to check it. If you're lucky. If you're less lucky, your password is just in cleartext in the database. Note: if a website can send you a "password reminder", as many of them can, this is the case. Furthermore, your data won't normally even be encrypted (or with some, e.g. Dropbox, they will be encrypted with keys that are available to the server even without your password). Hosted Lavabit was a flawed system -- they were vulnerable to the NSA forcing them to start logging passwords/private keys, and they were vulnerable to the NSA capturing all of their SSL traffic then demanding their SSL private key. They were also vulnerable to a malicious employee or other person with legitimate access to the server code who snuck in a bit of logging code. But they were still far more secure than just about any other web application you'll encounter. If they had configured their SSL for perfect forward secrecy, the NSA could have even confiscated their servers but would have been unable to get any user's emails. They could have installed any code they wanted on the servers, but still would only have been able to break into accounts where the users actively signed in beyond that point. If someone managed to steal a data backup from Lavabit, it would not have revealed any data. That's not true of almost any other site. That's part of why I find it frustrating when I try to point out the value of a private, fixed up Lavabit and am scorned for advocating an imperfect solution. Well, yeah! But it'd be miles ahead of where your email is now....