[tahoe-dev] Bulk encryption for 100 year cryptography

Samuel Neves sneves at dei.uc.pt
Mon Jun 21 11:00:45 PDT 2010


During the last few months, the 100 year cryptography project saw a
gradual convergence from postquantum/lattice/subset-sum based digital
signatures to hash-based signatures. The argument there is that since we
are using a hash function H anyway to hash the input, the strength of
the digital signatures is ultimately always dependent on H. Thus,  a
H-based digital signature algorithm 'just makes sense'.

Hashing itself has been made more future-resilient by combining two
different hash functions by Comb4P. This function would be our above
mentioned H.

In all of this, encryption seems to be left out of the fun. Instead,
plans are to mix AES (in counter mode) and Salsa20. Why? My suggestion
here is to also use H for this as well. This can be done is two
different ways: by a Feistel network construction (suggested by Zooko)
or counter mode (not unlike Salsa20's mode of operation).

If I remember correctly, we need a 4-round Feistel network with a
perfect round function to achieve provable "strong" pseudorandom
permutation status. However, since we intend to encipher things in
counter mode (at least it would seem to, from the AES and Salsa20
usage), we would use this Feistel network in counter mode.

The alternative is to cut the middleman: we hash a secret key K and a
counter CTR and XOR it with our plaintext --- C = H(K||CTR) ^ P. This is
roughly how Salsa20 works, and seems to be secure as long as H is secure.

This would make all cryptographic primitives in the 100 year
cryptography project dependent on H, which itself amasses the strengths
of more than one hash function to achieve future-resilience.

Best regards,
Samuel Neves

More information about the tahoe-dev mailing list