A production-grade, security-focused messaging and file sharing platform with complete end-to-end encryption, zero-knowledge architecture, and comprehensive attack defense mechanisms.
- Overview
- Key Features
- Technical Architecture
- Technology Stack
- Libraries & Dependencies
- Functional Details
- Security Features
- Project Accomplishments
- Installation & Setup
- Project Structure
- API Documentation
- Security Documentation
CryptShare E2E is a modern secure communication platform designed with security-first principles. The system implements:
- End-to-End Encryption: All messages and files encrypted on the client-side using AES-256-GCM
- Authenticated Key Exchange: CryptShare-KEX protocol using ECDH + ECDSA for secure key establishment
- Zero-Knowledge Architecture: Server never has access to plaintext data, private keys, or session keys
- Triple-Layer Replay Protection: Nonce + Timestamp + Sequence number defense mechanism
- Attack Mitigation: Comprehensive defenses against MITM attacks, replay attacks, and other threats
- AES-256-GCM: Authenticated encryption for messages and files (confidentiality + integrity)
- ECDH P-256: Elliptic Curve Diffie-Hellman for secure key agreement
- ECDSA P-256: Digital signatures for key exchange authentication
- HKDF-SHA256: Key derivation from shared secrets
- Dual-Key System:
- Conversation Keys (persistent across sessions)
- Session Keys (ephemeral, forward secrecy)
- Real-time encrypted messaging via WebSocket (Socket.IO)
- Message history with decryption capability
- Typing indicators and user presence
- Read receipts and delivery confirmation
- Persistent message storage (encrypted)
- End-to-end encrypted file sharing
- Chunked encryption for large files (64KB chunks)
- Client-side encryption before upload
- Secure file downloads with decryption
- File metadata encryption
- Secure registration and login
- Password hashing with bcrypt
- JWT-based authentication
- User profile management
- User discovery and contacts
- Triple-layer replay attack protection
- Man-in-the-Middle (MITM) attack prevention via ECDSA
- HTTPS/WSS (TLS 1.3) for transport security
- CORS protection
- Input validation and sanitization
- Security event logging
- Comprehensive security event logging
- Key exchange event tracking
- Message and file activity logs
- Attack detection and alerting
- Audit trail for compliance
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β CLIENT SIDE β
β βββββββββββββββββββ βββββββββββββββββββ βββββββββββββββββββ β
β β React App β β Web Crypto β β IndexedDB β β
β β (UI Layer) βββββΊβ API βββββΊβ (Key Store) β β
β βββββββββββββββββββ βββββββββββββββββββ βββββββββββββββββββ β
β β β
β β HTTPS/WSS (TLS 1.3) β
βββββββββββββΌββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β
βββββββββββββΌββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β β SERVER SIDE β
β βΌ β
β βββββββββββββββββββ βββββββββββββββββββ βββββββββββββββββββ β
β β Express.js βββββΊβ Socket.io β β MongoDB β β
β β (REST API) β β (Real-time) βββββΊβ (Ciphertext) β β
β βββββββββββββββββββ βββββββββββββββββββ βββββββββββββββββββ β
β β
β Server NEVER has access to: β
β β’ Private keys β’ Plaintext messages β’ Decrypted files β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
Each user has:
-
ECDSA P-256 Identity Keypair (for signing/verifying key exchange)
- Private key: Stored only in browser (IndexedDB) - never sent to server
- Public key: Stored on server for peer discovery
-
ECDH P-256 Long-Term Keypair (for conversation key derivation)
- Private key: Stored only in browser (IndexedDB)
- Public key: Stored on server for peer key fetching
-
Ephemeral ECDH Keypairs (for each session)
- Generated fresh for each key exchange
- Provides forward secrecy
- Discarded after session key derivation
- React.js 18.2.0 - UI framework and component library
- React Router 6.21.0 - Client-side routing and navigation
- Socket.IO Client 4.6.1 - Real-time bidirectional communication
- Axios 1.6.2 - HTTP client for API requests
- Web Crypto API - Native browser cryptography (AES-GCM, ECDH, ECDSA, HKDF)
- Node.js - Runtime environment
- Express.js 4.18.2 - Web framework and REST API
- Socket.IO 4.6.1 - Real-time communication server
- MongoDB 8.0.3 - NoSQL document database
- Mongoose 8.0.3 - MongoDB ODM and schema validation
- bcrypt 5.1.1 - Password hashing
- jsonwebtoken 9.0.2 - JWT token generation and verification
- dotenv 16.3.1 - Environment variable management
- Multer 1.4.5 - File upload middleware
- CORS 2.8.5 - Cross-Origin Resource Sharing
- react-scripts 5.0.1 - Build tools and development server
- nodemon 3.0.2 - Development server with auto-reload
The client uses the Web Crypto API (native browser cryptography) for all cryptographic operations:
SubtleCrypto.generateKey()- Key generation (ECDH, ECDSA)SubtleCrypto.deriveKey()- Key derivation (ECDH shared secret)SubtleCrypto.encrypt/decrypt()- AES-256-GCM encryptionSubtleCrypto.sign/verify()- ECDSA digital signaturesSubtleCrypto.deriveBits()- HKDF-SHA256 key derivationcrypto.getRandomValues()- Cryptographically secure random number generation
{
"react": "^18.2.0", // UI framework
"react-router-dom": "^6.21.0", // Routing
"socket.io-client": "^4.6.1", // WebSocket client
"axios": "^1.6.2" // HTTP requests
}{
"express": "^4.18.2", // Web framework
"socket.io": "^4.6.1", // WebSocket server
"mongoose": "^8.0.3", // MongoDB ODM
"bcrypt": "^5.1.1", // Password hashing
"jsonwebtoken": "^9.0.2", // JWT authentication
"multer": "^1.4.5-lts.1", // File uploads
"cors": "^2.8.5", // CORS middleware
"dotenv": "^16.3.1" // Env configuration
}Registration Flow:
- User provides email, username, and password
- Password is hashed using bcrypt (salt rounds: 10)
- ECDSA P-256 identity keypair generated on client
- ECDH P-256 long-term keypair generated on client
- User record created with password hash and public keys
- Private keys stored in browser IndexedDB
Login Flow:
- Username/password verified against bcrypt hash
- JWT token generated and returned
- Client retrieves stored keys from IndexedDB
- Session established
3-Message Authenticated Key Exchange:
Message 1: KEX_INIT (Alice β Server β Bob)
- Alice generates ephemeral ECDH keypair
- Constructs KEX_INIT with ephemeral public key, nonce, timestamp
- Signs message with ECDSA private key
- Server relays to Bob
Message 2: KEX_RESPONSE (Bob β Server β Alice)
- Bob generates ephemeral ECDH keypair
- Constructs KEX_RESPONSE with ephemeral public key, nonce binding, timestamp
- Signs message with ECDSA private key
- Server relays to Alice
Message 3: Session Key Derivation
- Both parties verify ECDSA signatures using known identity public keys
- Both compute ephemeral ECDH shared secret:
S = ECDH(my_eph_priv, peer_eph_pub) - Both derive session key using HKDF-SHA256:
K_sess = HKDF-SHA256(S, salt, info) - Session key established with forward secrecy
Persistent Key for Message History:
- User fetches peer's long-term ECDH public key
- Client computes ECDH shared secret:
S = ECDH(my_ecdh_priv, peer_ecdh_pub) - HKDF-SHA256 derives deterministic conversation key:
K_conv = HKDF-SHA256(S, salt, info) - Conversation key allows decryption of entire message history
- Same key derived consistently across sessions
Encryption:
- User types message
- Client selects key (prefer session key for forward secrecy)
- Generate random 96-bit IV (nonce)
- Encrypt plaintext using AES-256-GCM
- Attach replay protection metadata (nonce, timestamp, sequence)
- Emit via WebSocket with sender, recipient, ciphertext, IV, auth tag
Decryption:
- Receiver gets message from WebSocket
- Verify replay protection (checks nonce, timestamp, sequence)
- Retrieve appropriate key (session or conversation)
- Decrypt using AES-256-GCM with stored IV
- Verify authentication tag
- Display plaintext message
Encryption:
- User selects file to share
- File split into 64KB chunks
- Each chunk encrypted with same conversation/session key but unique IV
- Metadata (filename, size, type) encrypted separately
- Encrypted file uploaded to server via multipart form
- Server stores ciphertext blob without decryption
Decryption:
- Receiver fetches encrypted file
- Decrypt metadata to retrieve filename, size
- Download encrypted chunks
- Decrypt each chunk using stored key and corresponding IV
- Reassemble chunks into original file
- Save to user's device
Triple-Layer Defense:
- Nonce Layer: Random value with every message prevents exact replay
- Timestamp Layer: Message timestamp checked against server clock; rejects old messages (configurable window)
- Sequence Number Layer: Monotonic sequence counter per conversation pair; rejects duplicate sequences
Implementation:
{
messageId: uuid,
sender: alice_123,
recipient: bob_456,
ciphertext: base64,
iv: base64,
authTag: base64,
nonce: uuid,
timestamp: 1704067200000,
sequence: 42,
replayProtection: { nonce, timestamp, sequence }
}Protection Mechanism:
- All key exchange messages signed with ECDSA
- Receiver verifies signature using known peer identity public key
- If signature invalid: KEX aborts, alert user
- Attacker cannot forge/modify keys without knowing peer's identity private key
- Ephemeral keys prevent long-term compromise
- AES-256-GCM: 256-bit symmetric encryption with authentication
- ECDH P-256: 128-bit equivalent security for key agreement
- ECDSA P-256: Signature verification and authentication
- HKDF-SHA256: Secure key derivation
- CSPRNG: Cryptographically secure random number generation
- Forward Secrecy: Ephemeral keys ensure past sessions aren't compromised
- Authentication: ECDSA signatures prevent key substitution
- Integrity: AES-GCM authentication tags ensure data hasn't been tampered
- Zero-Knowledge: Server doesn't possess plaintext, keys, or sensitive data
- Replay Attacks: Triple-layer protection (nonce + timestamp + sequence)
- Man-in-the-Middle: ECDSA authentication and signature verification
- Key Compromise: Ephemeral keys and forward secrecy limit damage
- Brute Force: JWT token expiration and rate limiting
- Comprehensive security event logging
- Key exchange tracking
- Message/file activity logging
- Attack detection and alerts
- Audit trail for compliance
-
Core Cryptography Implementation
- β Web Crypto API integration for all crypto operations
- β AES-256-GCM encryption/decryption
- β ECDH key agreement (P-256)
- β ECDSA digital signatures (P-256)
- β HKDF-SHA256 key derivation
-
User Authentication & Registration
- β Secure password hashing with bcrypt
- β JWT-based authentication
- β User registration system
- β Login/logout functionality
-
Key Management
- β Client-side key generation (identity and ECDH)
- β IndexedDB key storage
- β Conversation key derivation
- β Session key derivation
- β Ephemeral key management
-
Key Exchange Protocol
- β CryptShare-KEX 3-message protocol
- β Authenticated key exchange via ECDSA
- β Nonce binding for anti-MITM
- β Session key derivation post-KEX
-
Real-Time Messaging
- β WebSocket communication via Socket.IO
- β Encrypted message transmission
- β Message history storage (ciphertext)
- β Typing indicators
- β User presence tracking
-
File Sharing
- β Chunked file encryption (64KB chunks)
- β Metadata encryption
- β Secure file upload/download
- β Client-side encryption before server upload
- β File decryption on download
-
Replay Attack Protection
- β Nonce-based replay prevention
- β Timestamp validation
- β Sequence number tracking
- β Triple-layer protection
-
UI/UX Components
- β Login page with validation
- β Registration form
- β Chat interface
- β File share interface
- β User list/contacts
- β Loading spinners and feedback
- β Password strength indicator
-
Security Monitoring
- β Security event logging
- β Key exchange logging
- β Message/file activity logging
- β Attack detection logging
- β Audit trail
-
Attack Demonstrations
- β MITM attack demo script
- β Replay attack demo script
- β Educational attack scenarios
-
Documentation
- β Threat model (STRIDE analysis)
- β System flow documentation
- β Alice-Bob scenario walkthrough
- β Architecture diagrams (drawio)
- β Security design documentation
- Node.js 14+ and npm
- MongoDB instance (local or remote)
- Modern web browser with Web Crypto API support
cd server
npm install
# Create .env file
echo "MONGODB_URI=mongodb://localhost:27017/cryptshare" > .env
echo "JWT_SECRET=your-super-secret-jwt-key" >> .env
echo "PORT=5000" >> .env
# Start server
npm start
# or with auto-reload
npm run devcd client
npm install
# Create .env file (optional)
echo "REACT_APP_API_URL=http://localhost:5000" > .env
# Start React app
npm startThe app will open at http://localhost:3000
CryptShare-E2E/
βββ client/ # React frontend
β βββ public/
β β βββ index.html # Main HTML file
β βββ src/
β β βββ App.js # Main app component
β β βββ index.js # React entry point
β β βββ components/
β β β βββ Chat.js # Chat interface
β β β βββ FileShare.js # File sharing
β β β βββ Login.js # Login form
β β β βββ Register.js # Registration form
β β β βββ common/
β β β βββ Button.js # Reusable button
β β β βββ FormInput.js # Form input component
β β β βββ Avatar.js # User avatar
β β β βββ LoadingSpinner.js
β β β βββ PasswordStrength.js
β β β βββ index.js
β β βββ crypto/
β β β βββ encryption.js # AES-256-GCM encryption
β β β βββ fileEncryption.js # File chunked encryption
β β β βββ keyExchange.js # CryptShare-KEX protocol
β β β βββ keys.js # Key generation
β β β βββ keyStore.js # IndexedDB key storage
β β β βββ sessionKeyStore.js # Session key management
β β β βββ conversationKey.js # Conversation key derivation
β β βββ hooks/
β β β βββ useKeyExchange.js # Key exchange React hook
β β βββ services/
β β β βββ api.js # API client
β β β βββ socket.js # Socket.IO setup
β β β βββ fileService.js # File operations
β β βββ utils/
β β βββ replayProtection.js # Replay attack defense
β βββ package.json
β
βββ server/ # Express backend
β βββ app.js # Express app setup
β βββ middleware/
β β βββ auth.js # JWT authentication
β β βββ replayProtection.js # Replay protection
β βββ models/
β β βββ User.js # User schema
β β βββ Message.js # Message schema
β β βββ File.js # File metadata schema
β β βββ Log.js # Security log schema
β βββ routes/
β β βββ auth.js # Auth endpoints
β β βββ messages.js # Message endpoints
β β βββ files.js # File endpoints
β β βββ logs.js # Log endpoints
β βββ services/
β β βββ logger.js # Security logging
β βββ uploads/ # Encrypted file storage
β βββ package.json
β
βββ attacks/ # Attack demonstration scripts
β βββ mitm-demo.js # MITM attack demo
β βββ replay-demo.js # Replay attack demo
β
βββ docs/ # Documentation
β βββ System-Flow.md # Complete system flow
β βββ Alice-Bob-Scenario.md # Alice-Bob walkthrough
β βββ Diagrams/
β β βββ Encryption-Decryption-Workflows.drawio
β β βββ Key-Exchange-Protocol.drawio
β βββ client-flows.drawio
β
βββ threat-model.md # STRIDE threat model
βββ README.md # This file
POST /api/auth/register
- Register new user
- Request:
{ username, email, password, publicKeys: { idPub, ecdhPub } } - Response:
{ userId, token }
POST /api/auth/login
- Login user
- Request:
{ username, password } - Response:
{ userId, token, user }
GET /api/messages/:conversationId
- Get message history
- Response:
[{ messageId, sender, recipient, ciphertext, iv, authTag, ... }]
POST /api/messages
- Store encrypted message
- Request:
{ sender, recipient, ciphertext, iv, authTag, ... }
POST /api/files/upload
- Upload encrypted file
- Multipart form:
encryptedFile, metadata
GET /api/files/:fileId
- Download encrypted file
- Response: Encrypted file blob
GET /api/keys/:userId
- Get user's public keys
- Response:
{ idPub, ecdhPub }
See threat-model.md for comprehensive STRIDE analysis covering:
- Spoofing threats and mitigations
- Tampering detection mechanisms
- Repudiation protections
- Information disclosure prevention
- Denial of service defenses
- Elevation of privilege protections
See docs/System-Flow.md for:
- Complete cryptographic flow
- Key derivation processes
- Encryption/decryption workflows
- Replay protection mechanisms
- MITM attack prevention
See docs/Alice-Bob-Scenario.md for:
- Step-by-step walkthrough
- Concrete user scenario
- Key exchange examples
- Message encryption process
- File sharing flow
MITM Attack Demo:
node attacks/mitm-demo.jsReplay Attack Demo:
node attacks/replay-demo.jsThese scripts demonstrate how the system defends against various attacks.
Created: December 2025
Security-First Design | Zero-Knowledge Architecture | End-to-End Encryption
For security vulnerabilities or concerns, please reach out directly.