ZKL Architecture

This file describes the cryptographic activities that take place in zk-Lokomotive’s platform and web applications.

Yigid BALABAN, [email protected]

Revision 3 20/09/2024

2. Cryptographic Activities

System Elements

The system elements are/will be described and discussed in the ZKL System Architecture document. This section is to provide a reminder/reference.

1. Key Derivation Service

The Key Derivation Service (or KDS for short) provides

  1. a deterministic secp256k1 keypair generator from BIP-39 mnemonics,
  2. a pseudo-random BIP-39 mnemonic generator through web-bip-39 package.

2. Cross-chain Identity Registry

The Cross-chain Identity Registry (or CCIR for short) provides a method to look up identities and their corresponding public keys.

3. Encrypted File Storage

The Encrypted File Storage is a distributed storage solution that allows the recipient to retrieve payloads that were uploaded for them.

4. Client

The client (the sender) generates the encrypted payload to be sent to the reciever, whose public key is retrieved via the CCIR. The workflow of sending an encrypted file for a recipient is described in the next section.

Workflows

Definitions

The , intermediate file format is as follows:

Bytes[0]..4[4]..1024[1024]…1024+len()
ContentLength of
Length in bytes4 bytes1020 (255 * 4 bytes)variable

Workflow: Sending a file

  1. The is retrieved from the CCIR.
  2. An ephemeral keypair is generated, and .
  3. The shared secret which will be used in symmetric encryption is computed from .
  4. File intermediate is encrypted using AES-GCM-256 with encryption key , and a randomly generated initialization vector, .
  5. The payload is created by concatenating .
  6. The payload is uploaded to the EFS.

Reminder

The MAC in the payload at step 7 is a result of using AES-GCM-256, which is selected in ECIES implementation in the Rust crate we consume through ecies/rs-wasm package.

Workflow: Receiving a file

TBE