Hello Nico Williams. Nice to hear from you. Yes, when David-Sarah Hopwood and I (both Tahoe-LAFS hackers) participated on the zfs-crypto mailing list with you and others, I learned about a lot of similarities between Tahoe-LAFS and ZFS.
On Wed, Apr 25, 2012 at 1:10 PM, Nico Williams <n...@cryptonector.com> wrote: > > One way to do this is to use AE and also hash the encrypted data, storing > both, the hashes and the AE tags in block pointers, but this is rather > wasteful. Storing only hashes has other problems, but these could be > addressed by MACing the root hash of every encrypted stream and storing that > hash in an appropriate place (e.g., the pointer to the root node for that > stream, or else separately in the node pointing to that root node). I remember this discussion on the zfs-crypto list! It led me to a very general crypto engineering question. It goes like this: suppose you want to ensure the integrity of a chunk of data. There are at least two ways to do this (excluding public key digital signatures): 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. Tahoe-LAFS uses the latter approach, ZFS settled on the former. Obviously which approach works better depends on the context, but I continue to harbor the suspicion that the latter approach—the non-secret verifier-oriented approach—is underrated. In the secret-oriented approach, the attacker wins if they either learn the secret _or_ if they substitute a different secret key of their own to be used by their intended victim. In the verifier-oriented approach, they can win only by such a substitution; there is no secret for them to steal. The secret-oriented approach is contingent on the existence of an appropriate key-distribution scheme which correctly discriminates between legitimate users and illegitimate, giving a copy of the secret to everyone in the first set. The verifier-oriented approach is contingent on the existence of some mechanism to distribute the correct hash value to all users. Since that value is not secret, this seems like an easier problem. Cryptosystems are often predicated on the assumption that a certain secret is unknown to the attacker. What happens when this assumption fails? The non-secret-verifier approach to data integrity is "tamper evident". An audit log, or even just some other user's replica, will prove that something has gone wrong. The secret-key approach can fail in a silent way. The victims may never know that it failed. By the way, I like your suggestion of using both approaches at once. *are we winning?* I'm currently interested in a "big picture" question: how are we doing? Are we winning? I don't know about you, but I consider myself to be primarily a producer of "defense" technology. I'd like for every individual on the planet to have confidentiality, data integrity, to be able to share certain access with chosen people while denying it to everyone else, and more. Judging from the news and the chatter, offense is winning. Apparently almost nobody actually enjoys this kind of protection against the modern attacker, even big organizations who pay big money for it, much less the rest of the populace. I think a good strategy, if it is true that our defensive technology is losing in the field, is to improve our detection and remediation tech more than to continue to focus on prevention tech. That way, at least our users have a better chance of finding out that they are being spied on or manipulated, and in addition we might be able to use the resulting information in a feedback loop to improve our tech. (I was fascinated by the recent disclosure that Nortel Networks was thoroughly penetrated—allegedly by Chinese industrial spies—for almost ten years prior to its dissolution. Ten years!) ... *pause to catch breath* Okay, so the question of how to check integrity of your data chunks is one tiny engineering decision in light of that big picture. I guess the big answer to that big question might be something along the lines of sharing more information among users, so that we can help one another spot incursions and collaborate to retrospectively analyze and understand them. I'm not actively working on this sort of thing right now, just thinking about it. I guess my next contribution in this direction will be the fulfillment of my long-standing desire to make Tahoe-LAFS into a good filesystem for storing secure audit logs. (To be really good for that, Tahoe-LAFS needs to extend its vocabulary of access control to include "add-only" and "write-only" access, which requires public key encryption plus some really hairy fault-tolerance stuff to withstand the defection of a limited subset of the storage servers. If you're interested I'll point you to notes about this.) *back to Authenticated Encryption* > But in traditional network protocols (TLS, SSHv2, ESP, ...) I have to strain > to think of reasons to not use AE when you want confidentiality protection > (encryption). Yes, I agree with you on that. And OTR ¹, CurveCP ², mosh ³, tcpcrypt ⁴, and ZRTP ⁵. All of these eight protocols we've just named have in common that there are only two parties, that only "current" data in-flight is protected, and that the protocol has already ensured (more or less -- haha) a shared secret key known to both of the users and not to any attackers. I don't question the usefulness of the Authenticated Encryption abstraction for protocols that fall into that category. Regards, Zooko ¹ http://cypherpunks.ca/otr ² http://curvecp.org ³ http://mosh.mit.edu ⁴ https://tcpcrypt.org ⁵ http://zfoneproject.com/zrtp_ietf.html _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
