Modo FIPS

O sgcCrypto oferece uma opção facultativa em tempo de compilação, SGC_CRYPTO_FIPS, que deixa na biblioteca apenas algoritmos aprovados pelo FIPS. Ela é destinada a projetos que não podem usar algoritmos fora das publicações FIPS e NIST SP. Esta página explica o que a opção faz, como ativá-la, o que ela mantém, o que ela remove e o que ela não cobre.

O que FIPS significa aqui

A FIPS 140-3 é uma certificação de um módulo criptográfico, não de um algoritmo. Um laboratório acreditado testa um build específico de um produto no âmbito do Cryptographic Module Validation Program (CMVP) do NIST, e o NIST publica um certificado para esse build. Usar um algoritmo aprovado, como o AES, não torna um programa validado.

O sgcCrypto não é um módulo validado conforme a FIPS 140-3, e ativar a opção não é uma alegação de validação. O que a opção faz é mais restrito:

Ela remove todo algoritmo que não é aprovado pelo FIPS, de modo que nenhum deles pode ser compilado na sua aplicação.
Ela impõe algumas regras de parâmetros em tempo de execução, por exemplo um tamanho mínimo de chave RSA para assinatura.

Os algoritmos que permanecem seguem as publicações FIPS e NIST SP listadas na tabela abaixo.

Se o seu projeto tem um requisito formal de FIPS 140-3, a criptografia dele precisa passar por um módulo validado, por exemplo o Windows CNG com o sistema executando em modo FIPS. A opção ajuda a manter algoritmos não aprovados fora do seu código. Ela não substitui um módulo validado.

Ativando a opção

A opção vem desativada por padrão. Sem ela nada muda, e todo algoritmo listado na página Criptografia fica disponível. Para ativá-la, faça uma das seguintes ações:

Abra sgcVer.inc e altere {.$DEFINE SGC_CRYPTO_FIPS} para {$DEFINE SGC_CRYPTO_FIPS}.
Adicione SGC_CRYPTO_FIPS às definições condicionais do projeto ao compilar o código-fonte do sgcWebSockets.


  {.$DEFINE SGC_CRYPTO_FIPS}   { off, the default }
  {$DEFINE SGC_CRYPTO_FIPS}    { on }

Em seguida, recompile. A opção afeta apenas o código compilado com a definição, de modo que pacotes pré-compilados que foram gerados sem ela não são afetados.

Com a opção ativada, as funções removidas deixam de existir. Código que ainda chama alguma delas falha ao compilar com um erro "Undeclared identifier". Isso é intencional: nada que não seja aprovado pode acabar no binário por acidente, e o compilador aponta cada lugar que precisa de um algoritmo diferente.

O que permanece

Certificados, senhas de uso único e os auxiliares de codificação também permanecem, porque são construídos apenas a partir dos algoritmos aprovados ou nem sequer são algoritmos criptográficos.

Família	Mantido	Padrão
AES	AES-128/192/256 nos modos ECB, CBC, CFB, OFB, CTR, CTS, GCM e CCM, AES Key Wrap (KW e KWP), AES-CMAC e AES-GMAC	FIPS 197, SP 800-38A/B/C/D/F
Hashing	SHA-1 (apenas onde ainda é permitido, nunca para novas assinaturas), SHA-224, SHA-256, SHA-384, SHA-512, SHA3-224/256/384/512, SHAKE128, SHAKE256, cSHAKE e KMAC	FIPS 180-4, FIPS 202, SP 800-185
Autenticação de mensagens	HMAC-SHA1, HMAC-SHA256, HMAC-SHA384 e HMAC-SHA512	FIPS 198-1
Derivação de chaves	PBKDF2, HKDF e o ANSI X9.63 KDF	SP 800-132 (PBKDF2), SP 800-56C (HKDF), SP 800-135 (ANSI X9.63 KDF)
RSA	Geração de chave RSA, assinaturas PKCS#1 v1.5 e PSS, criptografia RSA-OAEP	FIPS 186-5, SP 800-56B
ECDSA e ECDH	Assinaturas e acordo de chave nas curvas NIST P-256, P-384 e P-521 (a P-224 não é implementada pelo sgcCrypto)	FIPS 186-5, SP 800-56A
EdDSA	Assinaturas Ed25519 e Ed448	FIPS 186-5
Criptografia pós-quântica	ML-KEM, ML-DSA e SLH-DSA	FIPS 203, FIPS 204, FIPS 205
Certificados & PKI	Parsing de certificados X.509, verificação de cadeia e de CRL, e geração de certificados ou de CSRs assinados com os algoritmos acima	RFC 5280, RFC 2986
Senhas de uso único	HOTP e TOTP, construídos sobre HMAC	RFC 4226, RFC 6238
Codificação & utilitários	Codificação Hex, Base32 e Base64, comparação em tempo constante, zero seguro	RFC 4648

