Re: [Cfrg] Schnorr just as vulnerable to bad RNG

Bodo Moeller <bmoeller@acm.org> Fri, 25 July 2014 14:10 UTC

Return-Path: <SRS0=900A=4U=acm.org=bmoeller@srs.kundenserver.de>
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 494D41B28FB for <cfrg@ietfa.amsl.com>; Fri, 25 Jul 2014 07:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.929
X-Spam-Level:
X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 lPR1EBkvMCV2 for <cfrg@ietfa.amsl.com>; Fri, 25 Jul 2014 07:10:48 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBE161A0316 for <cfrg@irtf.org>; Fri, 25 Jul 2014 07:09:23 -0700 (PDT)
Received: from mail-yk0-f176.google.com (mail-yk0-f176.google.com [209.85.160.176]) by mrelayeu.kundenserver.de (node=mreue004) with ESMTP (Nemesis) id 0M940H-1XN1Su27Cv-00CRZd; Fri, 25 Jul 2014 16:09:21 +0200
Received: by mail-yk0-f176.google.com with SMTP id 19so2781210ykq.7 for <cfrg@irtf.org>; Fri, 25 Jul 2014 07:09:20 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.115.103 with SMTP id d67mr23694042yhh.46.1406297360558; Fri, 25 Jul 2014 07:09:20 -0700 (PDT)
Received: by 10.170.129.17 with HTTP; Fri, 25 Jul 2014 07:09:20 -0700 (PDT)
In-Reply-To: <20140725131738.6639765.60290.17138@certicom.com>
References: <20140725131738.6639765.60290.17138@certicom.com>
Date: Fri, 25 Jul 2014 10:09:20 -0400
Message-ID: <CADMpkcJD_qXkNFECQ4YoBUhyxQJNrh1=K6gAGfJ23jFWaD51-Q@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary=20cf30363911a0017804ff051e89
X-Provags-ID: V02:K0:QFXA8RReHVeEuZ22p/bCx+z3B/lNQNlOO+2BdCXEiwm vYKicVIh/t4n4HN9yumcrtkwXeXg8a4zALPFQuV3CoZ5eUptEO rlqOsGZj9zu/J1qa12s/9u05S1D0WaJINKwR5ppbVCEZQAena9 IruJM2qe/4VAcQgqZPad8f8g2Cq4XHcl3Mxi9rP8qb8XX8i3CC HsUAw8RDS0Sg79diH3jLo+gYThlSmfYVMKgwSrbxtM2FYeh6YY GWRSNrGoiTsP8DyJv5zmr/aPG2RXKJa5Ba4A6v0rjGHhLMzEka wHaxU//roJw5jc7BWRipyYGyyM4ikNY0YJUP0FwDxkGZZwm6uz l745NG0z1N/g9ZpdIj6ilFkoi3Xsn6kPBYdLlrgV0yqGEy5toB apyKGgp+vxdF9BqxBpJnaXiVIdCJDJXSuVdfQ/ZF69JmXX517I KHnMm
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/2mMCFLs6wVW2PTerKJloTDSUl08
Subject: Re: [Cfrg] Schnorr just as vulnerable to bad RNG
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: Fri, 25 Jul 2014 14:12:08 -0000

Dan Brown <dbrown@certicom.com>om>:

Some people propose using deriving the ephemerals from the message and a
> long term key. This does not seem any better as an algorithm than the DRBG
> approach, provided the X9.62 algorithm is adhered to.
>
> There's an RFC melding both these ideas, but that is trying fix something
> that is not broken, at the algorithm level.
>

It's certainly not broken, but more fragile than necessary. If you use an
appropriate PRNG with proper seeding, there's no problem, but in practice,
sometimes you *think* you have proper seeding when you actually don't.
 That's usually bad in any case, but it can be less bad with the hash-based
approach.  Since the additional cost of hashing is minor, I think hashing
is a good idea for implementations.

(What document are you referring to?  Really an RFC?)

Bodo