The Problem
Cryptographic systems can fail when implementation details leak information that the algorithm itself was designed to protect. Padding-oracle attacks make that failure mode concrete: an attacker learns from validation behavior, not from the key.
This lab explains the attack path as an engineering lesson about error handling, observable behavior, and security testing.
What I Built
I built the workflow as a controlled lab: an intentionally vulnerable AES-CBC service, a byte-wise padding-oracle attack engine, a live visualization layer, a secure AES-256-GCM implementation, and analytics/reporting that make the defensive lesson concrete.
Project Overview
The lab is a public security exercise focused on understanding a cryptographic failure mode in a controlled environment.
My Contribution
- Built the intentionally vulnerable AES-CBC server and byte-wise padding-oracle attack engine.
- Created the live attack visualization, AES-256-GCM secure implementation, analytics/report generation, and demo workflow.
- Connected the lab stages with Docker Compose and tested error behavior plus defensive mitigations.
System Architecture
Oracle feedback loop
A controlled client sends modified ciphertext and learns from distinguishable validation responses.
The diagram describes a lab environment, not a real target or deployable exploit workflow.
Cryptography lab dashboard
A recreated lab view showing CBC oracle behavior, GCM probe status, and analytics output.
4 lab stages
AES-CBC vulnerable path
AES-GCM defense path
Visual uses safe sample data created for this portfolio page.
Technical Decisions
Frame the public explanation around observable validation behavior.
- The security lesson is easier to understand when the reader sees how implementation responses leak information.
- The page stays high level and avoids publishing step-by-step exploitation instructions.
- The project communicates applied security reasoning while staying appropriate for public review.
How I Work
Engineering Challenge
- The vulnerable CBC endpoint needed distinguishable validation responses for the controlled experiment while the GCM implementation returned uniform authentication failures.
- I compared the lab's vulnerable validation path with the authenticated-encryption probe and defensive behavior checks.
- The CBC stage exposed the controlled oracle feedback loop, while the GCM stage normalized failed authentication behavior.
- The lab demonstrates both the failure mode and the mitigation without claiming a real target or production exploit workflow.
Quality & Testing
Quality Evidence
Product engineering evidence
- The public repository documents controlled local lab execution, stage checks, analytics outputs, and defensive behavior validation.
- The repository evidence is local-lab oriented; no hosted CI result is published.
- The README documents vulnerable CBC, attack visualizer, secure GCM, and analytics stages.
Public page quality
- The diagram supplies an accessible description and text-based comparison.
- Small screens can scroll the architecture diagram horizontally.
- Published claims are limited to the public lab repository and demo evidence.
| Security concern | Public explanation | Defensive takeaway |
|---|---|---|
| Distinguishable errors | Validation behavior can leak information | Normalize error responses |
| Observable timing or status | Attackers learn from differences | Reduce externally visible clues |
| Lab iteration | Controlled tests reveal the failure mode | Test security-sensitive paths |
CBC Versus GCM
| Mode | Lab behavior | Public takeaway |
|---|---|---|
| AES-CBC with distinguishable padding validation | The controlled oracle path can leak information through responses | Encryption needs safe validation behavior and uniform errors |
| AES-GCM authenticated encryption | The lab's GCM probe is documented as eliminating the oracle surface | Prefer authenticated encryption for this class of failure |
Demo And Disclaimer
The public repository links a YouTube demo for the educational lab. This page is intentionally defense-oriented: it explains why observable validation behavior is dangerous, but it does not publish real targets, secret material, credentials, or operational exploitation instructions.
Results & Impact
This lab shows how I reason about security failures at the implementation boundary, where ordinary error handling choices can become part of the attack surface.
What I Learned
Security work rewards careful language. A useful public explanation can show the system shape, the failure mode, and the defensive lesson without publishing details that belong in a private lab notebook.