Skip to content
KitploitKITPLOIT
FerramentasExploitsBlog
Log in
Enviar
FerramentasExploitsBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
CESS — Segredo de Shamir Criptologicamente Encantado. | Kitploit
Ferramentas/GitHubGitHub/supermagnum/cess
Ferramentas de Criptografia/DescriptografiaCriptografiaSegurança de HardwareAutenticação
GitHubsupermagnum/cess

CESS

Segredo de Shamir Criptologicamente Encantado.

Ver Repositório
257há 8 diasAinda não revisado

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

Open Invention Network member

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.

Baixar ferramenta