[Cfrg] theoretical question ... RE: Task for the CFRG

[Dan Brown <[e-mail]>]

I cannot offer an expert opinion on these symmetric algorithms, only a
generic concern and a naïve question, both theoretical and tangential (to
the original thread).

 

 

Generic Concern

 

The proposal is in the form of: change from algorithm A to algorithm A or B.


 

(+) This improves security in the sense that if we know A or B is broken, we
can shut if off, and then use the other.

 

(-) If we do not know that A or B is broken, or if we cannot easily shut off
one, then the adversary can perhaps just attack the weakest choice of A or
B.

 

Arguably (+) already outweighs (-)., but furthermore, many crypto protocols,
including TLS, take two parties, perhaps one of whom can shut off A or B and
be presumed to be more knowledgeable.  In other words, one side can do (+)
to mitigate the (-) above on the other side, if the enforcement to use the
secure choice can be securely conveyed.

 

 

Naïve (and theoretical) Questions

 

How does TLS enable one side to enforce the choice of A or B? Does it use a
mechanism other than A or B?   For a concrete example, suppose a server
implements (+), choosing MAC algorithm A, shutting off B. In TLS, the server
does not sign the algorithm choice of A, right?  Consequently, if MAC
algorithm B is sufficiently broken, can an adversary fool the client into
using the broken MAC alg B, leveraging the fact that B is broken to
mis-authenticate the approval to use B?  A similar question might be asked
about the encryption algorithm.  So, I am concerned that, while the server
will not use the broken algorithms, then client is still at risk, because
the adversary can impersonate the server, or the else, the client leak
plaintexts to the adversary.  

 

I guess what I am suggesting that for (+) to successfully mitigate (-) as
outlined above, some method other than a broken algorithm should be used to
enforce the other side to use the unbroken algorithm.  In the case of TLS,
this may occur at the public key level, or pre-shared key.  Maybe TLS
already does this: I’ve misunderstood TLS several times already, so maybe my
concerns are unfounded.

 

Also, all this is not suggest that specific alg might be weak, as in the
hypothesis above, but rather to establish how much is gained by the change
to A or B. .Put another way, maybe AàB substitution I outlined is possible
only if B is disasterously weak, and we can be very confident that B is not
so weak, in which case there may be no downside to allowing A or B at all.
So, this is a theoretical question, not a practical question.  

 

Authentication of algorithm has already been discussed a few times on this
list and others, but I forget the conclusions.   

 

Best regards,

 

Dan

 

 

 

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Igoe, Kevin M.
Sent: Thursday, August 08, 2013 3:46 PM
To: [e-mail]
Subject: [Cfrg] Task for the CFRG

 

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 -

----------------+--------------------------------------------------