I think that’s a joke?

I mean, why even encrypt it in that case?

It’s not like the drive is a web service that will detect and block your password attempts…

No it's not a joke. If the password is sufficiently complex, it can't be brute forced in a reasonable amount of time. But it's still a way for you to get your data back having only the SSD on which it is stored.

Or, well, fine, let there be an active element. But let me export the master key then. It's my device, I have root access to it, I should be allowed to do that. And, yes, do still put the SSD into a slot.

> I mean, why even encrypt it in that case?

Yeah because your time machine backup drive that's encrypted with "just" a password (you did encrypt it, right?) is somehow more secure than an internal SSD encrypted in the same exact way.

> But let me export the master key then.

You can do this encryption shindig with the ability to export by not using FileVault and using your own encryption software - Apple just doesn't allow this by default. In fact, why only store it on the computer? Rclone can upload and replicate an encrypted (via a long salt + password) copy of your data to dozens of cloud providers. Your encrypted data could be on 3 cloud providers in 10 physically separate locations on 30 different hard drives at once, possibly even in separate hemispheres. Or chuck it into S3 replication and be in all 81 availability zones if you so wish.

I mean, just turn off encryption if that’s what you want.

I don’t think you grasp how the encryption keys are generated, derived, and stored.

And I doubt you are using a password the length of the key. Well, maybe you create a USB human interface device that fits on your keyring to type it for you. I do have something like that for one time codes, but if that is your sophistication level, then we wouldn’t have this discussion really.

I feel for the “it’s mine, I bought it” logic, and I miss the days when our rights were more absolute. But that’s not today.

There are key-derivation functions like PBKDF2 that are computationally expensive enough that it would make brute-forcing infeasible at best and impossible at worst. Perhaps only if your password is 1234 or qwerty, but even then it would take literal years.

> I don’t think you grasp how the encryption keys are generated, derived, and stored.

And you're wrong.

If data is not encrypted with a piece of secret information (usually a password) with enough entropy to keep it secret in the face of offline attacks, then it is as good as not encrypted, period. The hope that your hardware design is sufficiently complex and non-repairable to prevent your attacker from disassembling it and performing such an attack is not a replacement for proper encryption.

And if it is encrypted with a secret with sufficient entropy, then making your hardware design non-repairable serves no reasonable purpose.

You can easily limit password attempts by requiring a sufficiently difficult password hashing algorithm and then just use a secure passphrase. Nobody is breaking into my encrypted drives via a guessing attack (other attacks exist, but they ~all also exist on macs).

Encryption is based on math, not on some hardware gimmick. I'd absolutely clone my laptop drive and move it to a new one if I want to, having exactly the same setup.