O BoringSSL é o fork do OpenSSL mantido pelo Google e usado no Chrome e no Android; o AWS-LC, a biblioteca por baixo do aws-lc-rs, é por sua vez um fork dele, e o ring reaproveita seu código assembly. Ele não tem versões publicadas e não promete estabilidade da API — quem o usa fixa um commit. Os fatos desta página foram verificados compilando a partir do código-fonte o commit b50cad27ee80 (19 de outubro de 2026).
O ECDSA mantém as convenções do OpenSSL: assinaturas DER, nonces aleatórios, nenhuma normalização low-S e uma verificação que aceita high-S; ECDSA_sign assina um digest calculado por você. Ao contrário do OpenSSL, uma entrada malformada é apenas uma verificação que falhou — EVP_DigestVerify retornou 0 para uma assinatura r‖s bruta e para um blob de 3 bytes, então a fila de erros é o único lugar em que um problema de formato aparece. Confira as codificações com o conversor DER ⇄ bruto.
As curvas são limitadas de propósito a P-224, P-256, P-384 e P-521 — EC_GROUP_new_by_curve_name(NID_secp256k1) retornou NULL —, e o Ed25519 é a única variante de EdDSA que funciona: EVP_PKEY_ED448 está definido por compatibilidade, mas a geração de uma chave Ed448 pela EVP falhou. Código que migra do OpenSSL para o BoringSSL perde secp256k1, Brainpool e Ed448 sem nenhum erro de compilação, até que o algoritmo seja solicitado.
O suporte pós-quântico é amplo e vem em APIs separadas e tipadas, e não pela EVP: MLKEM768_* e MLKEM1024_*, MLDSA65_* e os tamanhos relacionados, e SLHDSA_SHA2_128S_*, todas com o ciclo completo de ida e volta funcionando no teste; o ssl.h também define o grupo TLS híbrido X25519MLKEM768 (0x11EC). O exemplo usa ML-KEM-768 e ML-DSA-65 diretamente. Veja o que seu navegador negocia com a verificação pós-quântica do navegador.