Answer Happy

Case Study
“This new BatFly messaging service solves the public key distribution problem,” announces
Watson cheerfully. “Suppose Alice wants to send a message m to Bob, but she’s not sure
what public key Bob is using at the moment. Alice sends the message to the BatFly server,
encrypted with the server’s public key to keep the message secret. Alice specifies that she
wants to send the message to Bob, and signs the whole thing with her private key to prove
that the message really is from her:
A → S : A, Ea
- [ B, Es
+ [ m ] ]
The BatFly server knows Bob’s up-to-date public key, and uses it to re-encrypt the message
m. Then the server signs everything for integrity, and sends it back to Alice:
S → A : S, Es
- [ B, Eb
+ [ m ] ]
Now Alice sends this message on to Bob using whatever app she likes.
The only public key that Alice has to know is the key for the server. And when Bob changes
his public key, he only has to tell the BatFly server, not everyone else. The server never
knows anybody else’s private key, and revocation is trivial!”
Holmes has been examining the protocol closely. “Doesn’t anything worry you about the
protocol at all, Watson?” he asks. “Well, now that you mention it,” replies Watson, “I’m a little
uneasy about encrypting and then signing. I was thinking of recommending to them that it
should be the other way round:
A → S : B, Es
+ [ A, Ea
- [ m ] ]
S → A : B, Eb
+ [ S, Es
- [ m ] ]
What do you think, Holmes?” Holmes shakes his head. “I think that if I were Moriarty I’d be
using BatFly to revoke my public key right now,” he replies enigmatically.