Re: [TLS] Another INRIA bug in TLS

Tanja Lange <tanja@hyperelliptic.org> Fri, 22 May 2015 22:52 UTC

Return-Path: <tanja@hyperelliptic.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A3F1A896E for <tls@ietfa.amsl.com>; Fri, 22 May 2015 15:52:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.195
X-Spam-Level:
X-Spam-Status: No, score=0.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] autolearn=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 n4Kz4I3nd0s8 for <tls@ietfa.amsl.com>; Fri, 22 May 2015 15:52:42 -0700 (PDT)
Received: from calvin.win.tue.nl (calvin.win.tue.nl [131.155.70.11]) by ietfa.amsl.com (Postfix) with SMTP id D2F2F1A8969 for <tls@ietf.org>; Fri, 22 May 2015 15:52:41 -0700 (PDT)
Received: (qmail 22296 invoked from network); 22 May 2015 22:53:01 -0000
Received: from pcdhz005.win.tue.nl (HELO hyperelliptic.org) (131.155.71.33) by calvin.win.tue.nl with SMTP; 22 May 2015 22:53:01 -0000
Received: (qmail 29422 invoked by uid 1000); 22 May 2015 22:52:51 -0000
Date: Sat, 23 May 2015 00:52:51 +0200
From: Tanja Lange <tanja@hyperelliptic.org>
To: Jeffrey Walton <noloader@gmail.com>
Message-ID: <20150522225251.GG20757@cph.win.tue.nl>
References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> <1432317148442.5357@microsoft.com> <87pp5snxha.fsf@alice.fifthhorseman.net> <CAH8yC8k8C_PJqwJe38hjtaHhcga5iSZ2+sRx8EOQAp9E8SfZ+w@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAH8yC8k8C_PJqwJe38hjtaHhcga5iSZ2+sRx8EOQAp9E8SfZ+w@mail.gmail.com>
User-Agent: Mutt/1.5.11
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/mz68HMIqxOqRww9SzC0crLop90g>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Another INRIA bug in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 May 2015 22:52:43 -0000

> M-R is one check, but there are others. For example, trial division
> and the choice of g in a group (g may not necessarily be a generator).
> 
You want g to generate a large prime-order subgroup. 

> As a practical example from a guy who regularly validates all
> parameters, see
> http://crypto.stackexchange.com/questions/17707/trial-divisions-before-miller-rabin-checks
> and http://crypto.stackexchange.com/questions/12961/diffie-hellman-parameter-check-when-g-2-must-p-mod-24-11.
> 
> What I found in the past that the IETF's choice of g = 2 meant that
> various DH_param_check(...) would fail.
> 
The choice of g=2 is appropriate for the Oakley primes because 2 generates
the group of squares, which is exactly the group of size (p-1)/2.

Unfortunately some programs decide to check whether g generates the
entire group of size p-1, i.e. is a primitive element. I say 
'unfortunately' because if this is taken together with the recommendation
of using relatively short intervals for the secret key (p-1)/2
being composite you're likely to get a powerful break using
Pohlig-Hellman.

All the best
	Tanja