>The correct solution is to use free software cryptography on top of these things.

If implemented correctly, "hardware" encryption can be more secure than "free software cryptography". The most obvious benefit is protection against brute-attacks, which you can't meaningfully implement with software. Not to mention added protection of biometric authentication as a second factor, compared to typing a password into a possibly untrusted machine.

▲

close04 5 hours ago | parent | next [-]

“Correctly” is a big caveat. Almost no HW implementation is auditable in any way.

My baseline assumption is that even the good commercial products are only secure from a non-determined attacker, not TLAs. Anything safe from TLAs is what’s being sold only to them.

▲

gruez 5 hours ago | parent | next [-]

>Anything safe from TLAs is what’s being sold only to them.

I think you're overestimating how much backdoors there are in products vs actual bugs. As we've seen with with recent vulnerability disclosures, there's plenty of bugs that were put there unintentionally.

	▲	traverseda 4 hours ago \| parent \| next [-]
		We don't know how many of those bugs were intentional, or known, by the three letter agencies.
	▲	close04 4 hours ago \| parent \| prev [-]
		I didn’t make any mention of backdoors or bugs, intentional or accidental, or the prevalence of either. You aren’t wrong but you addressed a point I never made. The point was that there are special products, implementations of already known algorithms, sold only to TLAs. They have the code validated to the Moon and back, unlike the commercial products.

▲

steelframe 4 hours ago | parent | prev [-]

If you own an Android device, your disk encryption is most likely provided via a UFS/eMMC hardware component known as the "Inline Cryptographic Engine" (ICE). Reputable device manufacturers validate the ciphertext that these devices write out to storage in a test environment by running the plaintext through a software encryption process using the same encryption keys as the OS provides to the ICE. If the ciphertexts match, then it would be unlikely that the hardware encryption engine isn't doing its job right.

▲

my123 3 hours ago | parent | next [-]

The inline crypto engine is in the SoC for the phone case. Inline crypto engines for OPAL on the storage device side have a far worse security record.

▲

close04 4 hours ago | parent | prev [-]

That’s not validating an implementation. You’re just comparing the output for a few known inputs to known results.

The hardware is still a black box and you’ll never know how it behaves in conditions you didn't test against.

▲

steelframe 2 hours ago | parent [-]

Why do you trust the device you're posting this from? I presume you use it for private browsing, banking, email, and so forth.

	▲	buran77 22 minutes ago \| parent \| next [-]
		That's not a good faith argument. A general purpose computing device is unavoidable, it's exceedingly difficult to build anything close to it. Encrypted storage is trivial without dedicated hardware, using open, validated software solutions. The CPU that software runs on gets far more scrutiny than the obscure encryption engine on the USB stick. Even better, if bugs or backdoors are found you don't need to throw out your encrypted stick, just update the software or reencrypt.
	▲	magicalhippo 2 hours ago \| parent \| prev [-]
		You didn't build your computer from discrete transistors[1]? [1]: https://www.megaprocessor.com/index.html

▲

Sopel 4 hours ago | parent | prev | next [-]

you're not gonna brute force an AES256 key

if you have a bad password that's a user issue

▲

gruez 4 hours ago | parent | next [-]

You're not gonna remember a AES256 key either (or at least not many of them), not to mention the ergonomics associated with entering a AES256 key. The whole point of security chips like google's titan m2 or apple's secure enclave is to strengthen weak passwords (eg. 6 digit pins) so they offer comparable security to 256 bit keys, without having to enter 256 bit keys.

▲

kalaksi 4 hours ago | parent | next [-]

Password isn't used directly as key. The key is derived with PBKDF.

	▲	gruez 3 hours ago \| parent [-]
		>The key is derived with PBKDF. Which doesn't do shit even if you're using argon with 32 GB memory usage or whatever. NSA is always going to be able to out-compute you. Not to mention you need a difficulty level that's usable for daily use, but the NSA can brute-force at their leisure, possibly decades in the future.

▲

SV_BubbleTime 4 hours ago | parent | prev [-]

>You're not gonna remember a AES256 key either

Did we wake up in a world without key derivation functions to turn passwords/phrases into keys?

▲

SV_BubbleTime 4 hours ago | parent | prev | next [-]

>you're not gonna brute force an AES256 key

There was a great article around last week about PDFs using randomly generated keys that ended up using non-secure random number generators and the effect was the only unique portion of the key is was 9bits, and obviously forceable. I wouldn’t even describe this between burrito bites activity as “brute”.

The point being “AES” doesn’t mean secure. Secure through the whole implementation means secure. People fuck up crypto all day, calling out a specific cipher doesn’t mean much.

▲

4 hours ago | parent | prev [-]

[deleted]

▲

TacticalCoder 4 hours ago | parent | prev [-]

> If implemented correctly, "hardware" encryption can be more secure than "free software cryptography".

Well you can use open-source / free software cryptography to encrypt and decrypt using a secret key which you do not need to remember and which is safely stored behind a secure element.

And there are quite a few people doing just that.

It's immensely more secure than trusting Lenovo or Microsoft or whatever company.

And you can have your secret on the secure element protected by biometric auth too (some do offer just that).

And there are devices like that with a tiny attack surface that accept biometric (like your fingerprint) to unlock the secret.

To get the best of both world you trust the HSM with one thing: the secret, and that's it. And you use open-source software and protocols (like GPG and OpenSSH) with that secret.