Skip to main content
IBM 
ShopSupportDownloads
IBM HomeProductsConsultingIndustriesNewsAbout IBM
IBM : developerWorks : Security : Education - online courses
Introduction to cryptology: Pt. 3
Download tutorial zip fileView letter-sized PDF fileView A4-sized PDF fileE-mail this tutorial to a friend
Main menuSection menuGive feedback on this tutorialPreviousNext
4. "Exotic" protocols
  


Key escrow: Multiple recipient lists page 5 of 12


You are probably aware that most concrete public-key encryption systems actually use symmetric "session keys" to encrypt messages, and public keys only to encrypt these session keys. Computational speed considerations are the main motivation behind such split systems, but they also have desirable side effects. In fact, even when using entirely symmetric-key systems, the same sort of split systems can be useful. It is possible to encrypt a session key for multiple recipients, not merely for one. While youcould send the same encrypted message to multiple parties, it might be easier to simply attach multiple versions of the encrypted session key, and allow general distribution. This might look like the following:


	    
Let E{k} be a symmetric-key encryption algorithm.
Let S be a random session key.
Let M be a message.
Let Ka be Alice's public or symmetric key.
Let Kb be Bob's public or symmetric key.
Generate C = [E{S}(M), E{Ka}(S), E{Ka}(S))].
Make C available to both Alice and Bob.
Destroy S.

Either Alice or Bob can determine S from C. And once they have S, they can decrypt M. Other parties besides Alice and Bob have no access to S or M (C does use E with three keys over two messages, so this provides a bit of extra cipher text for attack). A nice property of C is that it is not much bigger than E{Ka}(M), which would be a direct way of encrypting for Alice only. Certainly, for megabyte messages and 128-bit keys, the extra session key encryption is insignificant.

If Alice is intended as the direct recipient, but Bob should be able to get access to M if he needs to (and at his own discretion), then this scheme would give Bob an "escrow key." For that matter, we could just send E{Ka}(S) to Bob, and forgo sending E{S}(M) to him at all; this would make sense if he had access to Alice's stored encrypted files, but not to her key. You can imagine these arrangements might make sense if you wish for an employer to have access to employees' messages should an employee quit (or die, or forget passwords). Of course, it leaves decryption at the employer's discretion (but this might be appropriate for company-related correspondence).


Main menuSection menuGive feedback on this tutorialPreviousNext
PrivacyLegalContact