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
- a deterministic secp256k1 keypair generator from BIP-39 mnemonics,
- 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() |
---|---|---|---|
Content | Length of | ||
Length in bytes | 4 bytes | 1020 (255 * 4 bytes) | variable |
Workflow: Sending a file
- The is retrieved from the CCIR.
- An ephemeral keypair is generated, and .
- The shared secret which will be used in symmetric encryption is computed from .
- File intermediate is encrypted using AES-GCM-256 with encryption key , and a randomly generated initialization vector, .
- The payload is created by concatenating .
- 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