diff --git a/OneHundredYearCryptography.md b/OneHundredYearCryptography.md
new file mode 100644
index 0000000..e2ffb66
--- /dev/null
+++ b/OneHundredYearCryptography.md
@@ -0,0 +1,22 @@
+
+This describes a project to enhance Tahoe's cryptographic system so that Tahoe shipped today/next year might remain safe from cryptographic attacks for a 100 years. The initial ideas were presented on a post by Zooko to his klog (since lost, apparently).
+
+The basic idea is to combine two primitives, both thought to be safe, such that even if one of them fails catastrophically Tahoe remains secure.
+
+## Bulk Encryption
+
+Convert from AES/CTR to using AES/CTR combined (by XOR) with XSalsa20. This has the advantage of being fully parallel, since you can compute both the AES and XSalsa20 keystreams in parallel and before the plaintext or ciphertext is known.
+
+It's worth noting that AES is being retained more for political/name brand reasons than actual security. If this wasn't a factor we might well be better of instead using a design that is safe against timing attacks, such as Serpent or Noekeon. On the other hand, CTR mode probably makes timing attacks rather more difficult because the attacker can't choose inputs. And, I believe, in Tahoe's case, the initial CTR IV will be secret and chosen via a cryptographic KDF.
+
+Open questions:
+  * Should we use AES-128, AES-192, or AES-256?
+  * What KDF is used to generate the keys/IVs? I think Zooko suggested using XSalsa20, but I haven't seen a concrete proposal.
+
+## Hashing
+
+We'll combine two hash functions using the Comb4P hash function combiner, which preserves most (but not all) security properties of the hashes. It also has the advantage of being simple and relatively fast, though because the extra work comes in the form of a set of final Feistel rounds, this may negatively effect performance when combined with the tree hashing mode Tahoe uses.
+
+## Signatures
+
+I think Zooko has a plan. I don't know what it is.
\ No newline at end of file