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?
Again, the comment I responded to made an absolute claim but, like you, had no supporting evidence. Unless one of you can produce some evidence it’s hard to support the belief that this is based on data.
If you read the thread, note that I’m not taking a side other than finding it absurd to claim that all open source products are inherently better than all proprietary products with no analysis or data.
Unless you know the true ratio, you can't claim that open source projects are better either. Or that one has advantages over the other when it comes to cryptographic security.
I'm not GP and I'm not arguing for either side, just pointing i tout.
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.
