CESS — Segredo de Shamir Criptologicamente Encantado

Isso é besteira ou lixo de IA?

Um criptógrafo ou implementador sério revisando o CESS normalmente abrirá vectors/ e testdata/ antes de ler a prosa. A suíte de testes é a prova de trabalho: ela codifica conhecimento de domínio que não pode ser substituído apenas por narrativa.

Isso não é motivo para esconder o ponto de todos os outros. Pessoas avaliando o projeto para aquisição, decidindo se contribuem, escrevendo políticas ou enviando código sem treinamento aprofundado em metodologia de teste criptográfico ainda merecem um indicador para as evidências concretas. O repositório já declara regras de auditoria e exclusões de algoritmos; vincular essa história a vetores de teste publicados fecha a lacuna entre “afirmações na página” e “artefatos que você pode executar”.

O que olhar: O material de conformidade inclui exemplos trabalhados da RFC 8439 para ChaCha20-Poly1305 (a AEAD da IETF que este projeto referencia normativamente) e JSON do Wycheproof copiado para casos de borda do ChaCha20-Poly1305 em testdata/wycheproof/. Juntamente com os próprios vetores TOML do projeto em vectors/, eles são a verdade fundamental que o executor e os revisores podem exercitar.

RFC 8439 é publicada pela Internet Engineering Task Force (IETF), a organização que padroniza grande parte de como a internet opera. RFCs (Request for Comments) são a forma usual para muitos protocolos e especificações criptográficas. RFC 8439 define a criptografia autenticada ChaCha20-Poly1305 (baseada nos projetos de Daniel Bernstein) e inclui exemplos trabalhados concretos com entradas e saídas esperadas, para que implementações independentes possam verificar se correspondem ao padrão byte a byte. O texto simples amplamente reproduzido começando com Ladies and Gentlemen of the class of '99: wear sunscreen aparece nos exemplos do apêndice da RFC: se seu código reproduz exatamente a saída AEAD, você tem uma verificação forte de que implementou a construção corretamente. É o análogo criptográfico de um gabarito oficial. (A RFC 7539 anterior documentou ChaCha20 e Poly1305 para outros contextos da IETF; RFC 8439 é a referência usual para esta AEAD conforme usada aqui e em spec/CESS-v0.2.md.)

Wycheproof é um corpus de teste lançado pela equipe de segurança do Google (2017). O nome refere-se ao Monte Wycheproof na Austrália — frequentemente citado como a menor montanha do mundo — porque o projeto foca em superar obstáculos pequenos mas fatais: estouros de inteiros, casos de borda, entradas malformadas e tags de autenticação adulteradas; falhas que aparecem repetidamente em criptografia real implantada. Ele complementa vetores no estilo RFC: exemplos ao estilo RFC 8439 demonstram correção contra a AEAD publicada; Wycheproof testa robustez onde implementações historicamente quebram.

O que isso diz sobre este padrão fica a critério do leitor bem informado.

Também é possível verificar a integridade das crates com isso quando o PR for fechado: https://github.com/rust-lang/cargo/issues/16850

Versão: 0.2
Status: Somente especificação (texto normativo e vetores de teste)

Este projeto está registrado no Open Invention Network (OIN), um pool de patentes defensivo que protege software livre relacionado ao Linux. A combinação de publicação aberta de pré-impressão (estabelecendo estado da técnica), participação no OIN e licenciamento GPL-3.0 destina-se a garantir que esta tecnologia permaneça livremente disponível e não possa ser proprietarizada ou restringida por nenhum estado ou ator comercial.

CESS é um padrão criptográfico aberto para compartilhamento secreto por limiar combinado com criptografia autenticada independente de cifra, embrulhamento de compartilhamento baseado em senha e troca de chave híbrida pós-quântica opcional. É projetado para implantações que exigem confidencialidade de longo prazo, inscrição em ambiente desconectado, vinculação a tokens de hardware e caminhos de aquisição independentes de linhas de base de algoritmos exclusivas da NSA/NIST.

Leitores não técnicos podem começar com o glossário (termos em linguagem simples de A a Z).

Por que o CESS existe

Ecossistemas existentes abordam partes deste problema, mas deixam lacunas:

• GnuPG fornece criptografia e assinatura fortes, mas não um perfil normativo e interoperável para compartilhamentos Shamir mais AEAD moderna e fluxos de trabalho de custódia entre jurisdições.
• Autocrypt foca em criptografia oportunista de e-mail, não em divisão por limiar de segredos de longo prazo com compartilhamentos protegidos por PIN.
• SLIP-0039 padroniza codificação mnemônica de compartilhamentos Shamir para sementes; CESS complementa este espaço com um envelope de compartilhamento binário, negociação explícita de cifra, perfis Brainpool ECDH, tratamento de PIN baseado em Argon2id e combinadores híbridos CESS-PQ.

