[Cfrg] Poly1305 and timing attacks

Yoav Nir <ynir.ietf@gmail.com> Sun, 09 March 2014 14:56 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10781A0361 for <cfrg@ietfa.amsl.com>; Sun, 9 Mar 2014 07:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3uUsknntth1 for <cfrg@ietfa.amsl.com>; Sun, 9 Mar 2014 07:56:21 -0700 (PDT)
Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id B24FF1A0265 for <cfrg@irtf.org>; Sun, 9 Mar 2014 07:56:20 -0700 (PDT)
Received: by mail-we0-f178.google.com with SMTP id u56so7364204wes.9 for <cfrg@irtf.org>; Sun, 09 Mar 2014 07:56:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=7kovu93QTRcB+S8L/SnkxyDORwKeoS/TDniu8RRcWDo=; b=ouRoLqxH4I7an/x8tn5GUnrfURoPwmAcIx8z7Z3Bo9AEzTRDOVJ3RjBH/yzapoKx2I 7VhZSrwr6ZurD1qYXn2bRxH2evIXdXEYKb/tFHgV4pN18t0LocMbI4MXBWP2UoUauV5l P+qiqyxQXnjIbzS1U3wbKRYQlUOcUNMy+LC+IS86/bxKZwpZJQUX7dRyqrIU6U/6O0mt AuOtfQR4XIG8FPV4Ux5K+2fCwZQlVCF4f7R7d4iUhD+Lsn2sqV9Q/H3oBc7BDdsn0kET QqUVU6MdXzLffD3e18EqKOc5lcN4b9eBbBSRjvy/PLxC+rQtSwjYYGlzsb5MiturLz1v BAcQ==
MIME-Version: 1.0
X-Received: by 10.180.165.174 with SMTP id yz14mr5663500wib.34.1394376975013; Sun, 09 Mar 2014 07:56:15 -0700 (PDT)
Received: by 10.194.89.1 with HTTP; Sun, 9 Mar 2014 07:56:14 -0700 (PDT)
Date: Sun, 09 Mar 2014 16:56:14 +0200
Message-ID: <CAGvU-a7Mpn9Wrie=QEftsZrojQAcwysnQgNt5BOjdr8ZRY08Zg@mail.gmail.com>
From: Yoav Nir <ynir.ietf@gmail.com>
To: cfrg@irtf.org
Content-Type: multipart/alternative; boundary="90e6ba309824475d7e04f42db078"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/YrdhfvSV_zojPBAFKEjdkqfeJzI
Subject: [Cfrg] Poly1305 and timing attacks
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
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: Sun, 09 Mar 2014 14:56:22 -0000

Hi

I mentioned this during the meeting, but there was no discussion on this
subject there, so I thought I'd raise it here.

I got a private message in response to draft-nir-cfrg-chacha20-poly1305
that questions the text about constant time implementations for Poly1305.
The argument can be outlined as follows:

Side channels in general and timing vulnerabilities in particular are bad
because they reveal either parts of the plaintext they work on, or parts of
the key that is used. However, Poly1305 works on the ciphertext that is
sent on the wire anyway, so exposing that does not matter. Also, Poly1305
requires a different one-time key for each invocation, so revealing some
information about that one-time key doesn't matter, because it will not be
used again. So in summary, timing attacks on Poly1305 don't matter.

This argument is very attractive to me, because if it is valid, it makes
the security considerations much simpler, and significantly reduces the
complexity of implementing these algorithms (the "competent" vs "good"
coder from slide 2).

So can anyone on this list comment on this argument?

Thanks

Yoav