[7195] in cryptography@c2.net mail archive
Re: NSA back doors in encryption products
daemon@ATHENA.MIT.EDU (eli+@gs211.sp.cs.cmu.edu)
Fri May 26 00:28:37 2000
From: eli+@gs211.sp.cs.cmu.edu
Message-Id: <200005251745.KAA05817@blacklodge.c2.net>
To: crypto list <cryptography@c2.net>
Date: Thu, 25 May 2000 13:43:06 -0400 (EDT)
In-Reply-To: <3.0.3.32.20000524160945.00929740@mailhost.sctc.com> from "Rick Smith" at May 24, 2000 04:09:45 PM
Reply-To: eli+@cs.cmu.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Rick Smith wrote:
> What if we examine the RNG's binary implementation as well as its output?
> Consider what happened to the weak Netscape RNG.
>
> Given that, how would one go about constructing a broken RNG that would
> resist detection? I'm not saying it's impossible, but the strategy isn't
> clear to me.
It doesn't have to resist detection forever. You keep a few bugs in,
any one of which is compromising; when one is dug up and has to be
fixed, it's time to introduce another.
How long did PGP have the RNG flaw that was found a few years ago?
How long has PGP 5.0i, according Germano Caronni's Bugtraq post two
days ago, been trying to read /dev/random like _this_?
RandBuf = read(fd, &RandBuf, count);
If such a dramatic error in an open-source program can survive that
long, a subtle tweak in a binary can probably last a good while.
> While I suspect that the open source software concept is the only practical
> strategy for healthy long term evolution of software, it doesn't
> automatically yield bug-free, vulnerability-free, or backdoor-free
> software. At best, it gives us an obvious way to track down trouble after
> it pops up. But it doesn't guarantee we'll look for backdoors, or find them
> if they're there. Most of us know this, but given the discussion, it seemed
> worthwhile to repeat for the general audience.
Testify.
--
Eli Brandt | eli+@cs.cmu.edu | http://www.cs.cmu.edu/~eli/
