Re: Hack Lotus?

["Peter Trei" <trei@process.com>]

> "Peter Trei" writes:
> > I suspect that Lotus has not completely reworked it's security
> > system for the international version, and that they are in fact
> > doing a second public key operation on the 3 bytes of GAK'd data.
> 
> Likely.
> 
> > If they're nasty, they'll check on the receiving side as well, to
> > ensure that the LEAF and/or the espionage-enabling key have not been
> > patched in the sending 'International' version.
> 
> Nearly impossible. Why? Because they can only include the public key,
> and not the private key, of the GAK authority in the code. You can
> encrypt the three bytes of key, but it is very hard for a receiver
> other than the govvies to read them. There is no shared secret
> information or private information available, ergo, they can't check
> their LEAF equivalent.

Think it through. 

1 Alice generates session key K
2 encrypts with Bob's public key, producing Epb(K)
3 extracts 24 bits of K to make K'
4 encrypts with Eve's (spy) public key, producing Epe(K')

5 encrypts message under K, producing EsK(M)

6 sends EsK(M), Epb(K), Epge(K') to recipient (and possibliy Eve)

7 Bob's copy of lotus decrypts Epb(K), recovering K

8 Bob's copy of lotus repeats steps 4 & 5 above, and checks if
   it's version of Epe(K') matches the one sent. 

9 If it does,  decrypt EsK(M), and give it to Bob
   If it does not,  send a copy to the NSA, blowing the whistle on 
   Alice, who's running a hacked copy. 

Thus, you can prevent a non-complying copy  of Lotus from talking to 
a complying copy of Lotus, which is one of the goals of the GAKers.

> This is likely where the flaw in the scheme is -- it should be trivial
> to drop another public key in place of the government one and foil the
> entire thing with minimal effort. All will look normal until someone
> tries to use the GAK private key.

> Of course, I'll point out that 64 bit RC4 keys are still not
> particularly heartwarming...

Granted, but we don't know if they use RC4, DES, or what.

> Perry

Peter Trei
Senior Software Engineer
Purveyor Development Team                                
Process Software Corporation
http://www.process.com
trei@process.com