Secure E2EE Messaging System - Sequential Implementation Plan

Project Overview

Course: Information Security - BSSE (7th Semester)
Team Size: 3 Members
Implementation Model: Sequential (Member 1 → Member 2 → Member 3)

---

Sequential Task Division (Code Implementation Only)

MEMBER 1: Foundation & Authentication Layer

Duration: Week 1-3
Prerequisites: None (Starting point)

Code Responsibilities:

1. Project Setup

   • Initialize Git repository (private)
   • Setup React.js frontend structure
   • Setup Node.js + Express backend
   • Configure MongoDB connection
   • Setup HTTPS configuration

2. User Authentication System

   • User registration API endpoint
   • User login API endpoint
   • Password hashing with bcrypt/argon2 (salt + hash)
   • JWT token generation for sessions
   • Protected route middleware

3. Asymmetric Key Generation

   • Client-side RSA-2048/3072 OR ECC (P-256/P-384) key pair generation
   • Use Web Crypto API (SubtleCrypto)
   • Generate keys on user registration

4. Secure Key Storage

   • Implement private key storage using Web Crypto API + IndexedDB
   • Public key storage in MongoDB (server)
   • Key retrieval functions
   • Justify and document secure storage approach

5. Basic Frontend Components

   • Registration page
   • Login page
   • Basic navigation structure
   • Key generation status display

Handoff to Member 2:

• Working auth system (register/login)
• Users can generate and securely store key pairs
• API endpoints documented
• Database schema for users and public keys
• Frontend routing structure ready

---

MEMBER 2: Key Exchange & Messaging Core

Duration: Week 4-6
Prerequisites: Member 1 must complete authentication & key generation

Code Responsibilities:

1. Custom Key Exchange Protocol

   • Design unique DH/ECDH variant
   • Implement Diffie-Hellman OR ECDH key exchange
   • Add digital signature mechanism for authentication
   • Implement HKDF or SHA-256 for session key derivation
   • Implement "Key Confirmation" final message
   • Draw protocol flow diagrams (for documentation)

2. End-to-End Message Encryption

   • Implement AES-256-GCM encryption (client-side)
   • Generate fresh random IV per message
   • Create authentication tag (MAC) per message
   • Message encryption function
   • Message decryption function

3. Message Storage & Retrieval

   • API endpoint to store encrypted messages
   • Store: ciphertext, IV, metadata (sender/receiver ID, timestamp)
   • API endpoint to retrieve messages
   • Never store plaintext on server

4. Replay Attack Protection

   • Implement nonces
   • Implement timestamps
   • Implement message sequence numbers/counters
   • Verification logic to reject replayed messages

5. Real-time Messaging (Optional)

   • Setup Socket.io for real-time chat
   • Emit/receive encrypted messages
   • Online/offline status

6. Messaging UI Components

   • Chat interface
   • Message send/receive display
   • Key exchange initiation UI
   • Decryption status indicators

Handoff to Member 3:

• Working key exchange protocol
• Encrypted messaging functionality (send/receive)
• Replay attack protection implemented
• Message encryption/decryption working
• Chat UI functional

---

MEMBER 3: File Sharing & Security Features

Duration: Week 7-8
Prerequisites: Member 2 must complete messaging core

Code Responsibilities:

1. Client-side File Encryption

   • Implement AES-256-GCM file encryption (client-side)
   • Split files into chunks (recommended)
   • Encrypt each chunk with fresh IV
   • Generate authentication tags

2. Encrypted File Upload

   • API endpoint for encrypted file upload
   • Store encrypted chunks on server
   • Store file metadata (name, size, type, sender, receiver)
   • Never store plaintext files

3. Encrypted File Download & Decryption

   • API endpoint to retrieve encrypted files
   • Client-side file decryption
   • Chunk reassembly
   • File download to user device

4. File Sharing UI Components

   • File upload interface
   • File encryption progress indicator
   • Shared files list
   • File download and decryption interface

5. Security Logging System

   • Log authentication attempts
   • Log key exchange attempts
   • Log failed message decryptions
   • Log detected replay attacks
   • Log invalid signatures
   • Log server-side metadata access
   • Create log viewing interface (admin panel)

6. Final Integration & Polish

   • Integrate all components
   • Error handling across all modules
   • Loading states and user feedback
   • Final UI/UX improvements

Final Output:

• Complete working E2EE system
• Message encryption ✓
• File sharing ✓
• Security logging ✓
• All features integrated

---

Shared Responsibilities (All Members)

Attack Demonstrations (Week 7)

All members collaborate:

• Create MITM attack demonstration
  • Script to intercept DH exchange without signatures
  • Show how digital signatures prevent MITM
• Create Replay attack demonstration
  • Script to replay captured messages
  • Show how nonces/timestamps/counters prevent replay
• Capture evidence:
  • Wireshark packet captures
  • BurpSuite logs
  • Screenshots of attacks

STRIDE Threat Modeling (Week 7-8)

All members collaborate:

• Identify threats using STRIDE framework
• Identify vulnerable components
• Propose countermeasures
• Map threats to implemented defenses
• Create threat model diagrams

Documentation (Week 8)

All members contribute:

