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 _______________________________________________ tahoe-dev mailing list tahoe-dev@allmydata.org http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev