Encryption
Hadinet Africa uses three distinct layers of encryption to protect data at rest, in transit, and on-chain. This page explains each layer in detail.
Three Layers of Encryption
| Layer | Algorithm | Purpose |
|---|---|---|
| Input encryption | TweetNaCl (Curve25519 + XSalsa20-Poly1305) | Encrypts all data before it reaches the blockchain |
| Document encryption | AES-256-GCM with PBKDF2 | Encrypts files before IPFS upload |
| Transport encryption | TLS 1.2/1.3 | Encrypts all API communication |
Layer 1: Input Encryption (Blockchain)
Every piece of data submitted to the Cartesi rollup is encrypted with the rollup's public key before it reaches the blockchain. This means:
- Blockchain observers cannot read the raw input data
- Only the Cartesi VM (running inside validators) can decrypt and process it
- Even if someone reads the blockchain directly, they see encrypted bytes
Technical Details
| Property | Value |
|---|---|
| Library | TweetNaCl |
| Key exchange | Curve25519 |
| Symmetric cipher | XSalsa20 |
| Authentication | Poly1305 |
| Key type | Rollup's public key (asymmetric) |
How It Works
- The frontend encrypts the input payload using the Cartesi rollup's public Curve25519 key
- The encrypted payload is submitted to the InputBox contract on Arbitrum
- The Cartesi VM decrypts the payload inside the deterministic execution environment
- The decrypted data is processed and stored in the rollup's SQLite database
- External observers see only the encrypted input — never the raw data
This ensures that even though the blockchain is a shared, replicated data structure, the actual content remains private.
Layer 2: Document Encryption (Vault)
Files in the document vault are encrypted using military-grade symmetric encryption before being uploaded to IPFS.
Technical Details
| Property | Value |
|---|---|
| Algorithm | AES-256-GCM |
| Key derivation | PBKDF2 |
| Salt | Unique random salt per document |
| Mode | Galois/Counter Mode (authenticated encryption) |
| Key location | Inside the attestor's TEE only |
How It Works
- The user uploads a document through the frontend
- The document is sent to the attestor's Trusted Execution Environment (TEE)
- A unique encryption key is derived using PBKDF2 with a random salt
- The document is encrypted with AES-256-GCM inside the TEE
- The encrypted blob is uploaded to IPFS via Pinata's private gateway
- Only the metadata (file name, type, size, IPFS hash) is recorded on-chain
Authenticated Encryption
AES-256-GCM provides authenticated encryption, which means:
- Confidentiality — the file contents cannot be read without the key
- Integrity — any tampering with the encrypted file is detectable
- Authentication — the decryptor can verify the file was encrypted by a legitimate source
If someone modifies even a single byte of the encrypted file on IPFS, the decryption will fail and the tampering will be detected.
Key Management
The encryption key exists only inside the attestor's TEE. This means:
- The server operator cannot access the key
- IPFS / Pinata cannot access the key
- The frontend never sees the key
- The key is protected by hardware-level isolation
Layer 3: Transport Encryption
All communication between components uses HTTPS/TLS:
| Connection | Protocol |
|---|---|
| User to Frontend | HTTPS (TLS 1.2/1.3) |
| Frontend to Attestor | HTTPS (TLS 1.2/1.3) |
| Attestor to KYC Provider | TLS via zkFetch tunnel |
| Attestor to IPFS (Pinata) | HTTPS |
| Attestor to Cartesi | HTTPS |
zkFetch TLS Tunnel
The connection between the attestor and the KYC provider uses zkFetch, which establishes a TLS tunnel with an additional property: the TLS session itself is used to generate zero-knowledge proofs. This means the transport encryption also serves as the foundation for the ZK proof generation.
Encryption Summary by Data Type
| Data | Encryption Layer | Algorithm | Who Can Decrypt |
|---|---|---|---|
| Rollup inputs | Input encryption | TweetNaCl | Cartesi VM only |
| Vault documents | Document encryption | AES-256-GCM | Attestor TEE only |
| API calls | Transport encryption | TLS 1.2/1.3 | Intended recipient |
| ZK proofs | Not encrypted (public) | N/A | Anyone (for verification) |
| On-chain metadata | Input encryption | TweetNaCl | Cartesi VM only |
Security Considerations
What If the Blockchain Is Read Directly?
All inputs are encrypted before submission. An observer reading the blockchain directly sees only encrypted bytes — they cannot determine the content of any input.
What If IPFS Storage Is Compromised?
All documents are encrypted with AES-256-GCM before upload. Even with full access to the IPFS storage, an attacker obtains only encrypted blobs. Without the decryption key (which is inside the TEE), the files are unreadable.
What If Network Traffic Is Intercepted?
All communications use TLS 1.2 or higher. The zkFetch tunnel provides additional cryptographic guarantees through ZK proof generation tied to the TLS session.
Next Steps
- System Overview — How all components fit together
- Trust Model — What you trust each component with
- Privacy Model — The complete data protection model