Baseline Registry

The Classification Ladder

Where the Common Algorithms Sit

Hashes Symmetric Ciphers Asymmetric / Signatures Password Hashing Transport / Protocols The full registry is browsable in the Dashboard under Catalog → Algorithms , which shows status, min-key-bits, recommended replacement, PQC note, and the upstream standard reference. There is no CLI equivalent.

Minimum Key Sizes

The same algorithm name can be Acceptable above a threshold and Deprecated below it. The registry encodes minKeyBits (for asymmetric and symmetric) and minOutputBits (for hashes) so the verdict adapts to actual key sizes in the code. The Policy Engine lets you tighten these via minimums in your .korthex_policy.json - e.g. require RSA ≥ 3072 or AES ≥ 256.

Algorithm Name Normalization

The registry is case-insensitive and separator-insensitive. All of the following names resolve to the same rule: AES-256-GCM aes 256 gcm AES_256_GCM aes256gcm AES/256/GCM For in-house wrappers, register them in the policy file via algorithm-aliases so the registry maps your wrapper name to the underlying algorithm. See the Policy File Syntax section.

Deadlines & Standards Tracking

Every Deprecated entry carries an upstream deadline from the standards bodies. Findings show this deadline so engineers know how much runway they have. The registry is updated as standards evolve. Refresh bundles are delivered monthly (or pulled automatically on online installations). In air-gapped mode, refresh bundles are applied through the Dashboard. The CLI has no import subcommand and no path that reads a .cjsn bundle.

Inspecting the Registry

Registry inspection is Dashboard-only today. There is no CLI command that lists, searches, or exports the algorithm registry - korthex baseline is a different thing entirely (see below). Browse the registry under Catalog → Algorithms , or read the status of a specific algorithm off a scan: every finding carries algorithm , status , baseline_id and replace_with .

The finding baseline (korthex baseline)

korthex baseline does not manage the algorithm registry. It manages the crypto-finding baseline - the record of which findings are already known, so CI can fail on new ones only. It writes .korthex_baseline.krx into the project root. # Create the baseline from the latest scan korthex baseline init # Rebuild it after intentional fixes korthex baseline refresh # Show NEW and RESOLVED findings against the current baseline korthex baseline diff # Exit 0 when the scan matches the baseline, exit 2 on drift korthex baseline verify korthex check --baseline <file> consumes the same file for the NEW-finding gate (exit 20).