[san-zrl]

Add PyCryptodome/PyCrypto detection support for Python

This PR adds cryptography detection rules for the pycryptodome / pycrypto Python libraries, alongside several mapper and reorganizer improvements needed to support them. This PR completely replaces #495 with an implementation based on the named parameters using the new detection rule functions '.with[Optional]NamedMethodParameter' introduced in #527.

What's changed

• Mapper model — DigestSize.ofDefault() factory for compile-time-known sizes; RIPEMD cast constructor; SHA2 updated to use ofDefault.
• Pyca mappers — Extended PycaCipherMapper, PycaDigestMapper, PycaMacMapper with new algorithm entries (DES, RC2, Salsa20, RIPEMD160, MD2/MD4, KangarooTwelve, CSHAKE, TupleHash, …). New shared PycaCurveMapper and PycaKeyBasedAlgorithmMapper.
• Reorganizer rules — New ECDH→X25519/X448 replacement rules, moveNodesFromUnderFunctionalityUnderParent for Sign/Verify, WRAP_SHA512_TRUNCATED; all wired into PythonReorganizerRules.
• Detection rules — Pyca rules moved to detection/pyca/ subpackage. New detection/pycrypto/ package with rules for cipher, hash, KDF, key agreement, MAC, public key, random, and signature.
• Translation — New PycaKeyContextTranslator and PycaRandomContextTranslator; removed dead PycaSecretContextTranslator. Existing context translators extended with PyCryptodome-specific algorithm names, modes, and KDF parameters.
• Tests — Pyca test fixtures and Java test classes moved to test/pyca/ subpackage. New pycrypto test fixtures and test classes added.

[n1ckl0sk0rtge]

Thanks for adding PyCryptodome coverage. I checked the new rules against the official API docs and traced the mapper values through CBOM output. Several valid calls are missed, and some detected algorithms receive incorrect OIDs or size metadata; I left the concrete cases inline. mvn test -pl python -am -q passes, but some fixtures contain calls that PyCryptodome rejects at runtime.

[n1ckl0sk0rtge]

The new RSA, DSA, and ECC key rule sets are missing from this production registry. Their tests instantiate each set directly, so those tests pass even though standalone RSA.generate(), DSA.generate(), and ECC.generate() calls will not run these rules in normal scans. Could we register all three and add a test through PythonDetectionRules? These are documented module-level APIs: RSA, DSA, ECC.

[san-zrl]

RSA, DSA, and ECC key rule sets were deliberately omitted from registration as "first-class" objects to avoid duplicate detections. RSA, DSA, and ECC keys are always used in combination with higher-level crypto concepts. One such example are PKCS1v15 signatures.

message = b'To be signed'
key = RSA.import_key(open('private_key.der').read())
h = SHA256.new(message)                              # Noncompliant {{(MessageDigest) SHA-256}}
scheme = pkcs1_15.new(rsa_key=key)                   # Noncompliant {{(Signature) RSA-PKCS1-1.5-SHA-256}}
signature = scheme.sign(h)

The detection rule for pkcs1_15.new(rsa_key=key) adds a dependent detection rule for RSA keys. This is also done for all other crypto use-cases where DSA or ECC key are needed. El Gamal key are special since PyCryptodome explicitly removed support for sign and verify. These detection rules are registered to detect the use of El Gamal since "code that uses such methods is doomed anyway. It should be fixed ASAP to use the algorithms available in Crypto.Signature and Crypto.Cipher."

If we also register RSA, DSA, and ECC key rule sets in PythonDetectionRules we get duplicate detections from the top-level rule and the dependent rule.

[san-zrl]

FYI: Here's an example what would happen if RSA, DSA, and ECC key rule sets were registered as top-level rules.

You will get two separate RSA key detections in the CBOM. They will not be deduplicated.

---

Step-by-Step Breakdown

1. How the Two Detections Occur

In PKCS1v15SignTestFile.py:

6 | key = RSA.import_key(open('private_key.der').read())
7 | h = SHA256.new(message)
8 | scheme = pkcs1_15.new(rsa_key=key)
9 | signature = scheme.sign(h)

1. Top-level Detection (PythonCryptoRSA):

   • If PythonCryptoRSA is registered in PythonDetectionRules, PythonBaseDetectionRule.visitCallExpression(...) visits RSA.import_key(...) at line 6.
   • The RSA_CONSTRUCT rule matches, producing an independent KeyContext finding translated to (Key) RSA.

2. Dependent Detection (PythonCryptoSignature:PKCS1V15):

   • When visiting pkcs1_15.new(rsa_key=key) at line 8, the PKCS1V15 detection rule runs.
   • Because PKCS1V15 registers PythonCryptoRSA as a depending detection rule on the rsa_key parameter (.addDependingDetectionRules(RuleSets.rulesOf(PythonCryptoRSA.class))), the engine traces key back to RSA.import_key(...) and attaches the RSA key finding as a child under the (Signature) RSA-PKCS1-1.5-SHA-256 detection tree.

---

2. Why Deduplication Does Not Occur in CBOM Generation

1. Component Identifier in CBOMOutputFile:

   • CBOMOutputFile maps and deduplicates components using their Component.getName().

2. Random UUID in RelatedCryptoMaterialComponentBuilder:

   • When translating a Key node into a CycloneDX component, RelatedCryptoMaterialComponentBuilder generates a random UUID and names the component:

     stringBuilder.append("@").append(this.uuid);
     this.component.setName(stringBuilder.toString()); // e.g. "key@<UUID>"

   • Because every key component instance generates a distinct UUID, their component names never collide in components.putIfAbsent(componentId, component).

---

Resulting CBOM Output

The generated CBOM will contain:

1. First Key Component: A standalone related-crypto-material component ("key@<UUID_1>") from the top-level RSA.import_key(...) detection.
2. Signature Component: An algorithm component for "RSA-PKCS1-1.5-SHA-256".
3. Second Key Component: Another related-crypto-material component ("key@<UUID_2>") registered as a dependency child of "RSA-PKCS1-1.5-SHA-256".

(This is why PyCrypto key classes such as PythonCryptoRSA, PythonCryptoDSA, and PythonCryptoECC are kept as dependent rules only and excluded from top-level PythonDetectionRules.)