1997-03-06 - RE: Microsoft Authenticode key security

Header Data

From: “Peter Trei” <trei@process.com>
To: cypherpunks@toad.com
Message Hash: 985e2339949f4d018f50b9ea285403202c0506924d42a4d40661d4dca828bf5a
Message ID: <199703061513.HAA13900@toad.com>
Reply To: N/A
UTC Datetime: 1997-03-06 15:13:44 UTC
Raw Date: Thu, 6 Mar 1997 07:13:44 -0800 (PST)

Raw message

From: "Peter Trei" <trei@process.com>
Date: Thu, 6 Mar 1997 07:13:44 -0800 (PST)
To: cypherpunks@toad.com
Subject: RE: Microsoft Authenticode key security
Message-ID: <199703061513.HAA13900@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


William H. Geiger III writes:
> In <L0c53D131w165w@bwalk.dm.com>, on 03/05/97 at 07:44 PM,
>    dlv@bwalk.dm.com (Dr.Dimitri Vulis KOTM) said:
> 
> >"Bob Atkinson (Exchange)" <bobatk@EXCHANGE.MICROSOFT.com> writes:
> 
> >> Actually, and sort of to the point, no, the keys never actually ever the
> >> BBN box, except as part of a backup procedure in which they are
> >> extracted in a doubly-encrypted form for which for security reasons you
> >> need the manufacturer's help in restoring.
> >>
> >> To this day, no human or computer other than the box itself knows the
> 
> >But do we necessarily believe what Microsoft people say?
> 
> If Bill Gates got on national TV and told the world that the sky was blue
> I'd have go outside and look for myself. 

Actually, around Redmond, gray skies are much more common.

Really guys, If you want to attack Authenticode (and I personally 
consider it a bandaid on a dangerous system), then stealing or
buying the key is not the approach to take.

I see two possible approaches to prove it's weakness.

1. If they are using RSA, factor the public key. This depends on it's
length. Considering the amount of cpu people seem to be able to 
muster for distributed cracks, etc, I suspect that 512 bit keys will 
soon be vulnerable (equiv = RSA 155).

2.  Write a Trojan Horse ActiveX control which disables the 
Authenticode checking, then covers it's tracks.

No, I'm not working on either of these.

Peter Trei
trei@process.com

Disclaimer: I speak for myself, not my employer.





Thread