[cryptography] [tahoe-dev] Tahoe-LAFS Weekly Conference Call summary 2012-08-07

Eugen Leitl eugen at leitl.org
Tue Aug 14 14:59:43 EDT 2012


----- Forwarded message from Zooko Wilcox-O'Hearn <zooko at zooko.com> -----

From: Zooko Wilcox-O'Hearn <zooko at zooko.com>
Date: Fri, 10 Aug 2012 13:47:52 -0600
To: tahoe-dev <tahoe-dev at tahoe-lafs.org>
Subject: [tahoe-dev] Tahoe-LAFS Weekly Conference Call summary 2012-08-07
Reply-To: Tahoe-LAFS development <tahoe-dev at 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-dev at 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



More information about the cryptography mailing list