upvote
I've been required to use similar products due to government regulations. Personally I never trusted them, and I would have loved to take 15 minutes poking around in them, but it was the government who mandated their use for their data so ultimately it was out of my hands.
reply
Was it probably a IronKey? They had a Homeland Security grant, I've used one then. To me software had some advantages. Easy backup of the encrypted data without a dependency to the hardware. IIRC this was somehow solved on the IronKey. Not a black box for the user which have to trust. My main problem with a software solution for me is the entry of the password which I have to do on a probably compromised computer.

The original IronKey (later sold to Kingston) seems to have be cracked. A team / company called Unciphered managed to break a IronKey in a attempt to offer such a decryption to Stefan Thomas who had 7002 bitcoin on this key. This was then worth then 235 million dollar (now >500 million), which is of course a VERY strong motivation. [1]

The Lenovo case of course seems not to be bad implemented security but no security at all, especially if they advertise with encryption, which I found on a Asian Lenovo website where still there are still some specs of the key [2]. A good method if you want to damage your reputation.

[1] https://www.wired.com/story/unciphered-ironkey-password-crac...

[2] https://tk.lenovo.com.cn/product/1003497.html

reply
I like using the Apricorn keypad flash drives. Like this Lenovo, it's doesn't connect until you unlock it. Password entry is via the built-in keypad so no software is necessary. It's also got a small battery so you can unlock it before you plug it which could prevent someone sniffing the USB 5V rail for any noise. Needing an app makes the Ironkey useless for anything that isn't running a normal desktop OS.
reply
All the devices with keypads are extremely vulnerable to hardware MITM of the keyboard/display. Same with the fingerprint ones. They rarely have secure elements so the PIN is also a weakness. And of course many of them just store the key internally instead of using a key stretching function, or don't do enough rounds, or use weak randomness.

For key entry you really want mutual TOTP or a separate ignition key, like a yubikey, that you insert into the drive.

reply
> This was then worth then 235 million dollar (now >500 million)

Says a lot about Bit Coin volatility that that didn't really narrow how long ago it was.

2023 for anyone else who wonders (the linked wired article is worth a read though).

reply
Ironically the DOJ isn’t great at this. Infamously they just gave California an encrypted thumb drive with 20,000 names of, allegedly, non-citizens registered to vote.

The password was included on a sticky note in the package.

reply
The requirement was that the data be encrypted, not that it would be secure.
reply
That's just the thing; these devices aren't meant to be -good-, they're meant to check boxes.
reply
Thats true for all govenment regulation, thats also why I prefer not to give up my data at all Esther than relying on pricycy laws.
reply
We used these: https://apricorn.com/aegis-padlock-usb3

They work well in high security environments because you can allowlist the vendor and product id of only these hard drives, and you don't have to set up procedures where people HAVE to encrypt their drives before use.

So cost-wise it makes sense.

But for personal use? BitLocker / VeraCrypt all the way.

reply
MS stores your Bitlocker keys on Microsoft servers now if you ever login with a OneDrive account, at least they were.

And MS has handed those keys over to law enforcement before.

reply
That's how it works by default, but you don't have to use it that way. BitLocker can be used securely.
reply
You should not be trusting a company or product that has been known to give up keys, regardless of how you are using it. Too risky
reply
people rolling windows and saying high security environment in the same phrase are likely not aware what is a highly secured environment in the first place so it doesnt matter where those keys are -_-. I have never encountered these types of devices nor windows in a high secure environment. free software and BSD. Occasionally Linux but that is also mostly avoided or manually tampered with / built and hardnened to get around its rubbish security. sometimes there is an alternate deployment linux based (very hardened) in the event of a security issue on the other more secure platform in case that one does happen to spring a leak. (might be more needed now its easier to pick apart these systems).

some highly secure environments have connections comming from networks that sport windows. usually they will come in via something like a data diode so whatever comes in can physically not come out because its so risky to allow even such a network to connect to yours....

perceptions of what is highly secure can vary a lot depending on what a person has encountered. if you ever come across a place that is really secure u'll immediately know the difference.

ive never seen a highly secure corporate network and have seen close up what security is implemented in fortune100 etc. its a doozey. they just pay vendors with big retainers for IR etc. to be compliant and insured. that is not security. (and they spend millions on that which is funny as hell)

reply
>nor windows in a high secure environment

I have. We had an air-gapped network for ingesting and processing the deliverables and results of security audits and pen-tests at work. It was running windows and not Linux/BSD like the laptops of the pentesters, because most of our customers were MS shops so all deliverables we got from them were mostly documents, apps and files that were designed for Windows apps or had better compatibility on MS Office, and businesses stay solvent by conforming to their customers' needs instead of fighting them.

