----- Forwarded message from Zooko Wilcox-O'Hearn <zo...@zooko.com> -----
From: Zooko Wilcox-O'Hearn <zo...@zooko.com> Date: Fri, 10 Aug 2012 13:47:52 -0600 To: tahoe-dev <tahoe-...@tahoe-lafs.org> Subject: [tahoe-dev] Tahoe-LAFS Weekly Conference Call summary 2012-08-07 Reply-To: Tahoe-LAFS development <tahoe-...@tahoe-lafs.org> In attendance: David-Sarah, Zooko [scribe], Brian For future discussion, perhaps next week, Brian wants to talk about Tit-for-Tat accounting when not all of the participants always run both a client and a server. Main topic: XSalsa20 encryption The idea is to encrypt with a combination of XSalsa20⊕AES instead of just AES. That would probably protect the confidentiality of the user's data even in the case that one or the other of the two ciphers turns out to be weak, as long as the other cipher turns out not to be weak. In particular it would protect against timing attacks in the implementation of the AES side, which is a relatively near-term and likely risk. But it would also protect against other sorts of failures in either cipher. There is some justification in theoretical cryptography for such an approach ¹. • It won't go into Tahoe-LAFS v1.10, because Tahoe-LAFS v1.10 is already feature-frozen! But it is close enough to completion that it can quite likely get into Tahoe-LAFS v1.11. • the current crypto implementation has a bug or incomplete feature with regard to random access/seek (ticket #46) • What should the cap type be? Brian has some ideas about putting a tree or other structured thing in the cap itself, s-records or proplists or trees o something, but we can't tell how useful that would be and the simple-minded approach is probably good enough for now. The simpleminded approach is that we augment the current set of caps -- CHK, SSK, MDMF, DIR2:CHK, DIR2:SSK, DIR2:MDMF with an "X" variant of each one: XCHK, XSSK, XMDMF, DIR2:XCHK, DIR2:XSSK, and DIR2:XMDMF. • Why do we care about this? Because of the issue of long-term-confidentiality. There are people who are reluctant to entrust their data to a storage system because they don't want to risk the data being exposed to the world, or to their enemies, a few years or decades hence. We can always upgrade integrity checks and digital signatures in the future to protect future users from accepting forged data, but we can't upgrade encryption, because the old, original ciphertext may be stored for future cryptanalysis. • Zooko says combining two ciphers is good marketing, because it is a defensible security engineering decision but also unusual and a distinguishing factor. David-Sarah says it can be criticized for being overkill. Zooko says being criticized for being overkill is not necessarily bad for marketing. • Brian says extensible data formats often benefit from two types of extension fields: mandatory ones where if you don't understand this then you are required to stop, and optional ones where if you don't understand this then you can ignore it. • Zooko says we have both kinds in our cap scheme: we invent new cap types for mandatory changes, and we use extension fields for optional changes. • We need to add extension fields to all cap types. Currently they are implemented only for MDMF and DIR2:MDMF. • What will go into the extension fields when/if we ever use them? It seems like a good engineering trade-off to use key-value pairs for the contents of the extension field, but not necessarily for the base contents of caps. • Shall we keep using AES-128 or upgrade to AES-256? On some low-power ARM CPUs AES-128⊕XSalsa20 takes 25% fewer CPU cycles than AES-256⊕XSalsa20. Is that significant? We need to do some back-of-the-envelope estimates or even a live measurement on an ARM device to decide if that cost is significant. • David-Sarah points out that each access to a mutable file would require a digital signature operation in addition to the symmetric encryption. • What size key in the crypto cap -- 128, 192, 256 bit? 256-bit is the gold standard key size among the sort of cryptographers that we like, but the caps are already a bit too big with 128-bit keys in them. 2¹⁹² (192-bit keys) is probably close enough to infinity, but it isn't as well-supported by those cryptographers, possibly because in their use cases a 256-bit key doesn't cost any more than a 192-bit key, so they might as well focus on 256-bit keys. • David-Sarah will read up on the latest attacks on AES. Unfinished discussion: • Shall we take this opportunity to remove the url-unsafe characters from the caps format? (Yes, please!) • Make the entire thing be base32? • Except that people need to be able to visually identify the authority bits -- MUT vs IMM, RO vs RW. • There was a recent issue which was confused because of accidental truncation of a CHK cap and the way that errors from truncated CHK caps are not reported very clearly (#1679). Should we add checksums to detect corruption such as truncation? https://tahoe-lafs.org/trac/pycryptopp/ticket/46# Add combined AES+XSalsa20 cipher module https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1679# Nondeterministic NoSharesError for direct CHK download in 1.8.3 and 1.9.1 ¹ https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Bibliography#CipherCombiners tickets mentioned in this letter: https://tahoe-lafs.org/trac/pycryptopp/ticket/46# Add combined AES+XSalsa20 cipher module _______________________________________________ tahoe-dev mailing list tahoe-...@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography