[tor-dev] future-proofing by combining ciphers (was: Draft sketch document with ideas for future crypto ops)

["Zooko O'Whielacronx" <zooko@xxxxxxxxx>]

in reference to
https://lists.torproject.org/pipermail/tor-dev/2011-November/002999.html

We're doing a development effort and/or thought experiment in the
Tahoe-LAFS project. This development effort and/or thought experiment
is called "One Hundred Year Cryptography" [1].

The main result of the experiment so far is that you don't need to
worry very much future-proofing your digital signatures,
collision-resistant hashes, or MACs, but you *should* worry about
future-proofing your Diffie-Hellmans and ciphers!

Once you deploy a future version of Tor which no longer accepts
old-style signatures, then it will no longer matter to your users if
someone subsequently figures out how to forge old-style signatures
(for example by using quantum computers). On the other hand, once you
deploy a future version of Tor that uses a newer cipher, your users
remain vulnerable to an attacker who later breaks the older cipher and
reads their older plaintexts.

Combining two ciphers as you suggested by XORing their output (and
keying them independentlyâperhaps by deriving two subkeys from a
master key using a strong KDF) seems to be a safe and efficient way to
protect against this sort of threat and doesn't seem to impose too
high of a burden of complexity. That's what we intend to do in
Tahoe-LAFS. A Google Summer of Code student, Yu Xue, contributed some
code to generate subkeys and XOR the streams, but we haven't yet
integrated it into Tahoe-LAFS itself. (I intend to do that in the
release cycle that just opened up, so within the next 4 or so months.)

I haven't thought very much about future-proofing Diffie-Hellman
operations. That sounds like it might be more complex. I *have*
thought about how to combine two different digital signatures or
public key encryption algorithms. Those don't seem too dauntingly
complex, but like I said not so urgent.

I'm leaning toward combining AES-256 with XSalsa20. Other interesting
options include ChaCha (used in SHA-3 finalist Blake, and very similar
to Salsa20) and Threefish (used in SHA-3 finalist Skein).

Regards,

Zooko

[1] https://tahoe-lafs.org/trac/tahoe-lafs/wiki/OneHundredYearCryptography
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev