[Cfrg] Task for the CFRG

["Igoe, Kevin M." <[e-mail]>]

The TLS WG has asked the CFRG for their opinion for a stream cipher, eSTREAM-SALSA20,
and two MAC algorithms, UMAC and POLY1305, that have been suggested for use in TLS
(draft-josefsson-salsa20-tls-02).  This was presented to the TLS WG at IETF-87, slides can
be found at http://www.ietf.org/proceedings/87/slides/slides-87-tls-2.pdf.
The SALSA family works on blocks of 512 bits, and forms a key stream in 512-bit blocks by
applying a fixed map V^{512}->V^{512} to an input consisting of the key (either 16 octets or
32 octets), an 8-octet block counter, an 8-octet IV,  and 16 constant octets.

SALSA20 was one of the five finalists for a software stream cipher in the eSTREAM
contest run by ECRYPTII (see http://www.ecrypt.eu.org/stream/).

UMAC has been around since 1999 and is described in RFC 4418.

POLY1305 first showed up as POLY1305-AES, but all it needs from AES is a 16 byte block
of output. Adapting this to SALSA is straightforward.  The 1305 in the name reflects the
fact that it uses arithmetic modulo 2^{130} - 5.  See http://cr.yp.to/mac/poly1305-20050329.pdf
for a description of poly1305-AES.

Off the top of my head, the only objection I can see is that SALSA may be difficult to
implement efficiently in hardware.  Hardware TLS acceleration can be useful at heavily
utilized servers.

The most current attempt to attack SALSA that I could find is a 2012 paper on the IACR
e-print server.

----------------+--------------------------------------------------
Kevin M. Igoe   | "We can't solve problems by using the same kind
[e-mail]  | of thinking we used when we created them."
                |              - Albert Einstein -
----------------+--------------------------------------------------