>as I run macOS
How is the FDE story on macOS? Isn't it closed source - how can you tolerate that as a cryptographer? (Not saying Linux is perfect, cryptsetup doesn't have a secure AEAD mode)
How is the FDE story on macOS? Isn't it closed source - how can you tolerate that as a cryptographer? (Not saying Linux is perfect, cryptsetup doesn't have a secure AEAD mode)
It isn't like the average hard disk permits padding oracles and chosen plaintext/ciphertext attacks to be mounted easily, except of course if you are storing disk images in the cloud, but then you're using the wrong tool anyhow - do crypto at the file level where you aren't constrained by sector sizes.
Really, I'd say that 99% of the uses of block device encryption would be better served by using a filesystem that supports encryption natively. The remaining 1% is for block devices that handle the encryption in the hardware.
You asked how someone can trust a crypto implementation that isn’t open source. I replied to the to it directly: it actually is open source. Personally I see the source being available largely irrelevant but I replied to exactly what you asked for.
Your second question is an entirely different topic, which is how you can trust that something isn’t backdoored. Notably, this has nothing to do with whether source is available. How I would typically do that is by inspecting the compiled artifacts themselves, which is the same whether the code is available or not. Of course, this requires that the OS or the AP or the crypto engine isn’t backdoored, for which there exist more involved verification processes. Whether this is possible to do in general is a difficult research area. It is, however, completely divorced from your view on how this works because auditing the properties you’re looking for does not rely on source code at least in a traditional sense.