GCHQ key escrow round 4 (Re: good uses for IBE -- non-interactive forward secrecy)

[Adam Back]

Having looked at the slides more carefully, it is now clear that both
the recipient and sender are offline with the identity server at time
of sending and receipt respectively (which is the normal construct for
IBE).

However the fairly extreme space inefficiency (192Kbytes per message
average for the key exchange) make the scheme I think effectively
unusable as a NIFS scheme.

Consider: you could alternatively just encode 1000 public keys in a
public key block, each of which expires one per day (using existing
openPGP formats) and consider that your NIFS system, and there would
be no message expansion (normal 128 bytes or so of key exchange
overhead per message).

So in fact it appears to be a resonable advance in IBE schemes, but
not practical as an NIFS system.  And IBE schemes are of course not a
good idea to use directly for most applications because the idetity
server can read all messages.

Time to get the rumor mill running that this is two things wrapped
into one: a piece of abstract theory, and round 4 (or whatever round
we've got to, with cloud cover/holloway, TTPs, licensed CAs etc) of
GCHQ attempts at forcing key escrow on the public.

(See the 2nd half of the set of slides for the text explaining how
this would be used.)

The secret splitting so there are two TTPs won't help you much if GCHQ
either owns, controls or can ask TTPs to cooperate, or if they have
the combined master keys.

Adam