A Zero-Knowledge encrypted cloud storage platform designed to guarantee end-to-end confidentiality through client-side cryptography.
This project simulates the core functionality of modern cloud storage systems while ensuring that the server never has access to plaintext files, encryption keys, or sensitive user secrets.
- End-to-End Encryption (E2EE)
- Client-Side File Encryption
- Hierarchical Key Management
- Secure File & Folder Management
- Secure File Sharing using RSA-OAEP
- Certificate-Based Strong Authentication
- Challenge-Response Verification
- Password Change without File Re-encryption
- AES-GCM Authenticated Encryption
- Recovery Key Mechanism
- ZIP Multi-Download Support
- Storage Quota Management
- Zero-Knowledge Architecture
The platform follows a Zero-Knowledge model:
- Files are encrypted locally before upload
- The server never sees plaintext data
- Encryption keys never leave the client in clear form
- Even a compromised server cannot decrypt user files
This guarantees structural confidentiality, not just contractual trust.
The platform is built around three core modules:
- User Management
- Cryptographic Key Management
- File & Folder Management
The system uses a layered key hierarchy to isolate compromises and improve security.
Password
↓ PBKDF2
KEK (Key Encryption Key)
↓ decrypts
RMK (Random Master Key)
↓ decrypts
FK (File Key)
↓ encrypts
Files (AES-GCM)
Derived from the user's password using:
- PBKDF2
- Random Salt
- High Iteration Count
- Encrypts the RMK
- Never stored permanently
- Recomputed during authentication
Randomly generated using a CSPRNG.
- Encrypts all File Keys
- Root cryptographic key of the system
- Stored only in encrypted form
Each file receives its own dedicated encryption key.
- Encrypts files using AES-GCM
- Ensures cryptographic isolation between files
Temporary key generated during authentication.
- Keeps RMK available during the session
- Destroyed on logout or session expiration
Generated during account creation.
- Recovers encrypted RMK
- Recovers encrypted RSA private key
- Allows account recovery in Zero-Knowledge mode
If lost, encrypted files may become permanently inaccessible.
Files are encrypted client-side using:
- AES-GCM
- Unique IV per encryption
- Authentication Tag
- Confidentiality
- Integrity
- Authentication
- Resistance against tampering
- Protection against padding oracle attacks
The platform supports secure sharing without breaking the Zero-Knowledge model.
- Files are encrypted using AES-GCM
- Each file has a dedicated FK
When sharing a file:
- The owner decrypts the FK locally
- The FK is encrypted with the recipient’s RSA public key
- The encrypted FK is sent to the server
- The recipient decrypts the FK using their RSA private key
At no point does the server access plaintext keys.
Owner
↓
Decrypt FK locally
↓
Encrypt FK with recipient RSA Public Key
↓
Send encrypted FK to server
↓
Recipient decrypts FK with RSA Private Key
↓
Decrypt file locally
To prevent MITM attacks during sharing, the platform integrates:
- MiniCertificates
- Digital Signatures
- Challenge-Response Authentication
At registration:
- User generates RSA signing keys
- Public signing key is sent to server
- Server signs user metadata
- A MiniCertificate is generated
The certificate links:
- User identity
- Public signature key
Before any file sharing operation:
The server generates:
- Nonce
- Challenge ID
The client signs:
- Nonce
- Challenge ID
- User identity
- Timestamp
using its private signing key.
The server verifies:
- Signature validity
- Challenge freshness
- Certificate authenticity
- Identity ownership
This proves possession of the private key.
Files are encrypted before upload.
AES-GCM authentication tags prevent unauthorized modifications.
Compromising one file key does not affect other files.
Challenge-response prevents identity spoofing.
No entity including the server is implicitly trusted.
- Hierarchical tree architecture
- Recursive deletion
- File/folder move support
- Unique names per directory
- Parent-child references
Supports:
- Multiple file uploads
- Folder uploads
- Preserving directory hierarchy
Each file is encrypted individually before upload.
Supports:
- Single file download
- Multi-file download
- Automatic ZIP generation client-side
Files are decrypted locally before ZIP packaging.
Changing the password does NOT require re-encrypting files.
- Old password derives current KEK
- KEK decrypts RMK
- New password derives new KEK
- RMK is re-encrypted using new KEK
- File Keys remain unchanged
- Files remain accessible
- Efficient password rotation
The system includes quota management:
- Maximum storage per user
- Real-time storage tracking
- Recursive quota updates
- Shared files counted only once
- AES-GCM
- RSA-OAEP (SHA-256)
- PBKDF2
- bcrypt
- JWT
- TLS
- Zero-Knowledge Architecture
- End-to-End Encryption
- Hybrid Encryption
- Challenge-Response Authentication
- Hierarchical Key Management
This project was developed as part of a cryptography and secure systems focused on:
- Cloud storage security
- Applied cryptography
- Zero-Knowledge systems
- Secure sharing architectures
In the current implementation, the server acts as a lightweight Certificate Authority (Mini-CA) responsible for generating and verifying MiniCertificates.
For a production-grade architecture, the Certificate Authority should be deployed on a separate trusted server isolated from the storage infrastructure. This separation reduces the risk of certificate forgery in case the main storage server is compromised and strengthens the trust model of the platform.