Live data from Hacker News

Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

zdnet.com

61–70 of 113 posts

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#61
post #59

Earlier quoted context omitted.

Are there regulations in any industry which require the name of software authors on binaries/products, or at least the name of someone who approved the security claims made by the device?

Buy drives with FIPS 140-2 certification. At least then you know a third party lab has reviewed the implementation.

It is almost definitely not the case that FIPS certification of any kind reliably informs you that a capable crypto engineer verified the implementation.

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#62
post #45
post #42

Earlier quoted context omitted.

1. There's a difference between kicking the tyres and looking under the bonnet of a car, and taking the schematics and building your own. It's easier to show something is crap than convince people that it is good when you're outright hiding things. If the things you aren't hiding (well) are crap, then god only knows how terrible the things you are really hiding are. 2. Making claims based on the calibre of the compan…

I don't know many people who actually work in cryptography who believe that verification is cheaper and easier than building systems. People absolutely do, for the most part, trust DJB because of his track record. Find 10 people who have adopted Poly1305 and ask them what Poly1305 does better than GCM. That's not to say their decision is uninformed; rather, they've delegated a very specialized part of the decision th…

> Find 10 people who have adopted Poly1305 and ask them what Poly1305 does better than GCM.

Two things, one of which cannot be credited to Poly1305 directly.

1. Poly1305 is easier to implement without introducing side-channels (modulo integer multiplication on some CPUs; in which case, I defer to Thomas Pornin on how to avoid them).

2. The Chapoly constructions that use Poly1305 do so in a way that leaking the one-time Poly1305 key doesn't buy you much. (This is the one that cannot be attributed to Poly1305 directly.)

Others may have better or different answers. I implemented it in PHP [1], so anyone reading this thread should keep that in mind. :)

[1] https://github.com/paragonie/sodium_compat/blob/f3b2d775a50d...

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#63
post #61
post #59

Earlier quoted context omitted.

Buy drives with FIPS 140-2 certification. At least then you know a third party lab has reviewed the implementation.

It is almost definitely not the case that FIPS certification of any kind reliably informs you that a capable crypto engineer verified the implementation.

Respectfully, I'll need a citation on that.

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#64
post #63
post #61

Earlier quoted context omitted.

It is almost definitely not the case that FIPS certification of any kind reliably informs you that a capable crypto engineer verified the implementation.

Respectfully, I'll need a citation on that.

Sure. Find any device crypto vulnerability, and check to see if the device was FIPS 140-2 certified. For instance, Infineon with their batshit RNG (the ROCA vulnerability).

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#65
Here's what I love the most about this: If you have a full-disk encrypted Windows laptop, which is fully powered down (or hybernated), and the laptop contains PHI, _and_ you lose the laptop, then you probably do _not_ have to report it as a data breach.

(https://www.hitechanswers.net/hipaa-doesnt-require-data-encr...)

But with this revelation, if you have an affected SSD, and you are running Windows, then losing such a laptop may now be a reportable event.

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#67
post #64
post #63

Earlier quoted context omitted.

Respectfully, I'll need a citation on that.

Sure. Find any device crypto vulnerability, and check to see if the device was FIPS 140-2 certified. For instance, Infineon with their batshit RNG (the ROCA vulnerability).

So looking at the ROCA vulnerability, it looks like the vulnerability wwas with how the primes were generated, not with the correctness of the actual crypto algorithm. Fips typically certifies that the algorithm is correct, but it can't be faulted for bad primes.

So I'm still going to have to ask for an actual citation

Edit: I also didn't see where that device is Fips certified either

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#68
post #64
post #63

Earlier quoted context omitted.

Respectfully, I'll need a citation on that.

Sure. Find any device crypto vulnerability, and check to see if the device was FIPS 140-2 certified. For instance, Infineon with their batshit RNG (the ROCA vulnerability).

Does your argument boil down to any review process that doesn’t catch 100% of problems is worthless? I don’t think anyone claims fips certification is always going to garuntee perfection but it’s better than nothing. It also stipulates things like tamper evident seals which would mitigate attacks that need jtag access to muck with firmware.

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#69
I spent a lot of time this year looking at ssds with encryption support. I’ve come to the conclusion that what is really needed is to separate the crypto hardware from the storage. Make a 2.5” drive sled for example that takes any m.2 and adds cryto to it. Then you can choose the best supplier for both crypto and flash independently.
Post reply on HN