Vivek.portfolio

Cybersecurity / Full-Stack Systems

Adaptive Network Security System

This system implements sender, receiver, admin, simulation, and evaluation workflows around AES-GCM encrypted messages, SHCS and CPHS protection modes, a transparent risk-scoring engine, replay/HMAC controls, rate limits, audit logging, and recovery without plaintext exposure.

Public academic/full-stack cybersecurity project; not a third-party-certified production messenger.

Java Spring Boot Spring Security React TypeScript AES-GCM HMAC MySQL
Repository

Architecture

System view

Adaptive network security architecture Sender traffic passes through risk assessment and adaptive security modes before receiver unlock and admin recovery workflows. Sender encrypted payload Risk engine threat pressure puzzle failures session signals Adaptive mode NORMAL SHCS CPHS AES-GCM + HMAC timestamp/nonce replay checks Receiver puzzle unlock Audit hold/release Recorded evaluation sample High-intensity compromise: NORMAL 0.215, CPHS 0.065
Conceptual diagram of sender, risk assessment, adaptive security mode, receiver, and admin recovery states. Source: venkatavivekp-debug/Network-Security-Game

Evidence

Measured outcomes and constraints

Project metrics are kept close to their original context and paired with limitations where needed.

High-intensity compromise ratio

0.065 vs 0.215

CPHS versus NORMAL in the README's recorded evaluation sample.

GitHub

High-intensity resilience

0.782 vs 0.582

CPHS versus NORMAL in the same sample; higher is better in the repository table.

GitHub

Evaluation graph

20 nodes / 35 edges

The README sample uses numNodes=20, numEdges=35, defenseStrategy=REDUNDANCY.

GitHub

Metric Visualization

High-intensity sample compromise ratio

NORMAL

0.215 ratio

CPHS

0.065 ratio

The public README supports about a 3.3x lower compromise ratio for CPHS versus NORMAL in this recorded sample.

Bar lengths are scaled within this comparison only.

Workflow

How the system is organized

The workflow shows the main technical pieces and how they connect.

  1. Sender

    Creates encrypted messages and selects or requests protection modes.

  2. Risk assessment

    Scores threat pressure, puzzle failures, session anomalies, and admin threat level.

  3. Security mode

    NORMAL, SHCS, CPHS, or ADAPTIVE mode determines puzzle and packaging behavior.

  4. Secure transport

    AES-GCM encryption, HMAC integrity, timestamp/nonce replay checks, and rate limits.

  5. Receiver / admin recovery

    Receiver puzzle unlocks messages; admin workflows hold, release, audit, and recover without plaintext endpoints.

Problem

Secure communication workflows need to respond to changing threat signals without turning recovery into a plaintext bypass.

The project frames security as an attack-defense-recovery game and evaluates protection modes under varying threat intensity.

Context / Data

The system uses request/session state, puzzle outcomes, administrative threat level, and simulator-generated attack intensity as operating context.

The repository explicitly states that the adaptive policy is a transparent heuristic rather than a Nash-equilibrium solver.

What I Built

Implemented NORMAL, SHCS, CPHS, and ADAPTIVE modes around encrypted payload handling and receiver-side challenge gates.

Built sender, receiver, admin SOC, simulation, and evaluation screens so the system exposes threat state and recovery state directly.

Integrated OWASP-aligned engineering controls including RBAC, secure cookies, replay protection, HMAC validation, rate limits, secure headers, and strict API errors.

Architecture

Spring Boot handles mode selection, security workflow orchestration, session behavior, and backend application logic.

The React/TypeScript frontend presents sender, receiver, admin, simulation, and evaluation workflows.

Admin step-up supports controlled release/reset actions while the repository states admins cannot decrypt messages and no plaintext endpoint is exposed.

Evaluation / Results

The README table reports NORMAL, SHCS, CPHS, and ADAPTIVE behavior across low, medium, and high attack intensities.

In the high-intensity recorded sample, CPHS compromise ratio is 0.065 versus 0.215 for NORMAL; CPHS resilience is 0.782 versus 0.582 for NORMAL.

The README also says ADAPTIVE stayed close to NORMAL in the recorded run because its value depends on live risk signals escalating high enough.

Technical Lessons

Security UX should make protection mode, threat state, and recovery state legible to users and administrators.

Adaptive policies need transparent thresholds, audit trails, and careful evaluation; a heuristic policy should not be oversold as formal game-theoretic optimization.

Security prototypes are more credible when implementation controls and simulator limitations are both visible.

Limitations

The simulator abstracts network behavior and is not a real RF/UAV communication stack.

The adaptive policy is heuristic; the repository does not present it as a Nash-equilibrium solver.

The recorded ADAPTIVE behavior depends on live risk signals escalating high enough to trigger stronger modes.