reply
I suppose it works if your threat model is corporate espionage and not state actors.
reply
You can probably implement your own these days. I would use a model to generate a requirement document, then human review, then generate an implementation plan, then human review, then take it to build. Have a different model to a code review and testing. End with human code review and testing.

You could make your own BitLocker conforming to your requirements without relying on or trusting any cloud or corporate entity.

reply
And then turn Mythos onto your code to make sure you don’t have vulnerabilities? That’s a lot of faith in the security of LLM-written code that I wouldn’t have in human-written code.
reply
The point is the code is there in front of you. You can audit it, study it, turn mod and after model loose on it, do whatever you want. You’re going to have to compile it so you need to trust the compiler but at least it’s not some cloud provider.
reply
Been daily driving this for a month

https://github.com/hparadiz/nexus-6p-biokey

I mean it's better than this sdcard thing at least.

reply
The overwhelming majority of people who use USB sticks for things are likely aware of security and the concept of encryption. But the idea of being able to use “free software cryptography on top” may as well be a trip to Mars.
reply
Most "normies" I know think that open source cryptography is less secure because it's "open" (if they even know open source cryptography is a thing at all). No amount of trying to explain to them how more eyes on the source code generally equals safer encryption will sway most of them in the slightest.
reply
Explain to them that all the commercial products are using the open source code under the covers anyway.
reply
>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.

reply
you're not gonna brute force an AES256 key

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

reply
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.
reply
Password isn't used directly as key. The key is derived with PBKDF.
reply
>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.

reply
The NSA is only going to spend so much time trying to crack my specific password on 100 billion dollars of hardware. If I have a 6 word password (barely harder than XKCD) (72 bits), .1 second local hashing, and their computer is ten billion times faster than mine ($10 per my-computer-equivalent), in a month they'll get through 0.006% of the search space.

The "decades into the future" part is a much bigger threat than their ability to out-compute me in the short term.

reply
>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?

reply
>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.

reply
deleted
reply
> 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.

reply
“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.

reply
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.
reply
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.
reply
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.

reply
Why do you trust the device you're posting this from? I presume you use it for private browsing, banking, email, and so forth.
reply
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. Even better, if bugs or backdoors are found you don't need to throw out your encrypted stick, just update the software or reencrypt.

Because what I said above might sound like black magic to anyone who knows nothing about the topic I will expand.

The CPU on which the software runs gets far more scrutiny than the obscure encryption engine on the USB stick. And it's possible to validate the software encryption with minimal effort. Verify the output with various software implementations of the same algorithm, ran on different CPUs. They have to be compatible and can't all have the same bug or backdoor.

An encrypted stick is impossible to validate by the end user. They have no access to the CPU encryption engine or the raw storage so can't know the algorithm implementation, or the output to disk format which is probably proprietary.

reply
You didn't build your computer from discrete transistors[1]?

[1]: https://www.megaprocessor.com/index.html

reply
>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.

reply
We don't know how many of those bugs were intentional, or known, by the three letter agencies.
reply
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.

reply
A good reason you have to use these sticks is stand-alone devices.

For example, you need to print something; take some data from an oscilloscope or other instrument.

Your alternatives are to connect those devices to your network or some devices run Windows you can alt-tab out of and install your own software. Given risks and complexity of those, a hardware encrypted USB stick is the least bad.

reply
You don't necessarily want free software and traditional cryptography for such use cases.

The traditional free software approach to cryptography is "derive the key from a passphrase; require the user to make the passphrase strong; if the passphrase is weak, put the onus on the user."

This works well for HNers, but is terrible for normies. What normal users want is a locked down chip (potentially running open source firmware!), which securely stores something like an AES key protected by a 6-digit pin, which gets erased after 10 unsuccessful attempts and cannot be cloned. This is how TPMs, Apple's secure enclaves and bank and SIM cards work. This kind of design did more to bring full-disk encryption to end users than any free software ever did.

reply
These kinds of product are great for disaster recovery. E.g. your day to day use is software encrypted with a key bound to a TPM and stored in a central crypto store that verifies devices state before giving it out etc etc but then what do you do when all that shit breaks? Having the root key material on a hardware encrypted device on a safe is a great way to be able to restore from failures.
reply
We have to use the ones that cost 8x more than regular ones and are certified by something that our industry approves.
reply
There's a guy with some Bitcoin that knows about a model, I'd trust that one.
reply
The ironkey at least has reasonable independent evaluations.
reply
Software is insecure in many scenarios because endpoint security is abysmal. Of course, a USB stick with fingerprint reader cannot be secure but there is no way around hardware-based cryptography with independent key entry if you need real security. Then again, this won't help you if the secrets are transferred to the insecure endpoint anyway.
reply
[dead]
reply