CryptoTagger
Flags endpoints that perform cryptographic operations — encryption / decryption, signing / verification, hashing, or key management. These warrant review for weak or obsolete algorithms, padding/signing oracles, static IV/salt/nonce reuse, and key exposure or mismanagement.
key, sign, and verify are deliberately not standalone signals:
"API key", "sign in", and "verify email" are overwhelmingly non-crypto.
Bare auth routes (/signin, /signup) therefore never match here.
Constants
Parameter names that imply a crypto operation on their own (the plaintext/ciphertext payloads, named key material, passphrases).
Unambiguous crypto path segments — one is enough. Matched as whole
segments after splitting on /, -, _, .. Includes named
primitives (aes/rsa/sha256/bcrypt/…) and key-management verbs that
carry no benign meaning as a standalone path segment. Legacy/weak
algorithms (md5/sha1/rc4/3des/blowfish) are kept on purpose — surfacing
an endpoint that still uses one is the point of this tag. Each named
primitive carries a digit or is otherwise distinctive enough to never
collide with a benign word as a whole path segment.
Weaker signals: meaningful for crypto but also seen elsewhere. Tag
only when at least two distinct tokens co-occur (across path and
params). verify, iv, algo, and fingerprint are intentionally
absent — each pairs spuriously with benign tokens (e-sign "verify",
invoice "iv", recommendation "algo", device "fingerprint").