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

Dan Brown <dbrown@certicom.com> Fri, 09 August 2013 17:26 UTC

Return-Path: <prvs=4933d59343=dbrown@certicom.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B13C11E8114 for <cfrg@ietfa.amsl.com>; Fri, 9 Aug 2013 10:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjl2-6b57ng4 for <cfrg@ietfa.amsl.com>; Fri, 9 Aug 2013 10:26:05 -0700 (PDT)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0A46121F841B for <cfrg@irtf.org>; Fri, 9 Aug 2013 10:21:12 -0700 (PDT)
X-AuditID: 0a412830-b7fca6d000000728-42-520525019886
Received: from XCT103CNC.rim.net (xct103cnc.rim.net [10.65.161.203]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id A9.90.01832.10525025; Fri, 9 Aug 2013 12:21:05 -0500 (CDT)
Received: from XCT111CNC.rim.net (10.65.161.211) by XCT103CNC.rim.net (10.65.161.203) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 9 Aug 2013 13:21:05 -0400
Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT111CNC.rim.net ([::1]) with mapi id 14.03.0123.003; Fri, 9 Aug 2013 13:21:04 -0400
From: Dan Brown <dbrown@certicom.com>
To: "'kmigoe@nsa.gov'" <kmigoe@nsa.gov>, "'cfrg@irtf.org'" <cfrg@irtf.org>
Thread-Topic: theoretical question ... RE: Task for the CFRG
Thread-Index: Ac6Ub9vopigPuZ74Q3i+O+WDV9xpLQArEIUQ
Date: Fri, 9 Aug 2013 17:21:04 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF51D9E4D@XMB111CNC.rim.net>
References: <3C4AAD4B5304AB44A6BA85173B4675CAB247161D@MSMR-GH1-UEA03.corp.nsa.gov>
In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CAB247161D@MSMR-GH1-UEA03.corp.nsa.gov>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.249]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0123_01CE9503.4A9062A0"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLsWRmVeSWpSXmKPExsXC5bjwtC6jKmuQQfcCI4vuHweZLCaces3q wOQxeeNhNo/+XS9ZA5ii5G2SEkvKgjPT8/TtbFJSczLLUouQWQnyGc+3L2QqePCZsaJn9wW2 Bsb/txm7GDk5JARMJHa8vsEKYYtJXLi3nq2LkYtDSKCdSWLPhe+MEM4KRonLc26yQDizGSX+ zZ7DBtLCJqAqcf/oOeYuRg4OEQEviUv91SBhYQFziVO3VjKD2CICNhI/vtxhgrCNJLov9IJt ZhFQkTi3fBFYDa+Am8TbI5fA4kICQRJtU1aBxTkFgiVm7X0LFmcUkJXYffY62BxmAXGJW0/m M0FcLSLx8OJpNghbVOLl439Q3yhK7H12lAnkZmaBXkaJZe92MUIsE5Q4OfMJC8QyBYkr1/ex TGAUm4Vk7ixkPbOQ9EAURUt8mt/PBGEbSNw/1MEKYWtLLFv4mhnC1pdoO7aaGVPcVmL/1ZVQ tqLElO6H7BC2qcTrox8ZFzByr2IUzM0oNjAzTM5L1ivKzNXLSy3ZxAhOCRoGOxjfv7c4xCjA wajEw/tUgjVIiDWxrLgy9xCjCtCMRxtWX2CUYsnLz0tVEuF9zQWU5k1JrKxKLcqPLyrNSS0+ xLibCRjwE5mluJPzgYksryTe2MCAco4ojGNoZGluaGlmbGZqYmg2VIWVxHldVT4ECgmkJ5ak ZqemFqQWwYKPiYPzEKMEB5eUSHFqXkpqUWJpSUY8KOvFFwPznlQDo/s912Wi8V+e3yzYeex9 8f3nZWu8lNYudCusXFOYajn52n9JYbaX/zujyia5bRHfNmX7o6NpD6arbVQynbpW/qGV0+ZL C+c+D3ucOuX9BOGrnyPZmLmlyk5biiSY2k7wWfulYc/ezZcqa1wOxu19d+h0+ZQF9psNaw0i 69QuHyiKONnF/fZPwgwlluKMREMt5qLiRAClJfscTQQAAA==
Subject: [Cfrg] theoretical question ... RE: Task for the CFRG
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Aug 2013 17:26:10 -0000

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: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of
Igoe, Kevin M.
Sent: Thursday, August 08, 2013 3:46 PM
To: cfrg@irtf.org
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

kmigoe@nsa.gov  | of thinking we used when we created them." 

                |              - Albert Einstein -

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