How Secure Is a File Uploaded to Ellipticc?

Abstract

This article provides a technical, evidence-based description of Ellipticc’s file protection pipeline. We present design goals, a detailed protocol description (chunking, authenticated encryption, post-quantum key wrapping, manifest canonicalization and signing), a brief security analysis, limitations, and references to authoritative standards and specifications.

Introduction

Cloud storage systems must balance usability, performance, and security. Ellipticc prioritizes confidentiality, integrity, and long-term resilience against quantum-capable adversaries. The system combines established authenticated encryption schemes with NIST-selected post-quantum primitives and deterministic manifest signing to achieve these goals.

Threat model and design goals

• Adversary capabilities: network eavesdropping, server compromise, and future quantum attackers.
• Guarantees: confidentiality under E2EE, integrity via AEAD and hashed chunks, authenticity via dual signatures, and post-quantum resilience for key-wrapping and manifest signatures.

Protocol overview

1. Chunking

   Files are divided into fixed-size chunks (4,194,304 bytes). Fixed-size chunking simplifies parallelism and resumability and reduces retransmit costs. The final chunk may be shorter.

2. Content Encryption Key (CEK)

   A random 32-byte CEK is generated per file. The CEK is used with XChaCha20-Poly1305 to encrypt each chunk. Every chunk uses a unique nonce (derived from chunk index and a per-file unique value) to prevent nonce reuse.

3. Authenticated Encryption (XChaCha20-Poly1305)

   Each chunk is encrypted with XChaCha20-Poly1305 (see ChaCha20-Poly1305 specification: https://datatracker.ietf.org/doc/html/rfc8439). The “X” variant uses a larger 24-byte nonce (extended nonce) compared to the 12-byte nonce used by standard ChaCha20-Poly1305, reducing the risk of nonce reuse in large-scale chunking. The AEAD provides confidentiality and authenticated integrity tags per chunk.

4. Key Wrapping (Kyber768)

   The CEK is encapsulated using the user’s public KEM key (Kyber768). Kyber768 is one of the NIST-selected post-quantum KEM parameter sets (https://pq-crystals.org/kyber/; see NIST announcement: https://www.nist.gov/news-events/news/2022/07/nist-announces-first-four-quantum-resistant-cryptographic-algorithms). Only the user holding the corresponding private key can decapsulate the CEK.

5. Chunk Hashing (BLAKE3, MD5)

   For each chunk we compute:

   • BLAKE3 hash (primary integrity check and fast verification): https://blake3.io/
   • MD5 checksum for interoperability with legacy tools (note: MD5 is not collision-resistant and is provided for compatibility only; see RFC1321).

6. Manifest Canonicalization, Hashing, and Signing

   A canonical manifest (deterministic JSON) lists chunk entries (index, size, blake3, md5) and wrapped key objects. The manifest is canonicalized (JSON Canonicalization Scheme: RFC 8785) and hashed with SHA-512 (FIPS 180-4). The manifest hash is signed with both Dilithium2 (post-quantum; specification) and ed25519 (RFC 8032) to provide both legacy-compatible and quantum-resistant verification.

Example manifest (canonicalized JSON excerpt)

1
{
2
  "chunks": [
3
    { "index": 0, "size": 4194304, "blake3": "b3f3...", "md5": "5d4140..." },
4
    { "index": 1, "size": 4194304, "blake3": "a1c9...", "md5": "7d7930..." },
5
    { "index": 2, "size": 3966970, "blake3": "d2e1...", "md5": "9d5ed6..." }
6
  ],
7
  "wrapped_keys": [
8
    { "recipient": "user:[email protected]", "kem": "kyber768", "wrapped_cek": "BASE64..." }
9
  ],
10
  "manifest_hash": "SHA512_BASE64...",
11
  "signatures": {
12
    "dilithium2": "BASE64...",
13
    "ed25519": "BASE64..."
14
  }
15
}

Note: The above is a canonicalized representation intended as an illustrative example; actual manifests adhere strictly to the canonicalization rules and storage format used by our implementation.

Verification and retrieval

On download, the client performs these steps:

1. Verify the manifest signatures (Dilithium2 and/or ed25519) against the expected public keys.
2. Verify the manifest hash matches a canonicalized hashing of the manifest.
3. Decapsulate the CEK with the user’s Kyber private key.
4. Decrypt each chunk with XChaCha20-Poly1305, verifying the AEAD tag.
5. Recompute BLAKE3/MD5 hashes for each chunk and compare with manifest entries.

Successful completion of all steps yields a verified plaintext file; failure at any step indicates tampering or corruption.

Security Analysis

• Confidentiality: Provided by E2EE using AEAD per chunk and post-quantum key encapsulation of the CEK.
• Integrity & Authenticity: AEAD, chunk hashes (BLAKE3), and manifest signatures (Dilithium2 + ed25519) provide layered integrity and provenance.
• Post-Quantum Considerations: Kyber and Dilithium are NIST-endorsed PQC constructions offering resilience against future quantum attacks; their use mitigates the risk of stored ciphertext being decrypted later by a quantum-capable adversary.
• Availability & Durability: Chunking allows parallel uploads and partial retransmits; however, data availability depends on server redundancy and user key management.

Limitations and caveats

• MD5 caveat: MD5 is included only for compatibility. Rely on BLAKE3 and manifest signature verification for security-critical integrity checks.
• Key loss: The zero-knowledge model makes key loss fatal to recovery; we recommend users securely backup private keys.
• No forward secrecy for stored data: Unless ephemeral wrapping keys or more advanced schemes (e.g., ratcheting or periodic re-encryption) are used, stored files do not provide forward secrecy in the classic sense.

Conclusion

Ellipticc’s design uses well-understood, vetted cryptographic primitives combined with canonical manifests and multi-algorithm signing to deliver strong confidentiality, integrity, and long-term resistance against quantum attackers. Proper key management and routine audits are essential complements to the cryptographic design.

References

• ChaCha20-Poly1305 (RFC 8439): https://datatracker.ietf.org/doc/html/rfc8439
• XChaCha20-Poly1305 background / libsodium: https://libsodium.org
• Kyber: https://pq-crystals.org/kyber/
• NIST PQC announcement: https://www.nist.gov/news-events/news/2022/07/nist-announces-first-four-quantum-resistant-cryptographic-algorithms
• Dilithium: https://pq-crystals.org/dilithium/
• ed25519 (RFC 8032): https://datatracker.ietf.org/doc/html/rfc8032
• BLAKE3: https://blake3.io/
• SHA-512 (FIPS 180-4): https://csrc.nist.gov/publications/detail/fips/180/4/final
• MD5 (RFC 1321): https://datatracker.ietf.org/doc/html/rfc1321
• JSON Canonicalization Scheme (RFC 8785): https://datatracker.ietf.org/doc/html/rfc8785