91–100 of 113 posts
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.
I wonder what this implies for SSDs that claim to support instantaneous ATA Secure Erase. Many SEDs, when issued this command, will simply discard their internal key and generate a new one, in theory rendering data irretrievable. I've encountered this method recommend over traditional wiping for reasons of security (you can't be sure all blocks are wiped when overwriting due to internal reservation), speed, and flash…
I don't see a reason to still use software encryption. I would sooner expect a backdoor in cpus rather than SSD. Almost nobody even has the capability to even analyze the microcode for modern cpus. It could contain a backdoor that stores N aes passwords in the cpu itself, sorted by the amount of data encrypted. Using AES-NI makes it relatively trivial. At worst, both ssd controllers and amd/intel cpus would have backdoors like that, but if that's the case there's nothing to be done.
Based on the presented analysis, TCG Opal encryption for the Samsung 850+ series appears to be secure. I don't see a reason to still use software encryption. I would sooner expect a backdoor in cpus rather than SSD. Almost nobody even has the capability to even analyze the microcode for modern cpus. It could contain a backdoor that stores N aes passwords in the cpu itself, sorted by the amount of data encrypted. Usin…
Why not? Software encryption can still be hardware accelerated (thanks to encryption instructions in the CPU), and it is fast enough to not be a bottleneck unless you have a very fast IO device (and very fast in this case mean either Optane or modern SSD's in RAID-0). Also, the impact in CPU usage/power consumption is low.
Earlier quoted context omitted.
Fips typically certifies that the algorithm is correct, but it can't be faulted for bad primes I think I rest my case.
How? I honestly don't follow your logic at all.
Earlier quoted context omitted.
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.
If someone lifted your drive - the thing FDE is supposed to protect against - tamper evident seals are not going to offer much in the way of mitigation.
Earlier quoted context omitted.
How? I honestly don't follow your logic at all.
Treating a certification of algorithm correctness as a certification of a well engineered product is a poor choice, because many security critical things in the product are not considered in the certification.
Earlier quoted context omitted.
I never used HW disk encryption (other than TPM) because I always seen it as unnecessary as in it doesn’t really improve on SW+TPM in terms of performance or compatibility and could only cause potential data recovery and security issues. There is no performance benefit in fact with modern CPUs that have crypto extensions it’s often slower and I never trust commercial solutions ever since you could dump the key from t…
The hw drives absolutely perform better if you have a raid.
Why would anyone be surprised about this? If you can't read a whitepaper, and inspect the algorithm to a degree where you can create your own provably-compatible implementation, or easily inspect the vendors source code, then you should just assume it's implemented incompetently and is completely and utterly compromised. The same goes for all cellular/mobile phone encryption standards, proprietary VPN solutions, prop…
Really, not so much. The problem here isn't so much with transparency as with delegating cryptography to non-cryptographers (or, for that matter, trusting that other vendors have had cryptographers review their designs). Based on the track record not only of open source cryptography but also of internal review of closed-source cryptography (that is: closed source software reviewed by the vendor that wrote it ), havin…
Well, ok, but who is a cryptographer then? How can a non-cryptographer tell who it's safe to delegate cryptography to? You can't even really complete a degree in cryptography (you can do a CS degree with a specialization in cryptography, but that doesn't mean all that much). There's no meaningful regulatory standards body there - the CISSP is a joke and is focused on producing compliance reports anyway rather than much to do with cryptography.
Litany of failures: * Firmware protection in drives is almost uniformly broken, so that they can get code execution (through JTAG or through hacked firmware images) routinely. This is bad, but shouldn't be the end of the world, since in the drive encryption threat model you don't want to have to depend on the firmware anyways. But: * Two Crucial SSDs encrypt the drive with a key unrelated to the password ; the passwo…