Phill writes:
I've been thinking about how I would do the lotus hack. I certainly would not be wanting to do a public key operation for the benefit of the government on every message. How about the following:
During installation of program: Select a random key ER, encrypt it under the govt. public key to give Eg(ER). To start encrypting,
chose a random value R, encrypt under destination public key to give Ek(R)
set 40 bits of R to 0 to produce R' Encrypt R' under ER to give E-ER(R') Hash R, E-ER(R') and Eg(ER) with a one way function (MDMF like) to produce the actual key. Send across Ek(R), E-ER(R'), Eg(ER) To decrypt the message one needs the information for the escrow authority.
Phill
Wouldn't this interoperate only with other systems which had a similar setup? I suspect the Lotus wants the US-Domestic and the International versions to interoperate transparently, including with their older versions. Kaufman describes the encryption setup of Notes in moderate detail on pages 448-454 of 'Network Security'. It's a typical mixed system, with a secret key encrypted under the recipient's Public key (a short one or a long one, depending on the local of the recipient and/or sender). 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. 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. Peter Trei trei@process.com Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com 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. 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... Perry
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.
If the 3 GAK bytes are derived from the key & the secret key, couldn't it be done this way: * sender creates 64-bit session key K * sender encrypts K with recepient's public key (say P_r(K)) * sender encrypts top 3 GAK bytes w/GAK key The recipent can verify the GAK bytes by using it's copy of the GAK key on the top bytes of the session key. If the encrypted GAK bytes match what was sent, then they're valid. No need to have the secret key. --- Fletch __`'/| fletch@ain.bls.com "Lisa, in this house we obey the \ o.O' ______ 404 713-0414(w) Laws of Thermodynamics!" H. Simpson =(___)= -| Ack. | 404 315-7264(h) PGP Print: 8D8736A8FC59B2E6 8E675B341E378E43 U ------
participants (3)
-
Mike Fletcher -
Perry E. Metzger -
Peter Trei