Keep in mind that the simpler implementation of block layer encryption also makes it easier to implement and audit.
I'm not as confident in the design and implementation of encryption in e.g. ZFS as I am in full disk encryption.
I'm not sure Tarsnap is a great example of doing encryption at a high level either. As I understand it the encryption layer only deals with opaque chunks of data; it doesn't know anything about high-level concepts like files and folders that the Tarsnap application operates on.
As I understand it the encryption layer only deals with opaque chunks of data
Correct.
it doesn't know anything about high-level concepts like files and folders that the Tarsnap application operates on.
Tarsnap doesn't really operate on high-level concepts like files and folders. It flattens everything into a tar archive, then encrypts and signs that. That does however ensure that data and metadata are kept together, in a way that encrypting individual disk sectors does not.
From an end user's perspective Tarsnap certainly deals with files and folders. It outsources most of that work to libarchive, which is kind of my point.
The article says to "Encrypt things at the highest layer you can.", but you could imagine a backup utility doing encryption at a higher layer than Tarsnap does, with all the complications that would bring. And would it be even better if instead of file system level encryption, every application encrypted it's own files? I don't think so.
So maybe it should just say "Encrypt things at the highest layer that makes sense", which is kind of vacuous.
IMO it would make just as much sense to say "Encrypt things at the level where it's easiest to do.", where block level encryption is a strong contender. It doesn't give you every property you might want, but it's easy to get right.
I think it would be better if applications could provide their own encryption. Applications know better how to cryptographically protect content. For instance: we use GPGMail for our email at Matasano. The operating system could not do a better job of encrypting email messages than GPGMail does.
I understand your point. "Encrypt at the highest layer you can" is an ideal, and achieving the ideal is not always worth the expense. Some lowest-common-denominator crypto in the OS is valuable. But disk block crypto is a pretty crappy lowest common denominator, as this article is at pains to say. What part of it do you disagree with?
If every application provided their own encryption, most of them would get it wrong, and it still wouldn't protect important metadata. I don't think that's much of an ideal.
I don't have an issue with adding application specific encryption, as long as you also keep doing it at a suitable "lowest-common-denominator" layer.
A more achievable ideal would be for every layer to do strong integrity checking.
I agree that one of the costs for doing everything at the highest possible layer is the potential for mistakes. I don't think every application should invent their own cryptosystem; I think most applications would be well-served with Nacl, and I think things like GPGMail show another good path forward.
I agree that it would be good if the lowest common denominator provided integrity checking, but as we can see with XTS, sector-level encryption makes that hard. Hence the article. :)
Comments
Keep in mind that the simpler implementation of block layer encryption also makes it easier to implement and audit.
I'm not as confident in the design and implementation of encryption in e.g. ZFS as I am in full disk encryption.
I'm not sure Tarsnap is a great example of doing encryption at a high level either. As I understand it the encryption layer only deals with opaque chunks of data; it doesn't know anything about high-level concepts like files and folders that the Tarsnap application operates on.
As I understand it the encryption layer only deals with opaque chunks of data
Correct.
it doesn't know anything about high-level concepts like files and folders that the Tarsnap application operates on.
Tarsnap doesn't really operate on high-level concepts like files and folders. It flattens everything into a tar archive, then encrypts and signs that. That does however ensure that data and metadata are kept together, in a way that encrypting individual disk sectors does not.
From an end user's perspective Tarsnap certainly deals with files and folders. It outsources most of that work to libarchive, which is kind of my point.
The article says to "Encrypt things at the highest layer you can.", but you could imagine a backup utility doing encryption at a higher layer than Tarsnap does, with all the complications that would bring. And would it be even better if instead of file system level encryption, every application encrypted it's own files? I don't think so.
So maybe it should just say "Encrypt things at the highest layer that makes sense", which is kind of vacuous.
IMO it would make just as much sense to say "Encrypt things at the level where it's easiest to do.", where block level encryption is a strong contender. It doesn't give you every property you might want, but it's easy to get right.
I think it would be better if applications could provide their own encryption. Applications know better how to cryptographically protect content. For instance: we use GPGMail for our email at Matasano. The operating system could not do a better job of encrypting email messages than GPGMail does.
I understand your point. "Encrypt at the highest layer you can" is an ideal, and achieving the ideal is not always worth the expense. Some lowest-common-denominator crypto in the OS is valuable. But disk block crypto is a pretty crappy lowest common denominator, as this article is at pains to say. What part of it do you disagree with?
If every application provided their own encryption, most of them would get it wrong, and it still wouldn't protect important metadata. I don't think that's much of an ideal.
I don't have an issue with adding application specific encryption, as long as you also keep doing it at a suitable "lowest-common-denominator" layer.
A more achievable ideal would be for every layer to do strong integrity checking.
I agree that one of the costs for doing everything at the highest possible layer is the potential for mistakes. I don't think every application should invent their own cryptosystem; I think most applications would be well-served with Nacl, and I think things like GPGMail show another good path forward.
I agree that it would be good if the lowest common denominator provided integrity checking, but as we can see with XTS, sector-level encryption makes that hard. Hence the article. :)