🚀 go-pugleaf

In article <BxKLDM.Mss@sneaky.lonestar.org>, gordon@sneaky.lonestar.org (Gordon Burditt) writes:
>>1.  Caller activates call.  All 3 parties generate a random x and
>>exchange their values y = a^x mod p for some a and p.  All 3 parties
>>generate the key k in the style of DH but with 3 exponents instead
>>of 2.
> 
> You're proposing enough telephone-company equipment to be involved in
> EVERY telephone call in progress at once.  This is VERY expensive.  If 

I'm not so sure.  Switches are involved in every call right now.  
Also, the majority of calls are unlikely to be encrypted and key 
negotiation only takes  place at the beginning of a call.  But this
is a good point.

> the caller has to indicate that the call is encrypted, then he's not 
> going to do it. 

Wouldn't the calling device have to send a bit saying "I'm starting an
encrypted call" so that the called device would know that it's 
receiving an encrypted call anyway?    

> Also, this prohibits (or doesn't handle) bulk, non-interactive encryption,
> where the encryption is done well before the transmission.  This sort

Yes, the technique seems to mainly applicable to real-time phone calls.
I believe this is the area of greatest concern to LE.  
> 
> Would you care to suggest a cryptographic protocol for activating
> the devices only if there is a VALID warrant?  Assume that the government
> 
Let's say that a warrant has been obtained.  Then the telco would set
a flag in the switch, say, indicating that your communications stream
was to be intercepted.  The software in the switch would use this to
determine whether to send a copy of your stream to the government
monitoring station.  A similar strategy could be used to activate the
crypto device.

> It would also appear that the 3rd party devices could be used to perform
> a traffic analysis of all encrypted traffic, possibly without a warrant.
> 
The switches can do this already.  Indeed, I would suppose they do 
some traffic analysis anyway for the purpose of resource analysis and 
capacity planning.

> This proposal STILL doesn't deal with the possibility of encrypted
> "plaintext", the possibility that the sender doesn't USE the agreed-on
> session key, but uses a different one, and that you have to decrypt
> the transmission to catch someone doing this.

Yes, this is a problem.

Dorothy Denning
denning@cs.georgetown.edu