Function classify_algorithm 

pub fn classify_algorithm(
    family: Option<&str>,
    name: Option<&str>,
    oid: Option<&str>,
    parameter_set: Option<&str>,
    elliptic_curve: Option<&str>,
) -> AlgorithmClassification

Classify a cryptographic algorithm from whatever identity a CBOM provides.

Sources are consulted in decreasing order of authority:

1. family (CycloneDX 1.7 algorithmFamily), normalized through the alias table (case, _/ // separators, “SHA1”→“SHA-1”, “TDES”→“3DES”, “Kyber”→“ML-KEM”, …) with trailing sizes extracted (“ML-KEM-768” → ML-KEM + 768). A bare “SHA” family accompanied by a SHA-2 digest size in parameter_set reads as SHA-2 of that size (bare “SHA” means SHA-1 only in cipher-suite context).
2. oid (CycloneDX 1.6+ cryptoProperties.oid) via [classify_oid].
3. A declared-but-unrecognized family string is token-scanned as a last resort (“DES-CBC”, “AES-128-CBC”, “RSA/ECB/PKCS1Padding”), and the most severe mention wins — a mode/padding-qualified family must not silently classify as Unknown.
4. elliptic_curve (CycloneDX 1.7): any named curve marks the asset as classical elliptic-curve crypto.
5. name: word-boundary token matching via classify_algorithm_names_guarded, used only when both family and oid are absent — bounding false positives to assets that carry no structured identity at all. The most severe mention wins (“sha384-rsa-signature” is RSA, not SHA-384). Callers should only pass names of components that actually have crypto_properties.

The explicit parameter_set (CycloneDX parameterSetIdentifier) fills the parameter when the identity source did not carry one; failing that, the component name is mined for a size of the same family (“AES” + name “AES-256-GCM” → 256). The CycloneDX primitive field is deliberately not used for classification — it cannot distinguish, say, ML-DSA from ECDSA, and callers that need primitive-based decisions (symmetric-vs-asymmetric severity) already have it.