Add support for ГОСТ Р 34.10 digital signatures

- Implemented the GostKeyValue class for handling public key parameters in ГОСТ Р 34.10 digital signatures.
- Created the GostSignedXml class to manage XML signatures using ГОСТ 34.10, including methods for computing and checking signatures.
- Developed the GostSignedXmlImpl class to encapsulate the signature computation logic and public key retrieval.
- Added specific key value classes for ГОСТ Р 34.10-2001, ГОСТ Р 34.10-2012/256, and ГОСТ Р 34.10-2012/512 to support different signature algorithms.
- Ensured compatibility with existing XML signature standards while integrating ГОСТ cryptography.

docs/security/crypto-routing-audit-2025-11-07.md

@@ -34,12 +34,14 @@ StellaOps:
     Registry:
       PreferredProviders:
         - default
+        - ru.openssl.gost
         - ru.pkcs11
       ActiveProfile: ru-offline
       Profiles:
         ru-offline:
           PreferredProviders:
             - ru.cryptopro.csp
+            - ru.openssl.gost
             - ru.pkcs11
     Pkcs11:
       Keys:
@@ -53,10 +55,27 @@ StellaOps:
         - KeyId: ru-csp-token
           ProviderName: "Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider"
           CertificateThumbprint: "<thumbprint>"
-          CertificateStoreLocation: LocalMachine
-          CertificateStoreName: My
+    OpenSsl:
+      Keys:
+        - KeyId: ru-openssl-token
+          PrivateKeyPath: /etc/stellaops/keys/ru-openssl.pem
+          PrivateKeyPassphraseEnvVar: RU_OPENSSL_PASS
+          SignatureFormat: Der
 ```
 
+Windows hosts still prefer `ru.cryptopro.csp`, but Linux deployments automatically fall back to the new `ru.openssl.gost` provider (BouncyCastle/OpenSSL-backed) so sovereign GOST signing works without CryptoPro.
+
+#### CLI quick check
+
+Use the diagnostics CLI to inspect providers or produce test signatures without editing service hosts:
+
+```bash
+dotnet run --project src/Tools/StellaOps.CryptoRu.Cli -- providers --config etc/rootpack/ru/crypto.profile.yaml --profile ru-offline
+dotnet run --project src/Tools/StellaOps.CryptoRu.Cli -- sign --config etc/rootpack/ru/crypto.profile.yaml --key-id ru-openssl-token --alg GOST12-256 --file samples/message.bin --format base64
+```
+
+The CLI accepts JSON or YAML configs, applies registry profile overrides, and prints the resolved provider name (for example, `ru.cryptopro.csp` on Windows and `ru.openssl.gost` on Linux).
+
 Call `builder.Services.AddStellaOpsCryptoRu(builder.Configuration)` to bind this configuration and register the RU providers with the correct preferred order.
 
 Each deployment picks a profile (`activeProfile`) that resolves to a deterministic provider order, and individual services call into `ICryptoProviderRegistry` rather than new-ing crypto stacks directly.
@@ -65,10 +84,8 @@ Each deployment picks a profile (`activeProfile`) that resolves to a determinist
 
 Even after the initial plug-ins landed, several sovereign-crypto deliverables remain outstanding. These items must be addressed before RootPack_RU can be treated as GA:
 
-1. **CryptoPro CSP integration** – `StellaOps.Cryptography.Plugin.CryptoPro` currently reuses the PKCS#11 core and never talks to CryptoPro CSP / GostCryptography. Replace it with a real CSP-backed signer, including certificate-store lookup and DER/raw normalization.
-2. **Ops CLI** – The promised `StellaOps.CryptoRu.Cli` (list keys, try-sign, emit determinism records) has not been implemented; operators are blind when staging PKCS#11/CryptoPro keys.
-3. **Integration tests** – There are zero CryptoPro/PKCS#11 tests in `src/__Libraries/__Tests/StellaOps.Cryptography.Tests/`. The RootPack validation script cannot validate hardware paths today.
-4. **Symmetric GOST** – Magma/Kuznyechik (RFC 5830 / RFC 7801) support is missing, so RU deployments cannot request sovereign symmetric encryption for exports/data-at-rest.
+1. **Integration tests** – There are zero CryptoPro/PKCS#11 tests in `src/__Libraries/__Tests/StellaOps.Cryptography.Tests/`. The RootPack validation script cannot validate hardware paths today.
+2. **Symmetric GOST** – Magma/Kuznyechik (RFC 5830 / RFC 7801) support is missing, so RU deployments cannot request sovereign symmetric encryption for exports/data-at-rest.
 5. **Host adoption** – Authority, Scanner, Concelier, etc. register only the default providers; none call the RU DI helpers or set `ActiveProfile = ru-offline`, leaving sovereign bundles inert.
 6. **Docs/runbooks** – RootPack docs reference the CLI/config/test harnesses, but they do not yet exist; we need explicit TODOs (see rootpack docs) and follow-up edits once tooling ships.