Difference between revisions of "Anonymous Data Retrieval Protocol"

From xx network wiki
Jump to navigation Jump to search
m (Protected "Anonymous Data Retrieval Protocol" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)))
m
 
Line 1: Line 1:
The Anonymous Data Retrieval Protocol (ADRP) allows users to request data anonymously from a server without revealing their identity. With normal [end-to-end] relationships in the xx network, the users know the identity of whom they are talking to. With ADRP, a user can send a request to another user containing a one-time-use key negotiation for an entirely new user. The recipient can then respond to it without ever knowing the original sender. When ADRP is combined with the metadata shredding of the cMix protocol encapsulation, it provides a powerful anonymous data lookup.
The Anonymous Data Retrieval Protocol (ADRP) allows users to request data anonymously from a server without ever revealing their identity. With normal [[End-to-End Encrypted Messaging in xx Messenger|end-to-end]] connections in the xx network, users always know the identity of whom they are messaging. With ADRP, one can send a request to another user containing a one-time-use key negotiation for an entirely new user. The recipient can respond to the negotiation without ever knowing the identity of the original sender. When ADRP is combined with the metadata shredding capability of the cMix protocol encapsulation, a powerful anonymous data lookup is guaranteed.


This protocol is open for use with the [xxDK] and is the basis for the [User Discovery system]’s privacy.
This protocol is open for use with the [https://git.xx.network/elixxir/client xxDK] and is the basis for the [[User Discovery]] system’s privacy.


=== Protocol Description ===
=== Protocol Description ===
The requestor needs to know the xx contact (cryptographic identity) of whom they are requesting on the network (A Diffie–Hellman key and a network identity). They then generate a new key pair and network identity, calculating a new symmetric Diffie–Hellman key using the new key and the recipient’s key. The payload contents are then encrypted with the new symmetric key via ChaCha20, with an appended HMAC.


The request is sent over cMix with the new public key in the clear and encrypted message contents in the same packet. On reception, the recipient can execute a Diffie–Hellman with the cleartext public key and decrypt the payload. The contents (and clear-text public key) can be used to create a response to the request to the new one-time-use identity. The responses are also encrypted via ChaCha20 with an appended HMAC.
The requestor needs to know the xx messenger contact details (cryptographic identity) of any user they request on the network (including a [https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange Diffie–Hellman key] and a network identity). xx messenger then generates a new key pair and network identity by calculating a new, symmetric [https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange Diffie–Hellman key] using the new key and the recipient’s key. The payload contents are then encrypted with the new symmetric key via [https://en.wikipedia.org/wiki/Salsa20#ChaCha_variant ChaCha20], with an appended HMAC.


The recipient can process the contents and then respond over the ad-hoc negotiated link. The sender received it by checking the network for receptions on the new identity.  
The request is sent over cMix in a single packet containing the new public key (in clear-text) and encrypted message contents. Once received, the recipient can execute a Diffie–Hellman with the clear-text public key and decrypt the payload. The contents (and clear-text public key) can be used to respond to the request from the new one-time-use identity. The responses are also encrypted via [https://en.wikipedia.org/wiki/Salsa20#ChaCha_variant ChaCha20], with an appended HMAC.
 
The recipient can then process the contents and respond via the ad-hoc negotiated link. Finally, the sender confirms receipt by checking the network for receptions on the new identity.


== Cryptographic Primitives Summary: ==
== Cryptographic Primitives Summary: ==
{| class="wikitable"
{| class="wikitable"
|Algorithm
!style="text-align:left;"| Algorithm  
|Length
!style="text-align:left;"| Length
|Description
!style="text-align:left;"| Description
|-
|-
|RSA
| RSA
|4096 bits
| 4096 bits
|Used as the signature algorithm for signing a fact or a key.  
| Used as the signature algorithm for signing a fact or a key.
|-
|-
|Blake2b
| Blake2b
|256 bits
| 256 bits
|Algorithm used for generating single-use specific fingerprints and keys. Additionally used for HMACs.
| Algorithm used for generating single-use specific fingerprints and keys. Additionally used for HMACs.
|-
|-
|Diffie Helmen
| Diffie Helmen
|3072 bits
| 3072 bits
|Discrete log-based component of key negotiation.
| Discrete log-based component of key negotiation.
|-
|-
|ChaCha20
| ChaCha20
|256 bits
| 256 bits (key)
|Messages and payloads are encrypted by ChaCha20.
| Messages and payloads are encrypted by ChaCha20.
|}
|}


== Resources ==
== Resources ==


* Single-Use Implementation  
* Single-Use [https://git.xx.network/elixxir/client/-/tree/release/single Implementation]
* Single-Use Cryptographic Library  
* Single-Use [https://git.xx.network/elixxir/crypto/-/tree/release/e2e/singleUse Cryptographic Library]
* ID Implementation (Ephemeral and Reception)  
* [https://git.xx.network/xx_network/primitives/-/tree/release/id ID Implementation (Ephemeral and Reception)]
* cMix Message Format
* [https://git.xx.network/elixxir/primitives/-/blob/release/format/message.go cMix Message Format]
* Sending cMix Messages
* [https://git.xx.network/elixxir/client/-/blob/release/network/message/sendCmix.go Sending cMix Messages]
 
= Single-Use - Complex Explanation =
The anonymous data retrieval protocol, also known as single-use, allows a user to request information on any individual without providing any record of the request that can be tied to the requestor. This is done by using single-use transmission messages—a message type that delivers a payload while simultaneously negotiating a new end-to-end relationship for a new, one-time use network identity. This allows the recipient to respond to the request without knowing who the sender is.
 
One of the headline uses for this design is a user contacting the user-discovery bot to search for other users without revealing their own identity.
 
== Protocol Description ==
This protocol description involves two generic entities, Alice and Bob, where Alice initiates contact, and Bob responds to the contact. Alice initiates contact by sending Bob a cMix message which will contain a request for some information (e.g., looking up a user in user discovery). This request and the follow-up response are specifically crafted and designed for anonymity using cMix. Below, we detail how Alice requests information from Bob, how Bob responds to that request, and how Alice receives Bob’s response.
 
=== Request ===
Alice first generates a key pair within the network’s group. Then, using the public key from this keypair and Bob’s Diffie-Helman public key, Alice generates a Diffie-Helman key for herself.
 
Alice will construct a special message with:
 
* a set tag (e.g., lookup, search)
* the max number of messages expected as part of Bob’s response (constants are set for each use case)
* and the payload containing the requested information
 
Alice generates a one-time use recipient ID and ephemeral ID for this single-use communication. The ephemeral ID is temporarily valid, with its validity period intended to encapsulate the timeframe in which the communication takes place. The reception ID is generated randomly.
 
A fingerprint is created using Bob’s DH key and a salt. An encryption key is generated using Alice’s DH key and another salt. Both previously mentioned salts are constants rather than randomly generated. The specifically crafted message is then encrypted using the encryption algorithm Salsa20. This is done using the fingerprint as the nonce, the marshaled message as the plaintext, and the encryption key. A message authentication code is created to verify the encrypted contents, using the encryption key, encrypted contents, and another specified salt.
 
Finally, Alice crafts a cMix message, placing the encrypted contents and her DH public key serialized into the contents section of the cMix message. The fingerprint and the MAC are also set in the cMix message. Finally, the message is sent along as any other cMix message to Bob.
 
=== Response ===
Bob receives the message from Alice, expecting a single-use message. He generates his own DH key using the key in the message and his own private key. This key should be identical to Alice’s encryption key, assuming proper communication and no disturbance or malice performed by either Alice, Bob, or a third party. Using this key, he will verify the MAC to ensure its authenticity.
 
After verification, he will decrypt the message. Then, using the tag indicating the type of request and the decrypted contents, Bob will construct a response to Alice. For example, if Alice were requesting a search for another user Carl from UDB, UDB would pull its information on how to contact Carl from its database and send that over to Alice. In most cases, the information Alice requests will not fit into a single cMix message, so the response is split into several messages, up to the max messages Alice specified in her request. Bob will send the responses to Alice's temporary reception ID. Each response message is encrypted using the Diffie-Helman key and the part number of the message. A fingerprint is also constructed using the DH key and part number.
 
=== Reception ===
Alice waits for the cMix message(s) on her reception ID. After sending the initial request, she preprocesses the reception of the multiple messages she expects from Bob by saving a set of fingerprints representing the part number of the message. The part key is generated and used to decrypt the partitioned message on the reception of a specific part. Standard MAC verification is performed on the message, and then the message is decrypted. The decrypted message is saved, and once all responses have been received, the partitions are collated into a single response. With the constructed response, Alice has now acquired the information she requested from Bob.

Latest revision as of 22:18, 20 January 2022

The Anonymous Data Retrieval Protocol (ADRP) allows users to request data anonymously from a server without ever revealing their identity. With normal end-to-end connections in the xx network, users always know the identity of whom they are messaging. With ADRP, one can send a request to another user containing a one-time-use key negotiation for an entirely new user. The recipient can respond to the negotiation without ever knowing the identity of the original sender. When ADRP is combined with the metadata shredding capability of the cMix protocol encapsulation, a powerful anonymous data lookup is guaranteed.

This protocol is open for use with the xxDK and is the basis for the User Discovery system’s privacy.

Protocol Description

The requestor needs to know the xx messenger contact details (cryptographic identity) of any user they request on the network (including a Diffie–Hellman key and a network identity). xx messenger then generates a new key pair and network identity by calculating a new, symmetric Diffie–Hellman key using the new key and the recipient’s key. The payload contents are then encrypted with the new symmetric key via ChaCha20, with an appended HMAC.

The request is sent over cMix in a single packet containing the new public key (in clear-text) and encrypted message contents. Once received, the recipient can execute a Diffie–Hellman with the clear-text public key and decrypt the payload. The contents (and clear-text public key) can be used to respond to the request from the new one-time-use identity. The responses are also encrypted via ChaCha20, with an appended HMAC.

The recipient can then process the contents and respond via the ad-hoc negotiated link. Finally, the sender confirms receipt by checking the network for receptions on the new identity.

Cryptographic Primitives Summary:

Algorithm Length Description
RSA 4096 bits Used as the signature algorithm for signing a fact or a key.
Blake2b 256 bits Algorithm used for generating single-use specific fingerprints and keys. Additionally used for HMACs.
Diffie Helmen 3072 bits Discrete log-based component of key negotiation.
ChaCha20 256 bits (key) Messages and payloads are encrypted by ChaCha20.

Resources