Re: No SKE in Daytona and other goodies

" that one guy" wrote:

>1) I've got Daytona running on a machine right next to me. It doesn't
>feature any type of key escrow. Come to think of it, it doesn't
>support data encryption.
>
>The version I have is build 683, which is supposed to be the
>next-to-last, so it's unlikely MS will suddenly start adding new
>stuff, especially since they're already late.

Oh please! Just how many times am I supposed to repeat my point that I make
no claims that any imminent release of Chicago or Daytona or System 7.2 is
likely to have SKE included? I've pointed out that the TIS algorithm is
only now being coded, but that the *general field* of key escrow seems to
involve some behind-the-scenes manouverings which should give us all pause.

Saying that "version 683" doesn't have SKE is beside the point.

The real issue is just how all the work on SKE described in the Denning
conference coming up in September (the full agenda is posted in the crypto
newsgroups) is to be implemented if *not* by the OS and system software
vendors.

The Microsoft guy who wrote the long letter to me on the various issues
involved, the tradeoffs, the export issue (apparently SKE will allow some
products to be exported that would otherwise be illegal to export), etc.,
is clearly working on this key escrow business. Only time will tell if
Microsoft has ever met with NIST/NSA on software key escrow...if they have,
and pressures were put on MS to comply with the new scheme, then we'll all
have reason to worry.

If Microsoft has never met with NIST/NSA or Denning or TIS on this matter,
and was only pursuing SKE research on its own initiative, without any
incentives or threats from the government, then I will withdraw my
speculations and cheer Microsoft on.

(The same thing applies to Novell, Apple, etc. I'm not picking on
Microsoft...I've just heard more substantive comments from them than from
other companies.)

I once again urge Microsoft to make this situation clearer. And I don't
mean with a predictable, pro forma, "We have no intentions of including
software key escrow at this time." Such corporatespeak comments are
useless.

We need to see a public debate on software key escrow, regardless of
Microsoft's involvement one way or another. And we shouldn't wait until the
press conference is held to announce the program!


--Tim May

..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets,
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
"National borders are just speed bumps on the information superhighway."

A technical question about the proposed SKE schemes: are they a proper superset
of non-escrowed pgp/ripem type systems (pk for key exchange/auth, private
session keys for privacy)? As a previous poster mentioned, users
could select null or locally controlled key escrow agents, and effectively
have a non-escrowed system. This would be possible only if the 
users one wished to communicate with did co-operate, and did somehow
exchange public keys with you in a non-escrowed fashion, right? 
Is this then a strong argument for the web-of-trust model?

If I am tottaly out in left field here, feel free to berate me
in private mail, and I'll post no further on this.

Andy

A technical question about the proposed SKE schemes: are they a
   proper superset of non-escrowed pgp/ripem type systems

I'm not sure what you mean by superset, but I suspect that however you
interpret it, the answer is no.

   As a previous
   poster mentioned, users could select null or locally controlled key
   escrow agents, and effectively have a non-escrowed system. 

The system I've seen (Whit's recollection of Steve Walker's) did not
allow a cooperating party to interoperate with a non-cooperating
party.  In other words, both correspondents must comply with gov't key
surrender, or neither.

Matt or Whit can comment better, since they've seen it first hand.

Eric

>   A technical question about the proposed SKE schemes: are they a
>   proper superset of non-escrowed pgp/ripem type systems
>
>I'm not sure what you mean by superset, but I suspect that however you
>interpret it, the answer is no.
>
>   As a previous
>   poster mentioned, users could select null or locally controlled key
>   escrow agents, and effectively have a non-escrowed system. 
>
>The system I've seen (Whit's recollection of Steve Walker's) did not
>allow a cooperating party to interoperate with a non-cooperating
>party.  In other words, both correspondents must comply with gov't key
>surrender, or neither.
>
>Matt or Whit can comment better, since they've seen it first hand.
>
>Eric

I just looked over the viewgraphs from the Karlshrue meeting; short of
breaking the signature scheme used to certify the "package instance"
public escrow key, there doesn;t appear to be any unilaterial action that
one party can take to interoperate with a "legal" recipient without
escrow.

Others have pointed out, however, that you can re-use other people's
public escrow keys (that you learned, for example, by communicating with
them) to thwart traffic analysis.  Of course, traffic analysis is not
one of the stated requirements of the system anyway.

Also, the TIS proposal involves "software" tamper resistance in the form
of code checksums that the verified at run time.  This is intended to
discourage bi-laterial escrow circumvention.  Of course, any software-
only scheme can be thwarted, but patches to disable it may be a bit
involved, depending on how well obfuscated the code is.

-matt