[4583] in cryptography@c2.net mail archive
Re: Intel & Symantec v. ZKS?
daemon@ATHENA.MIT.EDU (William H. Geiger III)
Sat May 1 13:27:00 1999
From: "William H. Geiger III" <whgiii@openpgp.net>
Date: Sat, 01 May 1999 12:11:24 -0500
To: cryptography@c2.net
In-Reply-To: <199904292040.WAA25584@mail.replay.com>
In <199904292040.WAA25584@mail.replay.com>, on 04/29/99
at 03:40 PM, Anonymous <nobody@replay.com> said:
>William H. Geiger III writes:
>> One has to wonder if this is the actions of a company that is trustworthy
>> enough to supply RNG's to the community. IMHO it is not and I sincerely
>> hope support for the PIII is *not* included in /dev/random and/or IPSEC. I
>> will not be adding any support code in my software.
>He quotes John Markoff's story in the New York Times:
>> Earlier this month, an Intel executive called executives at the Symantec
>> Corporation, maker of the popular Norton Antivirus software, and told them
>> that the demonstration program was "hostile code."
>>
>> Symantec agreed that the program fit its definition of a type of malicious
>> program known as a Trojan horse, so it included the software in its
>> continually updated list of dangerous programs, which include viruses,
>> that cause warnings to pop up on its customers' computers.
>In fact, this is perfectly reasonable on the part of Symantec, and if I
>had a PIII I would absolutely want my virus detection software to catch
>code which enables the serial number. Any such action on the part of
>downloaded code is malicious and not in my interests, and anything the
>software can do to prevent it is good.
>This sets a precedent that code which reads the serial number contrary to
>the user's wishes is hostile. This should help dissuade over-eager
>software registration programs from using the serial number in their
>registration process. No antivirus software can detect all programs
>which try to read the serial number, but by making clear that such
>actions are antisocial it will help restrict its use.
>Granted, it would be better if the serial number didn't exist at all (but
>of course we know that network interface cards have always had serial
>numbers, don't we?). And it would be better if Intel's method of turning
>off the serial number worked right. But given that it does exist in a
>family of processors which will probably be widely used (ineffectual
>boycotts to the contrary), users do benefit by having unauthorized serial
>number programs be detected and identified as dangerous.
No, all this does is set the precedent of a major corporation flexing it's
muscle in an attempt to silence those who would expose their lies. This is
a typical case of corporate CYA and I am appalled by it. Do you honestly
think that Symantec is going to list any Microsoft products as a virus
when they covertly turn on this feature?
As far as ineffectual boycotts, I am not asking for the software not to
run on a P-III, I am asking that specific support for the P-III RNG not be
added. I don't think requiring Intel to shape up if they want to be
players in the crypto community is a Badthing(TM).
>> [Personally, given how bad the random number sources are in most
>> software, I'd say you are not doing your users a service. --Perry]
>Of course Perry is absolutely right. The Intel RNG can provide a badly
>needed source of randomness. The real problems are first, as was pointed
>out here yesterday, Intel has not documented how to read the RNG (and is
>apparently only supplying that information to partners like RSA and
>Microsoft). And second, how should we count the entropy added by the
>RNG. Here is where the trust issue comes into play. If it is really a
>good RNG we can count every bit as a bit of entropy. If we don't trust
>it, we can use the RNG data but not count entropy from it at all. Or we
>could split the difference and "semi" trust Intel, counting only some
>fraction of the nominal entropy provided by the RNG source.
So we should just blindly use a RNG of unknown properties from an
untrustworthy company? What will happen next when the P-IV has built in
crypto module (it is the next logical step)? Yes many programs have bad
random sources, many programs have bad crypto period. I don't use them and
I don't support them, plain and simple. I have to reiterate my original
statement from the /dev/random thread that I started:
"I have specific concerns, the #1 of which is that no analysis of this
program has been done!! If this was a crypto algorithm and one was to use
it without any analysis of it but only because "it came with the OS" one
would be severely chastised by the community. Unfortunately I am seeing
too many programmers blindly using /dev/(u)random on this very basis. I am
not saying it is a bad program, I am not saying it is a good program, I am
saying it is an unknown, and with something as important as one's random
number pool IMNSHO an unknown is not acceptable."
Here we have a RNG on unknown properties and yet there is already those
who wish to blindly rush out and uses it. You really should know better.
--
---------------------------------------------------------------
William H. Geiger III http://www.openpgp.net
Geiger Consulting Cooking With Warp 4.0
Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii
Hi Jeff!! :)
---------------------------------------------------------------