CESS define o padrão; SplitDisk (e produtos similares) são cenários de referência e implantações de exemplo, não o padrão em si.

Design independente de cifra

CESS fixa Compartilhamento Secreto de Shamir sobre GF(2^8) e várias primitivas de integridade e senha não opcionais auditadas. Todas as camadas de criptografia em massa, KEM, KDF e MAC são selecionáveis a partir de um registro auditado, sujeitas à regra de dois auditores independentes e à lista de exclusão rígida (veja spec/CESS-v0.2.md e ALGORITHM-REGISTRY.md).

Requisito de auditoria e exclusões (resumo)

• Cada primitiva na camada independente de cifra DEVE ter duas ou mais avaliações independentes da lista qualificada de auditores (NESSIE, CRYPTREC, ECRYPT/eSTREAM, revisão por pares da IACR, BSI, NCC Group, Cure53, Kudelski Security, JP Aumasson, comitê PHC).
• Participação da NSA no design, revisão exclusiva NIST/FIPS e vários algoritmos (AES, SHA-2, SHA-3, curvas NIST, ML-Kyber, Dual_EC_DRBG, RC4, DES, 3DES, HMAC-SHA-*) são excluídos com justificativa explícita na especificação.
• X25519 / Ed25519 são opcionalmente permitidos com justificativa documentada (projetos de Bernstein; extensas auditorias independentes).

Por que as curvas primas NIST (P-256, P-384, P-521) são omitidas

As curvas de corpo primo NIST amplamente usadas no governo e indústria dos EUA (P-256, P-384, P-521) foram escolhidas por meio de um processo no qual a NSA desempenhou um papel documentado. CESS não se baseia em uma única prova matemática de que essas curvas são fracas; aplica uma exclusão de política para que o padrão possa servir a caminhos de aquisição, ligação e engenharia que exigem criptografia justificada fora de uma linha de base exclusiva NSA/NIST e que favorecem primitivas revisadas independentemente (veja spec/CESS-v0.2.md Seção 3 e ALGORITHM-REGISTRY.md).

ECDH clássico no CESS usa curvas Brainpool (RFC 5639) em vez disso. Seus parâmetros são produzidos por regras de geração publicadas e são um ajuste natural para discussões alinhadas ao BSI e centradas na UE, ao mesmo tempo que cobrem alvos de segurança comparáveis (por exemplo, BrainpoolP384r1 vs segurança classe P-384) sem adotar a família de curvas NIST excluída.

Detalhes: spec/CESS-v0.2.md Seção 3, spec/CRYPTO.md e ALGORITHM-REGISTRY.md.

Estrutura do repositório

Licenciamento

Patentes e OIN

Os contribuidores concordam com o compromisso de não alegação de patentes em PATENTS.md. O projeto está registrado no Open Invention Network (OIN), um pool de patentes defensivo para software livre relacionado ao Linux. O licenciamento cruzado por meio do OIN não cobre, por si só, partes fora desse ecossistema; o compromisso destina-se a fechar essa lacuna para implementações conformes.

Públicos-alvo

• Criptógrafos e engenheiros de protocolo
• Agências governamentais e contratantes de defesa (especialmente aquisição centrada na UE)
• Fornecedores de tokens de segurança de hardware e cartões inteligentes (perfil CCID)
• Desenvolvedores de código aberto que constroem ferramentas de custódia por limiar e recuperação de desastres

Como contribuir

Veja CONTRIBUTING.md. Pull requests são tratados como concordância com PATENTS.md. Alterações na especificação exigem dois revisores em países diferentes. Novos algoritmos usam ALGORITHM-REGISTRY.md (abra um PR contra o registro e depois contra spec/CESS-v0.2.md referências cruzadas, se necessário).

Adicionando uma cifra ao registro

1. Confirme duas auditorias qualificadas e ausência de exclusões rígidas.
2. Abra um PR editando ALGORITHM-REGISTRY.md (tabela de evidências, alocação de identificador).
3. Adicione ou estenda vetores de teste em vectors/ cobrindo o novo conjunto.
4. Obtenha duas revisões de mantenedores conforme CONTRIBUTING.md.

Índice de documentos

• Glossário (não técnico A–Z)
• Padrão principal
• CRYPTO (justificativa)
• GOVERNMENT (implantação)
• Registro de algoritmos
• Conformidade
• Executor de conformidade / KATs de cascata interna
• Guia de vetores
• Executor de teste
• Patentes

Relação com SplitDisk

CESS é o padrão. SplitDisk é um cenário de implementação de exemplo (ex.: criptografia de disco mais distribuição de compartilhamentos); a especificação da ferramenta reside nesse repositório. Produtos podem reivindicar conformidade CESS-CORE, CESS-FULL ou CESS-PQ conforme CONFORMANCE.md sem usar o nome SplitDisk.