Overview
Built to stay secure even when the storage layer is fully breached
Most systems treat encryption as a boundary, once an attacker reaches the storage layer, the data is exposed. SecureShare assumes that boundary has already been crossed. Every file is encrypted before it ever touches disk, every ciphertext is signed to prove sender identity, and every security event is written to a tamper-evident audit trail, so the system remains trustworthy even under adversarial conditions.
This project implements the same cryptographic controls found in production-grade secure systems: the key exchange mechanisms behind TLS 1.3, the signature model used in secure messaging protocols, and the audit integrity patterns required by SOC 2 compliance frameworks.
"If an attacker can read every file on the server, they still cannot read a single encrypted file without the recipient's private key."
Technical Deep-Dive
The system enforces a strict verify-then-decrypt pipeline, signature verification runs first, before any key material is loaded or any decryption attempted. This eliminates an entire class of attack known as decryption oracle exploitation, where an attacker uses a system's error responses to gradually recover plaintext without the key. It is the same ordering principle mandated by OWASP cryptographic best practices.
RSA Key Transport
Uses RSA-2048 OAEP (RFC 8017) to wrap a randomly generated AES-256 session key.
- Straightforward and widely deployed
- If the recipient's long-term private key is ever compromised, every past session encrypted under it becomes retroactively readable
- Trade-off: no forward secrecy
ECDH + Perfect Forward Secrecy
Uses ECDH P-256 with an ephemeral keypair and HKDF-SHA256 (RFC 5869) to derive the session key.
- Mirrors the key exchange model at the heart of TLS 1.3 and the Signal Protocol
- The ephemeral private key is zeroed from memory immediately after derivation and never written to disk
- A future compromise of the recipient's long-term key reveals nothing about past sessions
The architecture diagram below illustrates the full pipeline: upload, key derivation, encryption, signing, storage, verification, and decryption, each step isolated into a dedicated cryptographic module. The storage layer is treated as fully compromised by design. Every artifact stored on disk, ciphertext, wrapped keys, signatures, is unreadable and unmodifiable without triggering a cryptographic failure.
Every operation, key generation, upload, download attempt, and verification failure, is written to an append-only audit log sealed with HMAC-SHA256. Each entry is individually verified on load. Any modification to a past record, however small, is detected and flagged without access to the server secret. This satisfies a core requirement in SOC 2 audit trail controls: tamper-evident, verifiable logging that an administrator cannot silently alter.
Impact & Metrics
- Every cryptographic guarantee is verified, tamper detection, key rejection, signature forgery, and round-trip integrity, with the test suite and live results available in the repository. Failure modes are tested as rigorously as the happy path.
- Two encryption modes demonstrate real-world key management trade-offs: RSA key transport for compatibility with existing PKI infrastructure, and ECDH with Perfect Forward Secrecy for environments where long-term key exposure is a credible threat, each backed by documented attack scenarios and residual risk analysis.
- The architecture was stress-tested against four adversarial attack classes: wrong key injection, ciphertext tampering, IV reuse under the same key, and signature forgery. Each attack was constructed, executed, and verified to fail at the correct point in the pipeline before any plaintext was released.
- The audit log integrity system detects both modification and deletion of log entries, using per-entry HMAC verification combined with a hash chain, surfacing two independent tamper signals without cascading false positives across unaffected rows.
Click to browse all screenshots with descriptions