1997-02-04 - IBM’s SecureWay Key Recovery technology

Header Data

From: Marshall Clow <mclow@owl.csusm.edu>
To: cypherpunks@toad.com
Message Hash: b4eff98ab40ee1acd1e006e057dbd49bbba8177b22baf22b822670c2f5f201cc
Message ID: <199702042159.NAA06345@toad.com>
Reply To: N/A
UTC Datetime: 1997-02-04 21:59:51 UTC
Raw Date: Tue, 4 Feb 1997 13:59:51 -0800 (PST)

Raw message

From: Marshall Clow <mclow@owl.csusm.edu>
Date: Tue, 4 Feb 1997 13:59:51 -0800 (PST)
To: cypherpunks@toad.com
Subject: IBM's SecureWay Key Recovery technology
Message-ID: <199702042159.NAA06345@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


>From <http://www.ibm.com/Security/html/prkeyrec.html>:

>At the RSA Conference, IBM announced the details of its highly
>anticipated SecureWay key recovery technology. IBM is developing this
>technology in response to market demands for exportable strong
>encryption required to advance the growth of global e-business.
>[ yada yada yada snipped ]

I attended this presentation. Basically, what they do is to add
two packets to the "channel setup process", one that depends only
on the coorespondents, the other that contains the information
about this particular session.

A problem with this, as I pointed out to the presenters, is
that the first packet can be trivially used for traffic analysis.
The eavesdropper may not be able to determine who is
cooresponding, but they can tell if it is the same people
as in a previous conversation.


>From <http://www.ibm.com/security/html/wp_keyrec2.html>
>In order to minimize the preparation overhead, the recovery information
>is prepared in two phases: one phase is independent of the particular
>session/archive key being prepared; the second phase is dependent on the
>particular key and session parameters. The first phase, which uses
>public-key encryption, can be shared across multiple invocations of key
>recovery preparation, thus reducing overhead. The public-key encryptions
>can be stored for repeated use.
>
As you can see, IBM suggests cacheing the contents of the
first packet, so that you don't have to recalculate it each
time. Imagine how easy traffic analysis would be if the
identification packets were identical instead of just related.



-- Marshall

Marshall Clow     Aladdin Systems   <mailto:mclow@mailhost2.csusm.edu>

Warning: Objects in calendar are closer than they appear.








Thread