
Segredo de Shamir Criptologicamente Encantado.

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).
Ecossistemas existentes abordam partes deste problema, mas deixam lacunas:
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.
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).
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.