On Wed, Apr 25, 2012 at 9:27 PM, Marsh Ray <ma...@extendedsubset.com> wrote: > On 04/25/2012 10:11 PM, Zooko Wilcox-O'Hearn wrote: >> >> 1. the secret-oriented way: you make a MAC tag of the chunk (or equivalently >> you use Authenticated Encryption on it) using a secret key known to the good >> guy(s) and unknown to the attacker(s). >> >> 2. the verifier-oriented way: you make a secure hash of the chunk, and make >> the resulting hash value known to the good guy(s) in an authenticated way. > > Is option 2 sort of just pushing the problem around? > > What's going on under the hood in the term "in an authenticated way"? > > How do you do authentication in an automated system without someone somewhere > keeping something secret? > > Is authenticating the hash value fundamentally different from "ensuring the > integrity of a chunk of data"?
Those are definitely the right sorts of questions, Marsh. I think that from our bias as crypto engineers familiar with protocols like TLS and SSH, it seems like approach 1 is "natural", or easy, or even the only real, complete solution, but I think it is deceptive. I think _both_ approaches are sort of just pushing the problem around, and I suspect that approach 1 actually leaves you with a harder problem left to solve than approach 2 does. Observe that there is an "in an authenticated way" problem hiding in option 1 as well -- someone has to distribute the secret keys to the legitimate readers in an authenticated way at some point. Basically, as security engineers we tend to assume as a starting point that there is some secret we can use which is known to the good guy(s) and unknown to the attackers. But this isn't really a fair assumption. It implies quite a lot of work that someone else is going to have to do to make that true for us (especially in the multi-party case, but we already don't seem to have solved the problem very well in the traditional 2 party case!), and in practice it seems to often fail. The secrets often turn out to be known to the attackers or unknown to the intended recipients. ... Um, frankly I'm having a hard time understanding exactly why my intuitions about this come out so differently for "data-at-rest" tools like Tahoe-LAFS and ZFS than for "data-in-motion" tools like TLS. My intuition is that secret-based integrity-checking is fine for the traditional two-party, time-limited "session" encryption a la TLS, but that hash-based integrity-checking is more robust and "pushes less of the problem around" when there are more than two parties and when the data is persistent. The intuitions of the ZFS crypto designers (Darren Moffat and others including Nico Williams) seems to have been that secret-based integrity-checking still had some use even in that scenario. However, I don't remember precisely what ZFS settled on for secure data integrity checking. I think to understand the trade-offs of these two options better we would need an example system in which they could be used. My favorite example is obviously Tahoe-LAFS, but I'm not sure if you would learn from considering that example. There is no use of symmetric MAC (nor Authenticated Encryption) anywhere in the Tahoe-LAFS data formats [*]. All data-integrity mechanisms are in the style of option 2 -- using secure hashes of the data as the verification tag. In some cases (immutable files and directories) that secure-hash-based integrity check is the only integrity check. In others (mutable files and directories), it is combined with a public key (RSA) digital signature, where the message being signed includes the hash value. I can't imagine how one could build a Tahoe-LAFS-like thing using the secret-key integrity-checking approach instead. It seems like it would make it impossible to give someone read-access to a file without also giving them write-access. I.e. they would have to know the secret in order to verify the contents of the file, and knowledge of the secret would empower them to undetectably alter the contents of the file. I guess this would make you want to share files with as few other people as possible, and for as short of a time as possible, thus pushing you back toward the "two-party session" type of usage. Regards, Zooko [*] There are actually a couple of uses of symmetric MAC in the Tahoe-LAFS system, but not for data integrity checking on the actual file contents nor on the file metadata or directories, so let's ignore those. They have to do with "control plane" stuff -- network establishment and so on... _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
