1996-01-20 - Re: Win95 Registration Wizard info

Header Data

From: JR@ns.cnb.uam.es
To: cypherpunks@toad.com
Message Hash: 1eba7ba8e0d7608b3109d5aa7603742381e6ae6e29913df6f307d9c96c1e9282
Message ID: <960119121126.204013d9@ROCK.CNB.UAM.ES>
Reply To: N/A
UTC Datetime: 1996-01-20 20:36:05 UTC
Raw Date: Sun, 21 Jan 1996 04:36:05 +0800

Raw message

From: JR@ns.cnb.uam.es
Date: Sun, 21 Jan 1996 04:36:05 +0800
To: cypherpunks@toad.com
Subject: Re: Win95 Registration Wizard info
Message-ID: <960119121126.204013d9@ROCK.CNB.UAM.ES>
MIME-Version: 1.0
Content-Type: text/plain


From:	SMTP%"alano@teleport.com" 18-JAN-1996 23:29:11.16
>At 10:03 AM 1/18/96 -0500, Perry E. Metzger wrote:
>>
>>Alan Olsen writes:
>>> I picked this link up from the Fringewear list.
>>[...]
>>> The author takes the registration Wizard in Win95 apart and shows exactly
>>> what it does and what it looks for.  Some interesting information about the
>>> encrypted database of product information it uses.
>>
>>What, exactly, does this have to do with cypherpunks?
>
>I posted it for two reasons.  
>
... reason one deleted ...

>2) The program's use of encryption to conceal what products it looks for.
>
... rest of message deleted ...

I also found interesting the use of a debugger to break Microsoft's crypto.
When we speak about crypto, we do not only refer to algorithms, we must also
consider insiders, eavesdroppers, etc...

Well, this is a good example of a technique to break encrypted messages that
has proven useful and, what's more, has the support of the operating system.
A big mistake from Microsoft. And also in many other vendors. While not
interesting in many protocols, it is worthy in those where one of the parts
doesn't trust the other.

The point is that any non-trusted party can try a similar approach -using a
debugger- to gather information from within their computer (passwords, keys,
data...) unless there is some way to prevent it (like using a better approach
or protocol).

It's silly to send text in the clear through an insecure channel. So it is
to store passwords in the clear in world-readable files. Or to keep data in
memory which can be paged to disk...

The article comes to point out that it is also as silly to store cleartext
in any program memory that can be accessed/traced/dissected by an untrusted
user. And that Microsoft obviously choose again a too weak (mean?) approach to
secure their data.

I wonder now wether one could still rely on Microsoft to provide a reasonable
Crypto API as they are bragging lately...

				jr






Thread