The Secure Enclave on the T2 chip was used to store secrets that were supposed to stay inaccessible, even to someone with physical access.
If you use a strong password to encrypt your drive you should still be safe, unless Apple did something really stupid. The password is used as a one-way hash to generate the key.
However if you can login with Touch ID and they find a way to use known SE exploits, it's compromised. Your fingerprint isn't a secret that gets hashed – instead it's verified by the SE which also holds the secret key for the drive.
Some one from Apple, I'm sure you read this. Please answer this ASAP. I rely on mac and FileValute for professional use at work. Need to know the state of this exploit.
Software encryption is very often much easier to rotate than integrated solutions. When all the TPM chips were broken, Windows stopped using them for BitLocker, but didn't reencrypt any of the affected disks. They're just as vulnerable as they were.
Software encryption is also harder to protect without a trusted boot path. My point was just that this isn't a simple binary decision but rather something which requires review and defense in depth.
Go count how many CVEs have come out for OpenSSL, GNUTLS, LUKS, etc. and ask whether you’re offering helpful advice. Security is expensive and there are no silver bullets: at the end of the day you need a lot of skilled work and being open source doesn’t magically get that for free.
Are you seriously claiming that anything short of omniscience is useless? In most fields people deal with incomplete data on a daily basis and this is no different. CVEs don’t tell you everything but they definitely give you more than zero, and more to the point, the many vulnerabilities in open source projects suggests that the very broad but completely unsupported claim I was responding to is based on ideology rather than reasoned analysis.
> the many vulnerabilities in open source projects suggests that the very broad but completely unsupported claim I was responding to is based on ideology rather than reasoned analysis
Does it? In order to claim that, one would have to have some idea of (a) the ratio of disclosed vulnerabilities to true vulnerabilities discovered in both open source, accessible code vs closed source, hardware locked code, and (b) the relative ratios of disclosed vulnerabilities.
Do you have any idea what either ratio might be? 1:1? 4:1? 1:4? 100:1?
I disagree. There are times when either no open-source solution is available, or the open-source solution is unmaintained, or not popular (thus not under much scrutiny) and you don't have the resources (time and skill) to audit it yourself.
As long as the incentives of the developer of the security scheme and the end-user are aligned (so no backdoors), I would trust a widespread, proprietary solution which appears to stand up to significant attacks (the solution being widespread means there are lots of efforts underway to crack it) more than an open-source implementation that nobody uses.
As it stands now, from my understanding, the failure case of the proprietary solution is the same level of security as the best case of the open source solution. So I don't see your point. Open source isn't any better.
Open source full disk encryption can be password cracked without limitations just like a hacked T2 chip. A sleeping open source full disk encryption machine can be accessed with enough skill to pull things out of frozen ram, etc.
I want not note, that ZFS is not full disk encryption.
ZFS native encryption was designed to allow secure backups via "zfs send | zfs receive" mechanism, so it encrypt only data blocks, and not metadata.
LUKS and GEIL are full-disk encryption systems, and if you need FDE, you must use them under ZFS, not ZFS native encryption.
If you use a strong password to encrypt your drive you should still be safe, unless Apple did something really stupid. The password is used as a one-way hash to generate the key.
However if you can login with Touch ID and they find a way to use known SE exploits, it's compromised. Your fingerprint isn't a secret that gets hashed – instead it's verified by the SE which also holds the secret key for the drive.