[148912] in cryptography@c2.net mail archive
Re: [Cryptography] Dual_EC_DRBG backdoor: a proof of concept
daemon@ATHENA.MIT.EDU (Bart Preneel)
Fri Jan 3 17:45:49 2014
X-Original-To: cryptography@metzdowd.com
X-KULeuven-Envelope-From: bart.preneel@esat.kuleuven.be
Date: Fri, 3 Jan 2014 17:11:19 +0100 (CET)
From: Bart Preneel <bart.preneel@esat.kuleuven.be>
To: ianG <iang@iang.org>
In-Reply-To: <52C673FA.4080407@iang.org>
Cc: =?ISO-8859-1?Q?Kriszti=E1n_Pint=E9r?= <pinterkr@gmail.com>,
John Kelsey <crypto.jmk@gmail.com>,
Cryptography Mailing List <cryptography@metzdowd.com>,
Jon Callas <jon@callas.org>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--8323329-692414304-1388765479=:9298
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
On Fri, 3 Jan 2014, ianG wrote:
> On 3/01/14 10:45 AM, Kriszti=E1n Pint=E9r wrote:
>>=20
>> John Kelsey (at Friday, January 3, 2014, 2:31:00 AM):
>>> If we replaced dual ec drbg's output function by taking the parity
>>> of the output point's scalar value, it looks to me like we'd have a
>>> secure drbg despite the potentially evil choice of P and Q, with
>>> whatever good theoretical properties came from dual ec drbg.
>>=20
>> dual ec is easy to fix, but what is the point? it is even easier not
>> to use it, and use fortuna instead, which is better in every way
>> possible. people only use dual ec if they have to, to be compliant
>> with whatever standards. but then they can't change it, not even the
>> extraction part (heck, they can't even fix the mistakes in the
>> documentation, see the case of openssl).
>>=20
>
>
> This is a seriously good point. Defaults are meant to be changed, and ar=
e=20
> offered as a sort of security feature. Alternatives are offered as if th=
is=20
> makes sense in a security context [1].
>
> But can defaults be changed? The barrier to this is often high, and too =
high=20
> to be realistic or give any security benefit.
>
> Two questions, possibly as research topics:
>
> 1. How often are security defaults changed? In any given environment=
=20
> such as OpenSSL, etc.
>
> 2. How hard is it to change the defaults? What is the mental energy=
,=20
> skill & time required? How high is this barrier?
>
> The result of defaults seems to be that they are poorly chosen [2], end u=
p=20
> being the only choice for 99%, and open up an easy attack, DUAL_EC [3].
>
>
> iang
>
> [1] http://financialcryptography.com/mt/archives/001461.html
> [2] http://financialcryptography.com/mt/archives/001450.html
> [3] http://financialcryptography.com/mt/archives/001446.html
One minor advantage of random number generators is that interoperability
requirements are not so stringent - unless you want to interoperate
with the cryptanalysis tools of three-letter agencies :-)
So switching defaults may be easier.
By the way: while we have failed badly at (secure) algoritm
agility, this does not imply imho that it is impossible to make
(secure) algorithm agility work.
-Bart
--8323329-692414304-1388765479=:9298
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--8323329-692414304-1388765479=:9298--
