Re: [Cfrg] Twist insecurity of 2y^2=x^3+x/GF(8^91+5)

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 19 August 2017 15:33 UTC

Return-Path: <ilariliusvaara@welho.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 38059132933 for <cfrg@ietfa.amsl.com>; Sat, 19 Aug 2017 08:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 88OT59t8BHaj for <cfrg@ietfa.amsl.com>; Sat, 19 Aug 2017 08:33:08 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id D2873132494 for <cfrg@irtf.org>; Sat, 19 Aug 2017 08:33:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id C41FD8358F; Sat, 19 Aug 2017 18:33:04 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id slLTij5DStWu; Sat, 19 Aug 2017 18:33:04 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 77DE0288; Sat, 19 Aug 2017 18:33:02 +0300 (EEST)
Date: Sat, 19 Aug 2017 18:33:02 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Dan Brown <danibrown@blackberry.com>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Message-ID: <20170819153302.pymmplx2wvfl3h7p@LK-Perkele-VII>
References: <810C31990B57ED40B2062BA10D43FBF501B9284D@XMB116CNC.rim.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B9284D@XMB116CNC.rim.net>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/5irSXN0fBj7KYn2qNarlxuQGz6M>
Subject: Re: [Cfrg] Twist insecurity of 2y^2=x^3+x/GF(8^91+5)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Aug 2017 15:33:10 -0000

On Fri, Aug 18, 2017 at 09:20:01PM +0000, Dan Brown wrote:
> 
> If the static DH key in the Montgomery ladder implementation above
> is used in a higher-level protocol that requires key confirmation
> from the other side before using the shared key in encryption,
> then it seems the previous attacker's chances either are
> drastically reduced, or the attacker requires billions of (failed)
> interactions (instead of 5).  Is this right?  If so, in such a
> protocol, would a good remedy be to place a limit (e.g. 1000/month)
> on the number of failed key confirmation attempts?

It depends on protocol.

As example of how things can go wrong, take TLS 1.3. If the server
keeps fixed DH key, one can send a few handshakes, and from the
resposes (the server does key confirmation first!) do offline ~2^65
operation attack to find the fixed DH key.

And TLS 1.3 breaks _really_ badly if the server static DH key is
compromised.



-Ilari