[tahoe-dev] GSOC proposal---"100 year cryptography"

[Jack Lloyd]

On Fri, Apr 16, 2010 at 10:46:04PM +0800, yu xue wrote:
> About 2-3 weeks
> This part is mainly for symmetric ciphers such as block cipher and stream
> cipher. Take two ciphers as underlying primitives. For block cipher it need
> to specify an appropriate operation mode, such as CBC, CRT, or OFB etc.

I would definitely vote for continuting to use AES (or any other block
cipher) in CTR mode, because when processing any message you can
encrypt arbitrarily many blocks in parallel, which has numerous
practical advantages:

 - On processors with the AES-NI instruction sets, the round
   operations have substantial latency. Intel recommends processing
   4-8 blocks in parallel to hide this latency. Being able to utilize
   AES-NI (or similiar instruction sets, eg for the low-power AMD
   Geode) well seems highly useful.

 - It allows use of bitslicing implementations; these are often
   constant time, which would prevent the well known AES timing
   attacks which is one driver behind the cipher combinator under
   consideration.

 - The decryption routine is not needed. This is particularly valuable
   in the case of bitsliced AES, since the code for implementing the
   Sbox in boolean operations is quite large and relatively complex
   compared to the typical table-based implementation, and wholly
   new code would be required for the inverse Sbox if decryption
   was also used.

Specifically for AES, CTR also allows for the "CTR mode caching"
optimization, which offers an immediate 3-5% (IIRC) performance
improvement over other modes with AES. (Crypto++ already implements
this optimization.)

-Jack