• Member 1 writes: Authentication section, key generation, key storage
• Member 2 writes: Key exchange protocol, message encryption, replay protection
• Member 3 writes: File sharing, security logging, integration
• All write together: Introduction, problem statement, conclusion, evaluation

Report must include:

• Introduction & problem statement
• Threat model (STRIDE)
• Cryptographic design explanation
• Key exchange protocol diagrams
• Encryption/decryption workflows
• Attack demonstrations with evidence
• Logs and screenshots
• Architecture diagrams
• System evaluation & conclusion

Video Demonstration (Week 8)

All members participate:

• Script the video together
• Each member presents their component
• Demo flow:
  1. Protocol explanation
  2. User registration & key generation
  3. Key exchange demonstration
  4. Encrypted messaging demo
  5. Encrypted file upload/download
  6. MITM attack demo
  7. Replay attack demo
  8. Limitations and future improvements
• Duration: 10-15 minutes

GitHub Repository Preparation (Week 8)

All members collaborate:

• Clean code and add comments
• Create comprehensive README.md
• Setup instructions
• Architecture documentation
• Add screenshots
• Include Wireshark/BurpSuite test results
• Ensure equal Git contributions visible

---

Technology Stack

✅ ALLOWED Technologies

Frontend:

• React.js
• Web Crypto API (SubtleCrypto) - MANDATORY for client-side crypto
• IndexedDB - for private key storage
• Axios - for HTTP requests
• Socket.io-client (optional) - for real-time messaging

Backend:

• Node.js
• Express.js
• MongoDB - for metadata storage only
• Socket.io (optional) - for real-time features
• Node.js crypto module - for backend signatures only

Tools:

• Wireshark - packet analysis
• BurpSuite Community Edition - attack simulation
• OpenSSL CLI - testing

❌ FORBIDDEN Technologies

Strictly NOT allowed:

• Firebase or any third-party authentication
• Third-party E2EE libraries (Signal, Libsodium, OpenPGP.js)
• CryptoJS for RSA/ECC
• NodeForge
• Any pre-built cryptography wrappers
• ChatGPT for generating full code modules
• Pre-built encrypted messaging app code
• Pre-built templates for cryptographic core

⚠️ Limited Use

• ChatGPT/LLMs: Only for conceptual help or debugging, NOT for complete modules

---

Critical Requirements

Security Constraints (NON-NEGOTIABLE)

• ✅ All encryption MUST occur client-side
• ✅ Private keys NEVER leave the client device
• ✅ No plaintext stored, logged, or transmitted anywhere
• ✅ AES-256-GCM only (NO CBC, NO ECB)
• ✅ RSA key size ≥2048 bits
• ✅ ECC must use NIST curves (P-256 or P-384 only)
• ✅ IVs must be unpredictable and non-repeating
• ✅ All signature verification must include timestamp checks
• ✅ All communication over HTTPS

Implementation Constraints

• ✅ Implement at least 70% of cryptographic logic yourself
• ✅ Each group must create a UNIQUE key exchange protocol variant
• ✅ Provide REAL packet captures from YOUR system
• ✅ Code similarity with other groups must be <35%

Storage Rules

• ✅ Server stores: Encrypted data, IVs, MACs, metadata only
• ✅ Server NEVER stores: Plaintext, private keys, session keys
• ✅ Client stores: Private keys (encrypted in IndexedDB), session keys (memory only)

---

Implementation Timeline

Week	Member 1	Member 2	Member 3
1-3	🔨 Setup + Auth + Keys	⏳ Waiting	⏳ Waiting
4-6	✅ Complete	🔨 Key Exchange + Messaging	⏳ Waiting
7-8	✅ Complete	✅ Complete	🔨 File Sharing + Logging
7	🤝 Attack demos (ALL)	🤝 Attack demos (ALL)	🤝 Attack demos (ALL)
8	📝 Documentation (ALL)	📝 Documentation (ALL)	📝 Documentation (ALL)
8	🎥 Video (ALL)	🎥 Video (ALL)	🎥 Video (ALL)

---

Evaluation Criteria (100 Marks)

Component	Marks
Functional correctness	20
Cryptographic design & correctness	20
Key exchange protocol	15
Attack demonstration (MITM, replay)	15
Threat modeling & documentation	10
Logging & auditing	5
UI/UX and stability	5
Code quality & originality	10
TOTAL	100

---

Git Contribution Requirements

• ✅ Repository must be PRIVATE
• ✅ Each member must show EQUAL code contributions
• ✅ Use meaningful commit messages
• ✅ Regular commits throughout development (not bulk commits at end)
• ✅ Each member's work should be clearly visible in Git history

---

Final Deliverables Checklist

• Working E2EE application (messaging + file sharing)
• Complete project report (PDF)
• Video demonstration (10-15 min)
• GitHub repository with README
• Attack evidence (Wireshark/BurpSuite logs)
• Architecture diagrams
• Protocol flow diagrams
• Security logs screenshots
• STRIDE threat model document

---

Success Criteria

Your project is successful if:

1. Messages and files are NEVER in plaintext outside sender/receiver devices
2. Server cannot decrypt any user content
3. Key exchange protocol is unique and secure
4. MITM and replay attacks are demonstrated and defended against
5. All cryptographic operations use correct algorithms and parameters
6. System is stable and functional
7. Documentation is comprehensive and clear
8. Code shows originality and equal contributions