Re: [Cfrg] Poly1305 and timing attacks

Watson Ladd <watsonbladd@gmail.com> Sun, 09 March 2014 22:48 UTC

Return-Path: <watsonbladd@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 77D3D1A0247 for <cfrg@ietfa.amsl.com>; Sun, 9 Mar 2014 15:48:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 kcc0bd1PIdw9 for <cfrg@ietfa.amsl.com>; Sun, 9 Mar 2014 15:48:57 -0700 (PDT)
Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7544D1A0196 for <cfrg@irtf.org>; Sun, 9 Mar 2014 15:48:57 -0700 (PDT)
Received: by mail-yh0-f51.google.com with SMTP id f10so6317869yha.38 for <cfrg@irtf.org>; Sun, 09 Mar 2014 15:48:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=g6ZwLIzlZu4LNRdQeIygjzU3wo17fEDmWNmLq9FdRZQ=; b=djmTN+rLiUQGXlzGddur+WewXmLudQpUJaxRqEko9UbXAxAHgMlLlTTWoPQv0Zo+Mo YWQeqZuEC8R/DD9I1vpdqj4lSH88HtwMGaPqsIoXsMwjb6P7fauqG337tZtGicB3S9IK W06Gfwuxhe6UaFj1rl0+EHkEZunfi6bAZZVxjSn9DM3+h8YlpUiE7CEwt9/JdL8Ijd3M poyd3yhGFXVoyY9pdg5SpuYLs2QPT/f8RxhgVGcSGOhR6ebJAy7niFZcLEN04ZpqJ5o6 k74l4FbDs9FRIk2Kzq74XXjjKHF00MNnGbhcmqBjiIcs304DbWMbmN4g2qTDwQynlHqH BelA==
MIME-Version: 1.0
X-Received: by 10.236.191.67 with SMTP id f43mr39186263yhn.60.1394405332143; Sun, 09 Mar 2014 15:48:52 -0700 (PDT)
Received: by 10.170.80.214 with HTTP; Sun, 9 Mar 2014 15:48:52 -0700 (PDT)
In-Reply-To: <CA0A4F63-89AB-4AC2-8955-E3C575E3B01C@gmail.com>
References: <CAGvU-a7Mpn9Wrie=QEftsZrojQAcwysnQgNt5BOjdr8ZRY08Zg@mail.gmail.com> <CACsn0ckrTB37jB4Apj7GxAZUjou_=RUj7j4dgFeWpqxS4HKq6Q@mail.gmail.com> <CA0A4F63-89AB-4AC2-8955-E3C575E3B01C@gmail.com>
Date: Sun, 09 Mar 2014 15:48:52 -0700
Message-ID: <CACsn0cmNA15ZM9S2s73oTtKGH5SujSef9_3ez12jzg934HW9ow@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/v3xL0bVZVZZ9agNzINzaWJTZ0zU
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [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 22:48:59 -0000

On Sun, Mar 9, 2014 at 3:00 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
>
> On Mar 9, 2014, at 6:45 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
<snipped agreement>
>
>> For Poly1305 as used in this draft, I am very, very hesitant about
>> approving any draft that says not-constant time is okay. However, if
>> the entire keys are being generated pseudorandomly, then I think, if
>> the side channel isn't gratuitously large, it's possibly safe. Saying
>> anything more concrete would require a lot of painful analysis of what
>> is leaked and how it can be used.
>>
>> Personally, I don't understand why making the crypto not constant
>> time, and thus open to attacks, simplifies the security
>> considerations. It might make the job of the implementor easier, but
>> it makes the job of the person who builds on top harder.
>
> It makes the security considerations simpler because it makes all the talk about constant time implementations go away and eliminates the need for pointing people at how to accomplish this. I agree I probably can’t do this, as this implementation might later be used as part of a library for other things. It’s not generally good to instruct people on how to make an implementation with a warning label (that they will later ignore).

Well, I have to fundamentally disagree with this. A constant-time,
constant-memory access, constant-control flow implementation is far
more reassuring than one which doesn't have these properties. The
security of a system using the second is far less evident than one
using the first. While implementing the second might be easier, it's
less trustworthy, and hence using it in a system requires more, rather
than less, analysis. The stronger the building blocks of a protocol
are, the easier it is to argue for its security.

Sincerely,
Watson Ladd

>
>> Two sidenotes: IVs are not nonces, and there is a typo where "times
>> might be great then 2^256 or less then 2^256”.
>
> Yes, “sometimes” is a single word.
>
>> Sincerely,
>> Watson Ladd
>>>
>>> Thanks
>>>
>>> Yoav
>>>
>>>
>>> _______________________________________________
>>> Cfrg mailing list
>>> Cfrg@irtf.org
>>> http://www.irtf.org/mailman/listinfo/cfrg
>>>
>>
>>
>>
>> --
>> "Those who would give up Essential Liberty to purchase a little
>> Temporary Safety deserve neither  Liberty nor Safety."
>> -- Benjamin Franklin
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin