earthrise

This post really needed to be written -- I get this question a lot, too. I like the blind indexes concept, it saves you from having to find some weird deterministic encryption mode (like using an HMAC of the message as the CBC mode IV or something insane like that) and it's more flexible by allowing the fuzzy indexing.

Security is half a technical problem and half a usability problem (for developers). We need more emphasis on the usability half.

For example, we should be doing everything we can to ease the mental burden of writing secure code. Whenever we can reasonably eliminate the possibility of a vulnerability, we should. Even if someone has to be an idiot to make the mistake, just don't make it possible to make the mistake in the first place. We should also try to reduce the amount of potentially-malicious input, reduce the amount of options and special cases, etc. Simplify.

Usability improvements pay off multiple times. They make developers' jobs easier because there's less code to write and the code that does get written is easier to reason about. They make security auditors' jobs easier because there are fewer "dumb" mistakes to check for, and that means more of the audit time can be spent looking for deeper flaws.

(Nitpick about the phrase "validating user input": The user's input should never be trusted, but that doesn't mean we should write code to try and decide whether the user's input is "safe" or "unsafe", as that can be impossibly-hard depending on what's happening after the validation check. The code should just be secure no matter what the input is.)

The salt would need to be kept secret so it shouldn't be called a salt, it should be called a key. The benefit of Scott's solution compared to this is that you don't need to deal with all the usability problems associated with keeping something secret (where should it be stored on the server? how should it be backed up? how often should it be changed? etc.)

I usually consider this a "vulnerability" in the sense that the author probably intended to use AES and so they may have misunderstood the mcrypt API. Most importantly, they might have wanted AES-256 and missed the fact that mcrypt selects the key size based on the size of key you give it.

That does not appear to be the case this time, however, since the page acknowledges (in an update) "256 bit block" and the fact that it isn't AES. So I should probably make note of that in the CryptoFails post.

I'm unsure how well the analysis of AES (and the attacks against it) carry over to Rijndael-256, so I'd be hesitant to actually recommend it without asking a cryptographer... but, like you, I'd be very surprised if it was a source of vulnerability itself.

Yeah, when I made this program two years ago I never intended it to be taken this seriously. I added a big disclaimer to the readme.

Hi everyone, I'm the author of that software.

I really didn't want this to blow up. It's absolutely NOT a solution to getting raided by the police. While that was the original inspiration for writing the tool, I was half-joking when I wrote the README about it being a defense against law enforcement.

I've moved the code into a different branch and added a disclaimer to the README. The most important line of the disclaimer is: "If you need to rely on SWATd, you have already lost."

Say we're trying to download the PHP source code from php.net. If all that's protecting us is SSL, then if an adversary compromises the php.net servers (happens all the time, and actually has happened to PHP), they can immediately replace all the downloads with backdoored copies. Whereas with a PGP signature, the key can be stored off-line (even on an air-gapped system), so that even if the web server is compromised, the adversary can't make me believe the file is legit.

PGP can also be used in a trust-on-first-use manner. Get the public key once over an insecure channel, and if the attacker missed that single opportunity, you're safe until the key changes. With SSL, on the other hand, you're at risk every single time you make a connection, because any of hundreds of CAs has the power to sign that certificate, and as above, you have to assume the web server isn't compromised.

Another reason PGP is important is mirroring. Big F/OSS projects let others' volunteer mirrors. Even if those mirrors support SSL and the transport from the author to the mirror is encrypted, there's absolutely no guarantee that the mirrors themselves are not malicious. The mirrors could be backdooring their own files. The fact that you have an SSL connection to the mirror doesn't do anything to prevent this. But with PGP signatures, you're assured the files come from the software's developer, and haven't been tampered with by the mirror.

So the difference is: SSL secures the connection between your browser and the web server. PGP ensures you're getting the file the software developer intended you to get. It's a semantic difference.

I'd also argue hard against `curl | sh` for (assuming it exists) the psychological effect of teaching users that it's OK to pipe random things from the web into sh.