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

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

MIME-Version: 1.0
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"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/2mMCFLs6wVW2PTerKJloTDSUl08
Subject: Re: [Cfrg] Schnorr just as vulnerable to bad RNG
Precedence: list

Dan Brown <dbrown@certicom.com>:

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

Re: [Cfrg] Schnorr just as vulnerable to bad RNG Stephen Farrell
[Cfrg] Schnorr just as vulnerable to bad RNG Dan Brown
Re: [Cfrg] Schnorr just as vulnerable to bad RNG Bodo Moeller
Re: [Cfrg] Schnorr just as vulnerable to bad RNG Rene Struik
Re: [Cfrg] Schnorr just as vulnerable to bad RNG Bodo Moeller
Re: [Cfrg] Schnorr just as vulnerable to bad RNG Michael Hamburg
Re: [Cfrg] Schnorr just as vulnerable to bad RNG David Jacobson
Re: [Cfrg] Schnorr just as vulnerable to bad RNG Sandy Harris