Impact
Explained cryptographic behavior through equations and executable checks.
Impact
Validated implementation assumptions for classical and modern schemes.
Impact
Produced walkthroughs that connect math, code, and security impact.
Deliverables
- Cryptographic analysis notebook
- Attack or validation scripts
- Technical explanation
Technical Overview
Cryptography tasks are easy to misstate when the math, implementation, and security claim are discussed separately. The project needed reproducible analysis that shows exactly why an algorithm, key choice, or protocol assumption succeeds or fails.
Architecture
flowchart TD
security_claim[Security claim] --> math_model[Math model]
math_model --> executable_check[Executable check]
executable_check --> edge_cases[Edge cases]
edge_cases --> final_conclusion[Finding or validation]
Model
with RSA correctness depending on key generation, padding discipline, and the secrecy of d rather than the formula alone.
Implementation Sketch
def rsa_roundtrip(m, e, d, n):
c = pow(m, e, n)
recovered = pow(c, d, n)
assert recovered == m
return c
# The equation is correct only when the surrounding protocol is correct.Engineering Approach
- State the primitive, adversary capability, and expected security property before coding.
- Use small reproducible examples to validate the math.
- Document implementation risks such as weak randomness, reused nonce values, padding mistakes, and incorrect key sizes.
Results
- Created clear cryptographic walkthroughs for encryption, hashing, modular arithmetic, RSA-style reasoning, and breaking simplified schemes.
- Used code to verify equations and avoid hand-wavy explanations.
- Translated security failures into practical remediation advice.
What This Demonstrates
- Cryptographic writing should identify the threat model before presenting the computation.
- A short proof-of-concept is valuable when it exposes an incorrect security assumption.
- Equations and tests should agree before a finding is considered complete.