81–90 of 113 posts
There's a very strong argument that encryption should only be implemented in software, in something GPL, LGPL, BSD or Apache licensed so that its full source code can be examined by cryptographers. I'm extremely wary of vendor supplied hardware-based "crypto" that is totally opaque with what's going on under the hood.
Who would have thought that proprietary firmware encryption implemented by hardware vendors would be crappy?
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…
Do you have any examples of bugs as bad as "password is checked with if statement" living for many years in widely deployed open source software?
BitLocker, ehh? Truecrypt.org, before its final demise, claimed it was obsolete due to FDE being native in Windows nowadays (ie. BitLocker ).
Earlier quoted context omitted.
I did not read GP as saying it was a binary choice, but rather a prerequisite. That is to say, without transparency, there can be no trust, but you can also have no trust with transparency. For someone like me, who is somewhat technically competent, but not a security expert, openness means that names and figures I do trust have the chance to examine whatever I intend to use and comment on it, observe it, and make as…
> I did not read GP as saying it was a binary choice, but rather a prerequisite. That is a binary statement though, saying it's a prereq is saying without it trust is 0. > That is to say, without transparency, there can be no trust, but you can also have no trust with transparency. That would clearly be incorrect though. Transparency is not needed to probe a system, it is mostly helpful in changing the incentive stru…
Maybe not strictly, but without transparency that probing becomes more difficult. It also suggests that there's something worth hiding, which is all the more reason to not trust it.
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…
https://www.viasat.com/products/encryption-kg-200r
Also has 2FA, a trusted path for PIN's, and emanation shielding. Being Type 1 means they focused hard on the RNG, algorithm implementations, firmware/protocol code, and error-handling code. Typical for high-assurance crypto. Just one of a few internal and external enclosures that do the job right due to security regulation for certain products. We can't buy them of course since they actually work and NSA uses them.
Then, unregulated vendors in private market are doing least they can for actual quality/security, doing most they can on marketing it, and making a killing with no or limited liability for preventable defects. Typical. I still maintain pretty much all of them are insecure and/or negligent until proven otherwise.
The high-assurance community selling to defense shows they couldve built better designs 10-20 years ago if they just followed standards, had a specialist for crypto, and hired some experienced breakers to check it. Peanuts for these big, companies' profits. Useful in protecting the IP that generates those profits, too. They still do this shit... Always will without better incentives and/or regulation...
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.
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…
> Crypto bugs of comparable severity have lived for many, many years in these systems. Do you have any examples of bugs as bad as "password is checked with if statement" living for many years in widely deployed open source software?
I did not know that BitLocker relies on hardware encryption if the SSD has support for it. That seems like an extremely dangerous default to have, especially as the implementation is closed source in most (all?) cases.
Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption
Configure use of hardware-based encryption for fixed data drives
Disabled