Also, On Wed, Apr 25, 2012 at 10:11 PM, Zooko Wilcox-O'Hearn <zo...@zooko.com> wrote: > 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.
Yes, I remember that too. It was fun and enlightening. >> 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. Remember that in ZFS we also speak of end-to-end integrity protection, except in ZFS there's a single end: the system that implements it, and the attackers are presumed to be between that system and its storage devices. It's end-to-end because even though there's only one end, that end is effectively communicating with itself [over untrusted storage media]. The on-disk format is the equivalent of secure transport protocol (with SAS, IB, .. being the equivalent of TCP/IP). Of course, if you access said storage from multiple heads then there will be multiple ends, but since only one can be writing at any given time (and really, even reading)... In ZFS w/ encryption there are no additional ends, and protection against a local privileged agent is not in scope, but protection of data at rest (on the storage devices making up the ZFS volumes) is in scope. Additional protection is available when and for as long as the keys are not loaded on the system running ZFS. I think the distinction between filesystems on the one hand and communication protocols on the other is that in the first case we always have snapshots of data that we can apply Merkle hash trees to, and we always have *all* the data available and subject to use and re-use in random access patterns at any given time, including years later. Whereas in the second case the data is ephemeral, consumed and thrown away or otherwise transformed (outside the scope of the transport protocol) as soon as possible -- there's no need to consider an attack where a block earlier in the octet/message stream gets modified after it's been received and consumed. We could store files as TLS streams using PSK and have those "shared" keys be the files' keys, but that would be inefficient, particularly if you were to need to write in any fashion other than strictly append-only. This distinction is what I believe drives us to design/apply completely different cryptographic protocols to the two types of protocols. > I don't question the usefulness of the Authenticated Encryption > abstraction for protocols that fall into that category. Right, me either. I can't even imagine not using AE in that context, whether by generic composition or -much better- via integrated AE ciphers/cipher modes. Nico -- _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
