Keys and Shielded Addresses

An introduction to Hinkal's shielded addressing scheme

There are two main parts to each Hinkal account: the viewing keypair and the spending keypair.

• The viewing keypair is used to decrypt user commitments.

• The spending keypair is used to send notes from the associated account to other accounts.

The viewing key’s purpose is to scan the blockchain for UTXOs or commitments belonging to that key’s owner. Once decrypted they can be used during proof generation alongside the spending key.

The spending key’s purpose on the other hand is utilized in order to prove that the user has ownership of those UTXOs and therefore can spend them. The spending key participates in proof generation.

Hinkal accounts are generated using Ethereum accounts by having a user sign a message and deriving the Hinkal keys from the signed message. This ensures that as long as someone has access to their Ethereum account, they will be able to access their Hinkal account by signing a message.

The spending key: For spending keys generation, the Poseidon Hashing algorithm is used, which is designed for zero-knowledge proof systems like zkSNARKs.

The Poseidon operates over the $GF(p)$prime field. It contains a series of rounds each based on input permutations. The S-box routine is just an exponentiation number in the $GF(p)$field $(x^5)$. The number of S-box operations as well as round constants both are affected by the Poseidon’s parameter tuple $(t,f,p,c,m)$ where

• specifies is the number of S-box routines in one round,

• $f$ specifies the number of full rounds ($t$ S-box routines),
• $p$ specifies the number of partial rounds (one S-box routine),
• $c$ specifies an array with the round constants ($(f+p)×t$ dimension),
• $m$ specifies a mixing function square ($t×t$ dimension)

The Poseidon routine produces a resulting hash (over prime field) after $(f+p)$ rounds.

You can find more about the Poseidon Hash in the original paper published by Lorenzo Grassi et al.

The viewing key: For viewing keys, X25519 function, that utilizes the Curve25519 elliptic curve, is combined with XSalsa20 cipher and Poly1305 universal hash function.

X25519 is an elliptic curve Diffie-Hellman key exchange using Curve25519, released by Daniel J. Bernstein. It allows two independent parties to agree on a shared secret.

The specified curve is a Montgomery curve given by the equation: $y^2= x^3 + 486662x^2 + x$ , defined over the prime field with the prime number $2^{255}-19$. The base point on the curve is $x=9$, generating a cyclic subgroup with an order equal to the prime $2^{252} + 27742317777372353535851937790883648493$. The co-factor of this subgroup is 88, indicating that the subgroup's size is 1/8 of the elliptic curve group.

XSalsa20 is an extended version of the Salsa20 stream cipher, featuring a significantly longer nonce of 192 bits compared to Salsa20's 64 bits. It employs a 256-bit key and utilizes the initial 128 bits of the nonce to calculate a subkey. This subkey, along with the remaining 64 bits of the nonce, serves as input parameters for the Salsa20 function, responsible for generating the stream. Similar to Salsa20, XSalsa20 is resistant to timing attacks and includes a built-in 64-bit block counter to prevent the need for nonce incrementation after each block.

Poly1305 is a one-time authenticator designed by D. J. Bernstein. Poly1305 takes a 32-byte one-time key and a message and produces a 16-byte tag. This tag is used to authenticate the message. The key is partitioned into two parts, called "r" and "s". The pair (r,s) is unique, and unpredictable for each invocation.