O que é removido

Removido	Motivo
ChaCha20, XChaCha20, Salsa20, XSalsa20, Poly1305, ChaCha20-Poly1305 e XChaCha20-Poly1305	Não são algoritmos do NIST.
Troca de chaves X25519 e X448	Não são aprovados para acordo de chave na SP 800-56A.
O híbrido X25519 + ML-KEM-768, e o ECIES	Ambos são construídos sobre o X25519.
secp256k1 e as curvas Brainpool, e as assinaturas Schnorr BIP-340	Não são curvas recomendadas pelo NIST, e o BIP-340 não é um esquema de assinatura da FIPS 186-5. O modo FIPS mantém apenas as curvas NIST P.
Argon2 e scrypt	Não são funções do NIST para derivação de chaves a partir de senhas.
BLAKE2b, BLAKE2s, SipHash e TLSH	Não são algoritmos do NIST.
MD4, MD5, HMAC-MD5, RIPEMD-160 e DES (a unit sgcCrypto_Legacy)	Obsoletos, ou nunca aprovados pelo NIST.
KDF1 e KDF2	Definidos na ISO 18033-2, não em uma publicação do NIST. O ANSI X9.63 KDF permanece.
Criptografia RSA PKCS#1 v1.5	Não permitida pela SP 800-131A. As assinaturas PKCS#1 v1.5 permanecem.
WinZip AES (AE-1 e AE-2)	Não é um formato do NIST.

Para a maioria dos algoritmos removidos há um substituto aprovado na primeira tabela: AES-GCM em vez de ChaCha20-Poly1305, ECDH em P-256 ou P-384 em vez de X25519, PBKDF2 em vez de Argon2 ou scrypt, SHA-256 ou SHA-3 em vez de BLAKE2, e RSA-OAEP em vez da criptografia PKCS#1 v1.5.

Regras verificadas em tempo de execução

Algumas regras dependem dos valores passados a uma função, de modo que o compilador não consegue impô-las. Com a opção ativada, o sgcCrypto as verifica quando a função é executada, e cada uma gera uma exceção cuja mensagem começa com sgcCrypto FIPS:

Criar uma assinatura com SHA-1, com RSA ou ECDSA, incluindo a assinatura de um certificado ou de um CSR. Verificar uma assinatura SHA-1 existente continua permitido.
Assinar com uma chave RSA menor que 2048 bits.
A geração de chave RSA executa as verificações adicionais de chave da FIPS 186-5 e um teste de consistência do par (pairwise consistency test) no novo par de chaves.
Gerar uma chave EC a partir de uma semente exige uma semente pelo menos 64 bits maior que a ordem da curva, por exemplo pelo menos 320 bits para a P-256.
PBKDF2 com um salt menor que 16 bytes, ou com uma chave derivada menor que 14 bytes.
AES-GCM com um IV vazio.

De onde vêm os bytes aleatórios

Chaves, nonces e salts precisam de bytes aleatórios. A função sgcRandomBytes sempre os lê do sistema operacional, nos dois modos, e nunca executa um gerador próprio por cima. A opção muda apenas qual fonte do sistema é usada:

Plataforma	Com SGC_CRYPTO_FIPS	Sem SGC_CRYPTO_FIPS
Windows	BCryptGenRandom (CNG, RNG preferido do sistema), sem fallback	BCryptGenRandom, recorrendo ao RtlGenRandom e depois ao CryptGenRandom quando o BCryptGenRandom não está disponível
Linux e Android	A chamada de sistema getrandom	/dev/urandom
macOS e iOS	SecRandomCopyBytes do framework Security	/dev/urandom

Nos dois modos, se nenhuma fonte puder ser lida, uma exceção é gerada em vez de retornar bytes fracos. Se o gerador do sistema operacional conta como FIPS depende do sistema operacional e da sua configuração, não do sgcCrypto.

O que a opção não cobre

A opção se aplica apenas às units do sgcCrypto. Outras partes do sgcWebSockets ainda podem usar algoritmos não aprovados:

MD5 nas credenciais de longo prazo do TURN, na assinatura da API do Pusher e no antigo handshake WebSocket hixie-76.
MD4 e DES na autenticação NTLM.
Os conjuntos de cifras e a troca de chaves que o OpenSSL negocia para conexões TLS e QUIC, como ChaCha20-Poly1305 ou X25519. Eles são controlados pela sua configuração do OpenSSL, não por esta opção.
URLs assinadas do Amazon CloudFront, que exigem RSA com SHA-1 por design. Elas geram uma exceção quando a opção está ativada.

Se a aplicação inteira precisa se restringir a algoritmos aprovados, revise também essas áreas.

Veja também