O Bouncy Castle é duas coisas ao mesmo tempo: um provedor JCA (BC) que se integra a Signature, KeyPairGenerator e KEM, e APIs leves, como ECDSASigner, que funcionam sem a JCA. O bcpkix acrescenta certificados, CMS, OCSP e o PEMParser que ainda falta no JDK. A maior parte do código da JVM que lida com secp256k1, Brainpool, PGP ou certificados depende dele.
Os padrões de ECDSA coincidem com os do JDK: SHA256withECDSA produz DER com um nonce aleatório e deixa o s sem normalizar, e a verificação aceita as duas metades. As diferenças ficam em nomes de algoritmo que é preciso pedir explicitamente. SHA256withPLAIN-ECDSA produz o r‖s bruto de 64 bytes que o JWS espera; SHA256withECDDSA assina de forma determinística, e o ECDSASigner leve com um HMacDSAKCalculator reproduziu exatamente o vetor de teste da RFC 6979. Como no SunEC, uma assinatura bruta entregue ao algoritmo DER lança SignatureException em vez de retornar false.
A cobertura de curvas é o que traz a maioria das pessoas até aqui: da P-224 à P-521, a secp256k1 e as curvas Brainpool r1 passaram na assinatura e na verificação, assim como Ed25519 e Ed448. Registre o provedor e indique-o pelo nome — KeyPairGenerator.getInstance("EC", "BC") —, porque, caso contrário, o SunEC do JDK é consultado primeiro e rejeita a secp256k1, o que o exemplo evita.
A cobertura pós-quântica na versão 1.86 é a mais ampla entre as bibliotecas testadas: ML-KEM por meio de javax.crypto.KEM, ML-DSA, SLH-DSA e LMS no provedor BC, e Falcon e XMSS no BCPQC. Experimente os algoritmos no playground de assinaturas pós-quânticas e inspecione certificados híbridos com o inspetor de certificados pós-quânticos.
JcaPEMWriter grava chaves privadas EC como SEC1 -----BEGIN EC PRIVATE KEY-----, que o PEMParser lê de volta como um PEMKeyPair; ferramentas que esperam PKCS#8 precisam que a chave seja convertida antes. O conversor DER ⇄ bruto ajuda quando uma assinatura PLAIN e uma DER são confundidas.