PRId

A Pseudonymous Relationship Identifier is represented by the PRId object type.

Serialization

PRId object serialization MUST conform to the following Avro schema:

{
    "namespace": "org.dsnp",
    "name": "PRId",
    "type": "fixed",
    "size": 8,
    "doc": "Pseudonymous Relationship Identifier"
}

Generation

PRIds are generated cryptographically to represent a relationship from one user to another within a specified context, in a privacy-preserving manner.

Contexts

The following context values are currently defined for PRIds. All other values are reserved for future use.

Algorithm

In the following section, the Alice to Bob identifier for context C is called PRId_A→B,C, and the corresponding Bob to Alice identifier is called PRId_B→A,C.

A PRId is derived from Alice and Bob's keyAgreement key pairs, using a key exchange protocol as follows. To illustrate the cryptographic operations required, the relevant functions from libsodium are noted. Sodium is a stable, fast, free, and cross-platform cryptography library, and supports all encryption algorithms used in the DSNP specification out of the box.

Definitions:

• IdA = DSNP User Id of A (little-endian)
• IdB = DSNP User Id of B (little-endian)

Algorithm:

1. Both Alice and Bob generate an asymmetric key pair for use with X25519 ECIES. Each publishes a Public Key Announcement with their generated public key with a keyType value of keyAgreement.

crypto_box_keypair(
  &a_public,
  &a_secret);
crypto_box_keypair(
  &b_public, 
  &b_secret);
  

(Apublic, Asecret) ← KGF()
(Bpublic, Bsecret) ← KGF()

2. When Alice wants to interact with Bob, she looks up Bob's public key and performs an X25519 Elliptic-curve Diffie-Hellman key exchange operation using her secret key and Bob's public key, generating a root shared secret.

crypto_box_beforenm(
  &root_shared_secret,
  b_public,
  a_secret);

RootSharedSecretAB ←
  ECDH(Bpublic, Asecret)

3. Alice derives a context-specific subkey CtxSharedSecretBob from the shared secret RootSharedSecret as the master key, Bob's DSNP User Id as the 64-bit key identifier, and the ASCII encoding of the PRId Context string ("PRIdCtx0" for connections).

crypto_kdf_derive_from_key(
  ctx_shared_secret,
  32,
  b_user_id,
  "PRIdCtx0",
  root_shared_secret);

CtxSharedSecretA→B ←
  Blake2b256(
    key = RootSharedSecretAB,
    message = {},
    salt = IdB || {0},
    personal = "PRIdCtx0" || {0})

4. Alice uses Bob's DSNP User Id to form an 8-byte little-endian message. Alice encrypts this message using XSalsa20 with the PRId key CtxSharedSecretA→B and a nonce of her own User Id (little-endian) followed by 16 zero bytes.

char nonce[24] = {0};
int i;
for (i = 0; i < 8; i++) {
  nonce[i] = (user_id_a >> (i*8))
    & 0xff;
}

crypto_secretbox_detached(
  &prid,
  &mac_unused,
  user_id_b,
  8,
  nonce,
  ctx_shared_secret);

PRIdA→B,C ←
  XSalsa20(
    message = IdB,
    key = CtxSharedSecretA→B,
    nonce = Padded24BytesLE(IdA)
  )

6. Alice adds the generated PRId to the relevant list of PRIds and publishes an updated copy via the Replace User Data Operation.

Similarly, Bob can calculate the same root shared secret RootSharedSecret using Alicepublic and Bobsecret and derive the same PRIdA→B,C in order to check if it is in Alice's published PRIds. Bob can also derive the PRId subkey for Alice's DSNP User Id and encrypt Alice's User Id, using his own as the nonce, to generate the Bob-to-Alice PRId (PRIdB→A,C), and then publish it to his own list, if desired.

If Alice or Bob wants to prove to a third party that their PRIds are in each other's PRId list, they can provide the third party with their own subkey CtxSharedSecretA→B or CtxSharedSecretB→A. The third party can repeat the encryption step using Alice and Bob's User Ids, and check that the output is present in the published set of PRIds. The root shared secret RootSharedSecret (used as a master key in this algorithm) should not be divulged.

Test Vector

For the following inputs:

An implementation of the PRId generation algorithm should produce the following outputs: