Bouncy Castle ist zweierlei zugleich: ein JCA-Provider (BC), der sich in Signature, KeyPairGenerator und KEM einklinkt, und schlanke APIs wie ECDSASigner, die ohne die JCA funktionieren. bcpkix ergänzt Zertifikate, CMS, OCSP und den PEMParser, der dem JDK bis heute fehlt. Der meiste JVM-Code, der mit secp256k1, Brainpool, PGP oder Zertifikaten arbeitet, hängt von Bouncy Castle ab.
Die ECDSA-Standardeinstellungen entsprechen denen des JDK: SHA256withECDSA erzeugt DER mit zufälliger Nonce und lässt s unnormalisiert, und die Prüfung akzeptiert beide Hälften (Low-S und High-S). Die Unterschiede stecken in Algorithmusnamen, die du ausdrücklich wählen musst. SHA256withPLAIN-ECDSA erzeugt das 64 Byte lange rohe r‖s, das JWS erwartet; SHA256withECDDSA signiert deterministisch, und der schlanke ECDSASigner mit einem HMacDSAKCalculator reproduzierte den Testvektor aus RFC 6979 exakt. Wie bei SunEC führt eine rohe Signatur für den DER-Algorithmus zu SignatureException, statt false zu liefern.
Die Kurvenauswahl ist für die meisten der Grund für Bouncy Castle: Mit P-224 bis P-521, secp256k1 und den Brainpool-r1-Kurven funktionierten Signieren und Prüfen, ebenso mit Ed25519 und Ed448. Registriere den Provider und gib ihn explizit an – KeyPairGenerator.getInstance("EC", "BC") –, denn sonst wird zuerst SunEC aus dem JDK befragt, und SunEC lehnt secp256k1 ab; das Beispiel umgeht genau das.
Die Post-Quanten-Unterstützung in 1.86 ist die breiteste aller geprüften Bibliotheken: ML-KEM über javax.crypto.KEM, ML-DSA, SLH-DSA und LMS im Provider BC sowie Falcon und XMSS in BCPQC. Probiere die Algorithmen im Playground für Post-Quanten-Signaturen aus und untersuche hybride Zertifikate mit dem PQ-Zertifikatsinspektor.
JcaPEMWriter schreibt private Schlüssel vom Typ EC als SEC1 -----BEGIN EC PRIVATE KEY-----, die PEMParser wieder als PEMKeyPair einliest; für Tools, die PKCS#8 erwarten, muss der Schlüssel erst konvertiert werden. Der Konverter DER ⇄ Raw hilft, wenn eine PLAIN- und eine DER-Signatur verwechselt werden.