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.