Subject: Re: Responses to Clipper Chip Discussion in RISKS-14.53

From: [email-masked] (Dorothy Denning)
Date: Sat, 24 Apr 93 14:39:12 EDT

Don Alvarez wrote

  Now, I have enough faith in the NSA's skills to trust that you can't pass the
  message to the user without also passing the escrow field, but I'd like to
  see that in writing.

That is certainly the intent.

  First, who knows F? If the cop on the street knows F then it quickly
  becomes so widely known that everyone knows it and you might as well send
  the serial number in the clear.  Ergo only the escrow agents know F.

F is embedded in every Clipper Chip, but like other chip keys, unknown to the
people who use them.  Only law enforcement will have a decoder box that allows
the law enforcement field to be decrypted. Initially, there will be just one
box, and it will be operated by the FBI.

	Second, what information does law enforcement get from the
	escrow agents?  Ideally, law enforcement only gets K, the
	session key governing the conversation for which they have a
	court order.  Unfortunately, in order for law enforcement to
	get *only* K (and not U), the escrow agents must get together
	and secretly combine U1 and U2 so that they can unwrap K and
	give it to law enforcement.  But then the escrow agents would
	also know K, and they would be able to decrypt messages
	themselves.  That's just a very short step away from the
	omniscient big-brother which the multiple-escrower scheme was
	designed to prevent.  The escrow agents must not allowed to
	exchange keys with each other.  Ergo, law enforcement must
	assemble U itself in order to find out K.  This means that law
	enforcement now knows the key to unlock every session key ever
	used on this phone.

It is imperative that law enforcement get U.  If they are tapping a line,
there may be dozens of calls on that line per day.  It would be totally
impractical to have to go to the escrow agents to get the session key for each
call.  It would be impossible to do real-time decryption under that
constraint.

	Things are starting to look bad, but what about F?  We never
	really figured out what F was for, we just said that only the
	escrow agents know F.  Well, now we know what F is for.  Even
	if law enforcement knows U, they still can't read messages
	without court orders, because they can't obtain E[K;U] without
	knowing F, and only escrow knows F.

For the same reason as above, it is imperative that law enforcement be able to
decode the law enforcement field in order to obtain E[K; U] and then decrypt
this to get K.  It is completely impractical to go the escrow agents for each
conversation.
 
Steve Holzworth wrote:
 
	I don't claim to be up on crypto, but it seems to me that once
	the "authorized tap" has been performed once, the agency in
	question now has a copy of the desired keys. They can use these
	keys at ANY time in the future to decrypt communications
	between these two parties (without having to go through the

After a tap has been completed, government attorneys are required to notify
the subjects of the electronic surveillance.  At that point, the subjects are
certainly free to purchase a new device with a new chip, or perhaps the
vendors could simply replace the chip.

  I have one outstanding question that I haven't seen asked yet.  Is there a
  time component in the encryption key? Since wiretaps are presumably
  authorized for certain time periods with both start and end dates, it should
  not be possible to decrypt an illegally monitored message.
 
I am unaware of any time component.  Current wiretap laws protect against
this.  Evidence collected after the warrant has expired can be thrown out in
court.  In addition, it is illegal for the service provider to implement an
intercept after a warrant has expired.  With the new technologies, law
enforcers will be incapable of executing a tap without the assistance of the
service provider.

Lars-Henrik Eriksson has written

  If the algorithm was made public, any weaknesses would be discovered
  in time. If it is classified, weaknesses may never be known, or known
  only to the parties who have access to the classified information.

The NSA has a long record of success with crypto, far better than any
individual or organization in the public community.  In addition, there are
plans to bring in expert cryptographers to assess the algorithm.

Dave Weingart wrote:

	It appears ... that two encryption devices, when they initiate
	a session, must exchange keys in order to decrypt each others
	messages.  Great, but here's my question...what's to stop
	someone at machine B (who's talking to machine A) from
	"recording" the key from machine A when the session is
	started?  Since it appears that the key is constant for each
	chip, machine B can now _always_ decrypt machine A's messages.

The unit keys that are embedded in the chips are not exchanged.  Instead,
machines A and B negotiate a session key K that is used only for that
particular conversation.

Jim Sims wrote:

        Seems a whole lot easier to just catch the key K during the
        negotiation between the boxes....

It is possible for both ends to negotiate a session key K without transmitting
any secret information at all, including K.  One way of doing this is with a
public-key distribution method. The Diffie-Hellman method works as follows.
Machine A picks a secret value xa, and machine B picks xb.  A sends the public
value ya = g^xa mod p to B and B sends yb = g^xb mod p to A, where p is a huge
prime and g is a global constant.  Then A computes the session key K = yb^xa
mod p = g^xbxa mod p, and B computes K = ya^xb mod p = g^xaxb mod p.  Both K's
are the same.  An eavesdropper sees ya and yb, but since xa and xb are not
known, cannot compute K.  For more information about key exchange, see for
example my book "Cryptography and Data Security" or some other crypto text.

Dorothy Denning [email-masked]

   [There were enough additional messages for several more issues,
   some raising points already covered by the above message.  I have
   somewhat arbitrarily selected a representative few for the rest of 
   this issue, trying to avoid duplication where possible.  There may
   be another issue or two yet to come out of the existing backlog.  
   PLEASE pardon some of the duplication.  It is virtually impossible
   for me to selectively choose a few nonoverlapping paragraphs from each
   message.  For those of you who wonder whether RISKS has been taken over
   by this discussion, there has been essentially no other topic of concern
   for the past week, although something may be brewing in the recent 
   near-fatal aircraft autopilot failure attributed to software.  PGN]