|
4 | 4 |
|
5 | 5 | **[Live Demo](https://systemslibrarian.github.io/crypto-lab-format-ward/)** |
6 | 6 |
|
7 | | -## Overview |
| 7 | +## 1. What It Is |
8 | 8 |
|
9 | | -Format Ward is a browser-based crypto lab demo for format-preserving encryption (FPE) using FF1 and FF3-1 from NIST SP 800-38G. |
| 9 | +Format Ward is a browser demo of format-preserving encryption using FF1 and FF3-1 with WebCrypto AES-CBC rounds in a Feistel construction. It solves the problem of protecting sensitive fields while keeping the original character set and field shape, so existing schema constraints continue to work. In this codebase, encryption and decryption are shown for PAN, SSN/phone/ZIP-style formats, and custom alphabets. This is a symmetric-key model: the same secret key material is required for both encryption and decryption. |
10 | 10 |
|
11 | | -The demo shows how sensitive values (credit cards, SSNs, phone numbers, ZIP codes, and custom-alphabet strings) can be encrypted while preserving original format constraints so legacy schema assumptions do not break. |
| 11 | +## 2. When to Use It |
12 | 12 |
|
13 | | -Primary standards references: |
| 13 | +- Legacy databases with strict field validation: FF1/FF3-1 let you encrypt values while preserving the original format, so downstream validators and fixed-width schemas continue to accept the data. |
| 14 | +- PAN tokenization workflows: preserving decimal length and structure helps payment pipelines that cannot immediately migrate away from format-bound interfaces. |
| 15 | +- Masked analytics for structured identifiers: FF1 can protect only the digit positions in SSN/phone-style strings while keeping separators in place for operational readability. |
| 16 | +- Cross-system data sharing where format compatibility is mandatory: custom-alphabet FF1 keeps agreed symbol sets and length invariant across parties. |
| 17 | +- Do not use this when you need authenticated encryption by itself: FF1/FF3-1 preserve format but do not replace integrity/authenticity controls at the protocol layer. |
14 | 18 |
|
15 | | -- NIST SP 800-38G: https://csrc.nist.gov/pubs/sp/800/38/g/final |
16 | | -- NIST SP 800-38G Rev.1 (FF3-1): https://csrc.nist.gov/pubs/sp/800/38/g/r1/final |
| 19 | +## 3. Live Demo |
17 | 20 |
|
18 | | -## What You Can Explore |
| 21 | +Live GitHub Pages demo: https://systemslibrarian.github.io/crypto-lab-format-ward/ |
19 | 22 |
|
20 | | -1. Credit Card Tokenization panel |
21 | | -2. SSN / Phone / Postal format masking panel |
22 | | -3. FF1 vs FF3-1 side-by-side timing and output comparison |
23 | | -4. Custom alphabet FF1 encryption and decryption |
| 23 | +The demo supports both encrypt and decrypt flows in each panel and displays round-trip results so you can verify reversibility. You can run FF1 and FF3-1 side-by-side, compare output and timing, and inspect Luhn validity behavior on ciphertext for PAN examples. Exposed controls include plaintext/format selectors, AES-256 key generation, FF1 tweak input, FF3-1 tweak input (14 hex chars), and custom alphabet selection. |
24 | 24 |
|
25 | | -## Primitives Used |
| 25 | +## 4. What Can Go Wrong |
26 | 26 |
|
27 | | -- FF1 (NIST SP 800-38G) |
28 | | -- FF3-1 (NIST SP 800-38G Rev.1) |
29 | | -- AES via WebCrypto (`AES-CBC`) as the underlying block primitive |
30 | | -- Feistel round structure per standard mode definitions |
| 27 | +- FF3-1 margin assumptions: FF3-1 has published differential-cryptanalysis results relative to FF1, which is why this demo marks FF1 as the preferred default for new systems. |
| 28 | +- Wrong tweak size for FF3-1: FF3-1 requires exactly a 56-bit tweak (14 hex chars), and using the wrong length breaks interoperability and security assumptions. |
| 29 | +- Small-domain misuse: very small message spaces reduce effective security for format-preserving schemes because exhaustive or statistical attacks become more practical. |
| 30 | +- Deterministic reuse patterns: reusing the same key/tweak configuration on repeated structured fields can leak equality patterns even though plaintext is hidden. |
| 31 | +- Alphabet/radix mismatch bugs: if application characters and radix mapping are inconsistent, encryption can fail or silently produce invalid domain behavior for downstream systems. |
31 | 32 |
|
32 | | -## Running Locally |
| 33 | +## 5. Real-World Usage |
33 | 34 |
|
34 | | -```bash |
35 | | -npm install |
36 | | -npm run dev |
37 | | -``` |
38 | | - |
39 | | -Build and preview: |
40 | | - |
41 | | -```bash |
42 | | -npm run build |
43 | | -npm run preview |
44 | | -``` |
45 | | - |
46 | | -## GitHub Pages |
47 | | - |
48 | | -The Vite base path is resolved automatically during GitHub Actions builds from `GITHUB_REPOSITORY`, so project-page deploys keep working after forks or repository renames. |
49 | | - |
50 | | -If you need to override it manually, set `PAGES_BASE_PATH` before building. |
51 | | - |
52 | | -Run vector checks: |
53 | | - |
54 | | -```bash |
55 | | -npm run test |
56 | | -``` |
57 | | - |
58 | | -## Security Notes |
59 | | - |
60 | | -- FF1 is the preferred choice for new deployments in this demo. |
61 | | -- FF3-1 has known differential-attack literature and reduced margin compared to FF1. |
62 | | -- The FF3/FF3-1 line of analysis was highlighted by Durak & Vaudenay (2017); this demo surfaces that caveat directly in UI and documentation. |
63 | | -- Always treat demo code as educational and validate operational choices against your threat model and compliance requirements. |
64 | | - |
65 | | -## Why This Matters |
66 | | - |
67 | | -Many production systems cannot change field lengths or character constraints without expensive schema and integration rewrites. |
68 | | - |
69 | | -FPE allows encryption while preserving the visible format shape, which is useful for tokenization, safe analytics, and controlled data sharing in constrained legacy environments. |
| 35 | +- NIST SP 800-38G and SP 800-38G Rev.1: these standards define FF1 and FF3-1 and are the baseline references used by compliant implementations. |
| 36 | +- PCI-oriented tokenization deployments: payment environments commonly use NIST FPE modes (especially FF1) to protect PAN data without breaking numeric format constraints. |
| 37 | +- OpenText Voltage SecureData: this enterprise data-protection platform documents format-preserving encryption deployments for structured fields. |
| 38 | +- Protegrity data protection platforms: Protegrity materials describe FPE usage for structured-data tokenization in regulated environments. |
| 39 | +- Application security toolkits such as Bouncy Castle: widely used libraries include FF1/FF3-1 primitives that are integrated into production JVM systems handling structured identifiers. |
70 | 40 |
|
71 | 41 | ## Related Demos |
72 | 42 |
|
73 | 43 | - crypto-compare (Format-Preserving Encryption category): https://github.com/systemslibrarian/crypto-compare |
74 | 44 | - crypto-lab landing page: https://github.com/systemslibrarian/crypto-lab |
75 | 45 | - crypto-lab-iron-letter: https://github.com/systemslibrarian/crypto-lab-iron-letter |
76 | 46 |
|
77 | | -So whether you eat or drink or whatever you do, do it all for the glory of God. — 1 Corinthians 10:31 |
| 47 | +> *"So whether you eat or drink or whatever you do, do it all for the glory of God." — 1 Corinthians 10:31* |
0 commit comments