Cryptographic Right Answers

I trust NaCl and, specifically, DJB-associated implementations thereunto. Lots of people have looked at it. I trust DJB and his cohorts to think about and mitigate footguns as much as practical.

STROBE is right about a year old. Maybe it's awesome, but it almost certainly hasn't been vetted sufficiently.

I seem to recall that most PAKE's relied on one of the nice properties that modular exponentiation has that doesn't work for ECC. IIRC, quite a few of the PAKE's tried to use ECC and fell into the trap and created a breakable PAKE.

The patent situation around PAKE's didn't help. Fortunately, those patents just expired.

> If you’re doing embedded you need a security person around.

Apple couldn't even get it right. They implemented an 3072-bit SRP that takes almost 15-20 seconds on Cortex M0/M3 series processors unless you have an exponentiation accelerator (Cortex-M4).

If Apple can't get it right, what chance do those with far less resource have?

A list like the parent article but tailored to embedded would be quite welcome.

True for so many things.

- My laptop has a 1TB disk, which is mostly full. I want to back it up.

- Some of the data on it is sensitive. The vast majority is not - for example, a large fraction of the disk is taken up by torrented anime videos - but I don’t want to separate out only the sensitive data to back up securely. Not only would that be inconvenient, it would be wildly insecure, since I’d presumably want some other, potentially less secure backup solution for the rest of the data, and it’d be really easy to miss some sensitive data and have it accidentally included in the insecure backup.

- Storing 1TB of data on Tarsnap for a year costs $3,000 (though after deduplication and compression there should be somewhat less than 1TB).

- Storing 1TB of data on Amazon Glacier for a year costs $48, which can be combined with various open-source encryption tools (of varying quality).

- Backblaze’s consumer backup product, which I currently use, costs $50 per year for unlimited storage; it supposedly does client-side encryption, though I don’t know how much I trust it.

- One of those prices is not like the others.

- I expect to have a larger disk in the future, and fill it up too; storing 2TB would double the Tarsnap and Amazon prices.

- If Tarsnap actually made the difference between my data being compromised or not, that would be worth $3,000 or $6,000 to me, and I do have the means to spend that much if necessary. But in reality, I’d expect it to only slightly reduce the chance of compromise compared to a high-quality alternative, and I don’t have so much money (or arguably, I don’t value security highly enough?) that I can reasonably spend so much on that small of a benefit.

- Why should you, the author of the post, or anyone else care that I’m stingy? Well, you don’t have to. But I’d certainly appreciate advice from experts about which of the alternatives are the best. In other words, what the right-est answer is that fits my budget constraints, even if it’s not actually the right answer. :) I don’t think the alternatives are all so insecure that it would be irresponsible to recommend any of them.

- I have nothing against Colin personally; indeed, I wish him the best of success. I do think his pricing model doesn’t do a great job representing his costs, since the time he spends maintaining the Tarsnap software and servers, and providing support, doesn’t scale linearly with the amount of data stored. But there’s no rule it has to; it’s his choice. It’s just that the result is a service that isn’t for me.

I think this is our largest point of divergence. If the world had sane TLS libraries, I would absolutely say "run TLS with all the backwards compatibility crap turned off" -- but we don't have sane TLS libraries. I am not confident in my ability to turn off all the unwanted "features" of SSL/TLS stacks, and I'm not confident that anyone can write code which will turn off all the unwanted features and keep them turned off in future library versions. It's not much of an exaggeration to say that I consider the OpenSSL maintainers to be actively hostile; if I have to run their code at all I really want it to be inside a sandbox.

Yes, writing your own transport protocol is nontrivial. But if you write your own transport protocol, you don't need to worry about "the user upgraded to a new version of OpenSSL and now your connections are all HeartBleeding". A sane library would have had this feature turned off by default; OpenSSL is not a sane library.

Guidance from experts from a use case perspective is difficult to find, as documentation is always product centric.

Additionally, many members of the HN community have exposure they aren’t aware of. If you represent that you “encrypt” data, many organizations consider data that isn’t FIPS unencrypted. A password database compromise of your scrypt protected passwords may be a problem if you just accept boilerplate terms when selling a few licenses to state, local or federal customers.