1. Systems Architecture http://sar.informatik.hu-berlin.de Receiver Anonymity Matthias Füssel, Dennis Schneider June 5, 2007

2. 2 May 2006 - 2 Systems Architecture http://sar.informatik.hu-berlin.de Overview  Introduction  Examples  Standard communication scenario  Research Overview  Three criteria for receiver anonymity  ElGamal  Incomparable Public Keys  Properties of the Incomparable Public Key system  Open problems and real world usage

3. 3 May 2006 - 3 Systems Architecture http://sar.informatik.hu-berlin.de Introduction

4. 4 May 2006 - 4 Systems Architecture http://sar.informatik.hu-berlin.de Example 1: Drug Study

5. 5 May 2006 - 5 Systems Architecture http://sar.informatik.hu-berlin.de Example 2: National Security

6. 6 May 2006 - 6 Systems Architecture http://sar.informatik.hu-berlin.de Standard Communication Scenario

7. 7 May 2006 - 7 Systems Architecture http://sar.informatik.hu-berlin.de Research Overview  Pfitzmann and Waidner (1986): multicast, marked messages - Implicit address: only receiver can identify message as being send to him - Invisible implicit address: addresses can't be compared for equivalence - Public key cryptosystem can be used  Bellare et al. (2001): Key-Privacy - Formalized as cryptographic security property - Given 2 public keys and a ciphertext encrypted with one of them, an adversary cannot gain information about what key has been used.

8. 8 May 2006 - 8 Systems Architecture http://sar.informatik.hu-berlin.de Research Overview  Chaum (1981), Goldschlag, Reed and Syverson (1997,99): anonymous reply addresses - Reply address: chain of routers and encryption instructions - Each router obscures relation between incoming and outgoing messages  Golle et al. (2003): Universal Reencryption - Can change encrypted message unforeseeably, knowing only the public key - However, same private key can be used to decrypt it

9. 9 May 2006 - 9 Systems Architecture http://sar.informatik.hu-berlin.de Three Criteria for receiver anonymity Criteria for receiver-anonymity-assuring systems:  The receiver may generate a multitude of identities: He choses can choose between a large number of identities to use with every sender for every message.  Incomparability of anonymous identities: No adversary can decide weather two identities belong to the same receiver.  Efficiency of the chosen solution: The solution should have reasonable performance.

10. 10 May 2006 - 10 Systems Architecture http://sar.informatik.hu-berlin.de Excursus: ElGamal  Asymmetric encryption system  Relies on the security of discrete logarithms Receiver:  Creates an efficient description of a finite cyclic group G of the order q and a generator g of that group  Choses x out of {0,1,..., q-1}, his private key  Calculates h = g x  Publishes his public key (G,g,q,h) Sender, gets (G,g,q,h), wants to send a message m:  Choses a random r out of {0,1,...,q-1}  Calculates c 1 = g r, c 2 = mh r  Transmits (c 1,c 2 )

11. 11 May 2006 - 11 Systems Architecture http://sar.informatik.hu-berlin.de Incomparable Public Keys (Waters, Felten, Sahai 2003) Network view:  Messages are sent to multicast groups  Every multicast group member tries to decode every message to that group  Only the intended receiver succeeds Cryptology:  Uses an asymmetric cryptosystem  With many public keys belonging to one private key  Every two public keys are incomparable, i.e. no adversary can tell weather they belong to the same private key  So only one private key suffices

12. 12 May 2006 - 12 Systems Architecture http://sar.informatik.hu-berlin.de Incomparable Public Keys: Usage The receiver  generates a private key a  Constructs public keys of the form (g, g a )  Sends his request r, one key pair and his multicast group address d to the sender The sender  Receives the request, generates an answer m  Uses random component r and (g, g a ) to encrypt m  Sends the encrypted message m' to the multicast group

13. 13 May 2006 - 13 Systems Architecture http://sar.informatik.hu-berlin.de Key Generation  Choose one prime p with q := (p-1)/2 also prime  Private key: - Choose x < q - Key: x  Public key (for a given private key x) - Randomly choose g: quadratic residue in Z p * - Store (g, g x ) in a hash table - Key: (g, g x )

14. 14 May 2006 - 14 Systems Architecture http://sar.informatik.hu-berlin.de Encryption Input: public key (g, g x ), message message  Choose key K for symmetric cipher  Choose exponent r for ElGamal  Encrypt message as: (g r, (g x ) r K), H(r), E K (r, (g, g x ), message) where  E is random encryption with a symmetric cipher  H is a secure random hash function

15. 15 May 2006 - 15 Systems Architecture http://sar.informatik.hu-berlin.de Decryption Input: ciphertext ((d, e), h, M), private key x  Calculate K := e / d x  Decrypt M using K: r, (g, g x ), message  Check that h = H(r)  Check that (g, g x ) is a public key in the hash table  Check that g r = d  If all tests pass, output message, otherwise ignore it

16. 16 May 2006 - 16 Systems Architecture http://sar.informatik.hu-berlin.de Other Possible Approaches  Standard Asymmetric Key Scheme: one public key for all senders  Several Independent Symmetric Keys: one symmetric key for each sender  Several Independent Public Keys: one public/private key pair per sender  Message Markers: one public/private key pair per sender, marked messages

17. 17 May 2006 - 17 Systems Architecture http://sar.informatik.hu-berlin.de Incomparable Public Keys: Properties Advantages  Fulfills 3 criteria - Many public keys for one private key - Public keys are incomparable - Efficient, only one decryption attempt per message  No markers on messages  Robust: message loss is irrelevant  One public key can be used many times w/o loss of anonymity Disadvantages  Ciphertexts have twice the length of the unencrypted messages  Every member of a multicast group tries to decode every message of that group

18. 18 May 2006 - 18 Systems Architecture http://sar.informatik.hu-berlin.de Open problems, real world usage  Unsuitable for most communication protocols (which require replies/new requests from our receiver): - Is interaction incompatible with anonymity?  Multicasting is more theory than practice  How are multicast groups formed?  Relies on other methods to distribute public keys  Receiver anonymity has only a few use cases, mainly web access, where multicast does not scale

19. 19 May 2006 - 19 Systems Architecture http://sar.informatik.hu-berlin.de References  Waters, Felten, Sahai: Receiver Anonymity via Incomparable Public Keys. in Proceedings of the 10th ACM conference on Computer and communication security, ACM Press, 2003  Danezis: Better Anonymous Communications. University of Cambridge, Computer Laboratory, 2004  Menezes, Oorschot, Vanstone: Handbook of Applied Cryptography, 1996, CRC Press http://www.cacr.math.uwaterloo.ca/hac/  Wikipedia articles