mystery number in web crypto as non-web3

Perfect — this is the right concrete question now.
Below is a practical, scanner-ready list of “mysterious numbers”, grouped by crypto type, with exact things to detect in code / configs, plus why they matter and what a green / red rule looks like.

Think of this as your v1 rule catalog.

0. Mental model (use this internally)

Every rule is:

(surface number found in code)
→ (known attack model)
→ (effective security bits)
→ GREEN / YELLOW / RED

You do not need to prove cryptography — just normalize risk.

1. Lattice / PQC / FHE / ZK backends

Parameters to detect

Parameter Where it appears Why devs get it wrong
n (dimension) TLS configs, Kyber params, FHE params Bigger ≠ safer if q/σ wrong
q (modulus) Hardcoded constants Often copied blindly
σ / η (noise) Defaults in libs Too small silently breaks security
logQ / modulus chain FHE configs Noise budget misunderstood
k (module rank) MLWE Structure reduces security
β (implicit) Not written Determines attack cost

Example patterns (what to scan)

// Kyber-like config
{
  "n": 256,
  "q": 3329,
  "eta": 2
}

let params = LweParams {
    dimension: 512,
    modulus: 12289,
    sigma: 3.2
};

Simple rules

  • ❌ n < 256 → RED

  • ❌ sigma too small for q → RED

  • ⚠️ MLWE without margin over NIST params → YELLOW

  • ✅ Estimated bits ≥ 128 → GREEN

2. RSA

Mysterious numbers

Parameter Where Why
Modulus size Key files, certs Devs assume “big enough”
Public exponent e Often ignored Small e has risks
Prime balance Never checked p ≈ q matters
Key lifetime Cert metadata Long-lived keys need more bits

What to scan

-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAv9E0...

tls:
  key_size: 2048

Rules

  • ❌ RSA-1024 → RED

  • ⚠️ RSA-2048 (long-term) → YELLOW

  • ✅ RSA-3072+ → GREEN

  • ❌ e = 3 → RED

3. ECC (classical & Web3)

Mysterious numbers

Parameter Where Why
Curve name Everywhere Curves ≠ equivalent
Field size Implicit Maps to √q security
Cofactor Rarely checked Breaks subgroup safety
Hash-to-curve ZK / BLS Domain separation bugs

Scan examples

using ECDSA for bytes32;
// secp256k1 implicit

elliptic.P256()

let curve = Bls12_381;

Rules

  • ❌ Custom curve → RED

  • ❌ secp160r1 → RED

  • ⚠️ secp256k1 (no domain sep) → YELLOW

  • ✅ P-256 / ed25519 / BLS12-381 → GREEN

4. Hash functions (HIGHEST ROI)

Mysterious numbers

Parameter Where Why
Output length Truncation Devs break birthday bound
Hash choice Dependencies SHA-1 still appears
Salt length Password hashing Too short = precomputation
Iteration count PBKDF Defaults outdated

Scan examples

crypto.createHash("sha1")

hashlib.sha256(data)[:16]

password_hash:
  algo: pbkdf2
  iterations: 10000

Rules

  • ❌ SHA-1 → RED

  • ❌ SHA-256 truncated <128 bits → RED

  • ⚠️ PBKDF2 <100k iters → YELLOW

  • ✅ Argon2id / bcrypt cost ≥ policy → GREEN

5. ZKP-specific (Groth16, PLONK, etc.)

Mysterious numbers

Parameter Where Why
Soundness error ε Circuit configs Devs don’t map to bits
Fiat–Shamir hash Transcript Domain errors catastrophic
Number of rounds Protocol params Too few = forgery risk
Trusted setup size Metadata Often misunderstood

Scan examples

[proof]
soundness = 1e-18
hash = "sha256"

pragma circom 2.1.0;

Rules

  • ❌ ε > 2⁻⁸⁰ → RED

  • ⚠️ ε between 2⁻⁸⁰ and 2⁻¹²⁸ → YELLOW

  • ✅ ε ≤ 2⁻¹²⁸ → GREEN

6. Web3 smart contracts

Mysterious numbers

Parameter Where Why
Curve choice Implicit Ethereum hardcodes secp256k1
Hash function Solidity keccak vs sha matters
Merkle depth Airdrops Too small → collisions
Multisig threshold Wallet config 1-of-N is meaningless

Scan examples

bytes32 leaf = keccak256(abi.encode(addr));

"multisig": { "m": 1, "n": 3 }

Rules

  • ❌ 1-of-N multisig → RED

  • ⚠️ Merkle depth < 32 → YELLOW

  • ❌ sha256 used inconsistently in EVM → RED

  • ✅ Well-known patterns → GREEN

7. FHE (advanced but huge future)

Mysterious numbers

Parameter Where Why
Ciphertext modulus Config Controls correctness & security
Depth Circuit Noise explosion
Bootstrapping params Hidden Devs cargo-cult

Example

{
  "logQ": [50, 50, 50],
  "n": 16384
}

Rules

  • ❌ No security margin after depth → RED

  • ⚠️ Tight noise budget → YELLOW

  • ✅ Margin ≥ X bits → GREEN

8. Minimal v1 rule set (what to ship first)

If you want maximum impact with minimal effort, start with:

  1. RSA key size

  2. ECC curve name

  3. Hash function + truncation

  4. Lattice (n, q, σ) → bits

  5. ZKP soundness ε

  6. Web3 multisig thresholds

That already catches 80% of real-world crypto footguns.

9. How this looks in API terms

{
  "finding": "RSA_MODULUS_TOO_SMALL",
  "location": "tls/config.yaml:12",
  "value": 2048,
  "security_bits": 112,
  "status": "YELLOW",
  "recommendation": "Use RSA-3072 or ECC"
}

That’s all buyers want.

If you want next

I can help you:

  • Turn this into a formal rule schema

  • Define green/yellow/red thresholds per industry

  • Design language-specific detectors (JS, Go, Rust, Solidity)

  • Create a compliance-friendly report format

This is exactly the right abstraction — you’re building a crypto lint engine, not a math tool.