Capítulo 8 — Revisão independente e defesa
Mapa da aula
Aula 08 publicada. Mapa, exemplo, EX044.
flowchart TD
N0["8.1 Pacote de reprodutibilidade"]
N1["8.2 Perguntas dos examinadores"]
N2["8.3 Divulgação"]
N3["8.4 Informe aos operadores"]
N4["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX044"]
Desenho lógico
flowchart LR
N0["8.1 Pacote de reprodutibilidade"]
N1["8.2 Perguntas dos examinadores"]
N2["8.3 Divulgação"]
N3["8.4 Informe aos operadores"]
N4["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX044"]
[8.1 Pacote de reprodutibilidade]
|
v
[8.2 Perguntas dos examinadores]
|
v
[8.3 Divulgação]
|
v
[8.4 Informe aos operadores]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX044]
Objetivos de aprendizagem e conexão
Você vai (1) preparar um pacote de reprodutibilidade que um revisor independente consiga executar; (2) antecipar as perguntas dos examinadores; (3) tratar com responsabilidade a divulgação de um defeito de produto; e (4) apresentar os achados aos operadores. O capítulo fecha o ciclo da dissertação e leva ao apêndice de resoluções.
8.1 Pacote de reprodutibilidade
Inclua o conjunto de dados minimizado (ou um substituto sintético, se a universidade não puder liberá-lo), os scripts congelados com hashes, o livro de códigos e as planilhas de codificação, a configuração da bancada (sem firmware confidencial do fornecedor) e um README explicando como regenerar cada tabela. Peça a um colega que o execute a frio e registre cada ponto em que travou.
Teste o pacote numa máquina limpa, tendo apenas o README como guia da execução. Registre as versões do Python e de cada script e anote quanto tempo leva a execução completa, para que o revisor possa planejar o tempo.
8.2 Perguntas dos examinadores
- Por que confiar na aleatorização pelo identificador do dispositivo? Mostre as tabelas de balanceamento do uso dos caminhos e da versão do navegador.
- O navegador poderia recorrer a um hello só clássico após a falha e esconder o efeito? Sim; o desfecho por série conta uma série como falha somente se nenhuma tentativa teve sucesso, e uma análise secundária relata as falhas na primeira tentativa.
- O efeito tem a ver com a criptografia pós-quântica? Só indiretamente: o gatilho é o tamanho da mensagem, que o ML-KEM aumenta; qualquer ClientHello grande faria o mesmo, como mostra a condição só com preenchimento.
- O que mudaria a sua recomendação? Evidências de falhas disparadas pelo codepoint em outros lugares, ou uma correção do fornecedor que falhe em produção.
8.3 Divulgação
O defeito do proxy foi encontrado numa bancada isolada. Antes da publicação, relate-o ao fornecedor com os detalhes de reprodução (tamanhos de preenchimento, limites de segmento, versão do firmware), dê um prazo razoável e informe a equipe de rede da Larkspur. Publique a classe do defeito — tratamento incorreto de ClientHello em vários segmentos — e não passos para escapar da inspeção do proxy.
Registre a data de cada etapa da divulgação, do primeiro contato com o fornecedor até a publicação. Se o fornecedor confirmar a correção nas notas de versão, cite-as na dissertação. A equipe de rede da Larkspur deve saber do defeito antes de qualquer apresentação pública dos resultados.
8.4 Informe aos operadores
Para as operações de rede da Larkspur (sintético): "Ativar a troca de chaves resistente à computação quântica fez falhar algumas conexões que passam pelo proxy de inspeção antigo, porque a primeira mensagem ficou grande demais para um único pacote e o proxy a tratou de forma incorreta. Uma atualização de firmware resolve isso no nosso laboratório. Mantenham a proteção ligada; atualizem o proxy; acompanhem o painel de falhas da ala do hospital."
Teste o informe com um operador que não viu o estudo. Se ele não souber dizer o que fazer na segunda-feira, simplifique. Deixe o detalhe técnico num apêndice para os engenheiros que perguntarem.
8.5 Erros comuns e limites
- Pacotes que não rodam sem o autor.
- Responder "a culpa é da PQC?" com sim ou não, em vez de com o mecanismo.
- Publicar um defeito antes de o fornecedor e o dono serem informados.
Cada erro tem uma salvaguarda: um pacote testado a frio por um colega, uma resposta à pergunta sobre a PQC que explique o tamanho da mensagem e o resultado da condição só com preenchimento, e um cronograma de divulgação combinado com o fornecedor e com a equipe de rede da Larkspur antes da publicação. Confira cada um antes da data da defesa. Ensaie as respostas em voz alta uma vez.
Exercícios — capítulo 8
- EX044 — README do pacote. Escreva o README do pacote de reprodutibilidade. Rubrica: 3 = um estranho conseguiria regenerar a Tabela 1.
- EX045 — Execução a frio. Liste cinco prováveis pontos de tropeço para um colega que execute o pacote. Rubrica: 3 = específicos.
- EX046 — Tabela de balanceamento. Descreva a tabela de balanceamento que responde à pergunta sobre a aleatorização. Rubrica: 3 = variáveis relevantes para os rivais.
- EX047 — Pergunta do fallback. Responda à pergunta do fallback em 120 palavras. Rubrica: 3 = distingue desfecho por série e desfecho da primeira tentativa.
- EX048 — E-mail de divulgação. Redija a divulgação ao fornecedor (sem passos de exploração). Rubrica: 3 = reprodutível, delimitada, prazo declarado.
- EX049 — Informe ao operador. Reescreva o 8.4 para a direção executiva da universidade. Rubrica: 3 = focado na decisão, sem jargão.
- EX050 — Reflexão sobre a defesa. Nomeie a parte mais fraca do Fragment Study e como um estudo futuro a corrigiria. Rubrica: 3 = honesta e acionável.
Síntese do capítulo
Uma defesa tem sucesso quando um estranho consegue refazer o trabalho, as perguntas difíceis são respondidas com mecanismos e não com slogans, os defeitos são divulgados antes da publicação e os operadores recebem uma decisão clara.
Continue estudando — capítulo 08 de 08
← Capítulo 07 · Índice de capítulos do curso · Resoluções →
Siga para a próxima lição escrita.
Resoluções
Respostas-modelo para autoavaliação; qualquer resposta que atenda à rubrica recebe a mesma pontuação. Os números sintéticos vêm dos laboratórios.
EX001. Intervenção: grupo híbrido ativado; desfecho: as sessões de Wi-Fi falham; população: usuários da biblioteca; causa implícita: a PQC. Rival: uma mudança no portal cativo ou no firmware dos pontos de acesso na mesma semana.
EX002. Descritiva: as falhas de conexão de VPN mudaram após a ativação da troca de chaves híbrida no IKEv2? Comparativa: mudaram mais para usuários remotos do que para os do campus? Explicativa: quanto da mudança se deve ao tratamento da fragmentação do IKE, e em quais gateways?
EX003. Compartilhamento do cliente 97 + 1.568 = 1.665 bytes; compartilhamento do servidor 97 + 1.568 = 1.665 bytes (o texto cifrado do ML-KEM-1024 também tem 1.568 bytes; FIPS 203; RFC 10024).
EX004. Uma boa resposta argumenta cada elemento do FINER e admite uma fraqueza, por exemplo, que a viabilidade depende do acesso aos logs.
EX005. Três bases (RFC Editor, IACR ePrint, ACM DL), expressões exatas, datas e número de resultados.
EX006. Por exemplo, RFC 9794 (terminologia; norma; sem dados de implantação) e SP 800-227 (uso de KEMs; norma; não específica do TLS).
EX007. "Nenhum estudo publicado atribui as falhas de handshake pós-híbrido dentro de uma organização ao tamanho da mensagem, em comparação com causas concorrentes, usando um controle concorrente."
EX008. As trocas de chaves gravadas podem ser decifradas quando existir um CRQC, então a confidencialidade do tráfego de hoje depende da troca de chaves de hoje; assinaturas forjadas depois não alteram sessões passadas. As assinaturas são urgentes para raízes de confiança de vida longa e para firmware que precisa ser verificável por décadas.
EX009. ML-KEM-512 (categoria 1; chave de 800 B, texto cifrado de 768 B), -768 (categoria 3; 1.184 / 1.088), -1024 (categoria 5; 1.568 / 1.568). Segredo compartilhado de 32 B.
EX010. Os dois segredos entram no escalonamento de chaves do TLS; recuperar a chave de sessão exige as duas entradas, supondo que a KDF (HKDF) se comporte como um bom extrator, de modo que quebrar só um componente não rende nada útil.
EX011. Para chaves estáticas de vida longa com transferências pouco frequentes, o pressuposto conservador baseado em códigos do Classic McEliece e os seus textos cifrados pequenos podem justificar a chave pública grande; como alternativa, ML-KEM com o HQC como reserva posterior. A resposta deve pesar o tamanho da chave contra a diversidade de pressupostos.
EX012. Os 240% não têm taxa de base; as semanas diferem e há uma atualização do navegador no meio; as novas tentativas inflam as tentativas; não há estratificação por caminho.
EX013. 4,5 × 3,4 = 15,3 por 10.000 — um aumento absoluto de cerca de 10,8 por 10.000 séries, pequeno no agregado, mas concentrado por caminho.
EX014. Antes/depois: barato, confundido. Quase-experimento: controle concorrente, exige implantação escalonada. Bancada: isola o mecanismo, não mede a prevalência. A combinação dos dois últimos cobre as ameaças de um e de outro.
EX015. As novas tentativas acrescentam tentativas; se as falhas disparam novas tentativas, numerador e denominador sobem e as taxas por tentativa podem enganar em qualquer direção; a unidade por série elimina essa dependência.
EX016. Hash com chave dos endereços dos clientes, com rotação mensal; categorias de destino mais hash com sal; nenhum conteúdo; armazenamento nas instalações da universidade; retenção limitada; acesso nominal; aprovação do comitê de ética.
EX017. 9/20.000 → 4,5 por 10.000, IC 95% de Wilson de cerca de 2,4–8,6 por 10.000.
EX018. Base 300: todos cabem ou não como antes (x25519 556→336 B, um segmento). Base 1.300: o hello só com x25519 tem ~1.336 B, ainda um segmento; ele só precisa de dois quando a base passa de cerca de 1.424 B. Os tamanhos reais dependem das extensões, então meça.
EX019. Versão e hash do código; dicionário de dados; conjunto de dados minimizado e soma de verificação; política do navegador e data; regra de atribuição das coortes; definição de série; livro de códigos; configuração da bancada.
EX020. Tamanho → só o caminho do proxy, dependente do limite de segmento; atualização → os dois caminhos; codepoint → falhas com hello de um segmento; sazonalidade → o controle também sobe; relato → os chamados sobem sem que as falhas registradas subam.
EX021. Por exemplo, uma mudança no resolvedor de DNS que faz o tráfego do hospital passar pelo proxy com mais frequência → a composição dos caminhos muda; verifique a participação de cada caminho ao longo do tempo.
EX022. Caminho de visitantes 3,0→3,5 por 10.000 (+0,5): nenhuma mudança relevante, compatível com o mecanismo de tamanho ser específico do proxy.
EX023. Antes: estrato A (proxy) 10/1.000 e estrato B (direto) 1/1.000 séries, agregado 11/2.000 = 5,5 por 1.000. Depois: A 3/100 (30 por 1.000) e B 4/1.900 (cerca de 2,1 por 1.000), agregado 7/2.000 = 3,5 por 1.000. Os dois estratos sobem, mas o agregado cai porque o tráfego do período híbrido se deslocou para o estrato de poucas falhas.
EX024. Um 2×2 na bancada isolada: {um, dois segmentos} × {codepoint presente, ausente}, usando o preenchimento para controlar o tamanho.
EX025. "Proporção de primeiras tentativas com falha para um host seguidas, em até 10 s, por uma tentativa bem-sucedida do mesmo cliente sem o compartilhamento híbrido."
EX026. Como a H1–H3 em 5.2, cada uma com um limiar numérico.
EX027. Ela varia tamanho e codepoint de forma independente; falhas com um hello de um segmento carregando o codepoint rejeitariam a H2 em favor do rival 3.
EX028. Por exemplo, capturas de pacotes da bancada confirmam a segmentação em ≥ 95% das tentativas com preenchimento; o pipeline processa um dia de logs em menos de uma hora.
EX029. Causa (ambiguidade do livro de códigos entre size e timeout), emenda (regra de decisão: RST do proxy após o primeiro segmento = size), novo teste em 40 logs novos, seguir adiante se κ ≥ 0,75.
EX030. Acesso aos dados retirado; atraso do comitê de ética; fornecedor recusa a licença para a bancada; mudança no cronograma de implantação; indisponibilidade de um codificador — cada um com mitigação.
EX031. Meses 1–4 busca e proposta; 5–6 ética e piloto; 7–12 coleta; 13–16 análise; 17–18 validação no Fenwick; 19–22 redação; 23–24 revisão e defesa.
EX032. Arquivo do script, SHA-256, testemunha (orientador), data, local do registro.
EX033. O κ cai para 0,808 (concordância observada 0,867); a confusão entre size e timeout é a que mais importa, porque afeta o mecanismo.
EX034. (26,0 − 5,0) − (5,7 − 5,1) = 21,0 − 0,6 = 20,4 por 10.000.
EX035. Falhas com dois segmentos independentemente do codepoint, e nenhuma com um segmento mais o codepoint, apoiam o tamanho e rejeitam o codepoint.
EX036. "O efeito foi observado num único modelo de proxy legado na Larkspur; o proxy de outro fornecedor no Fenwick não mostrou efeito."
EX037. Crescimento do tráfego da ala do hospital no início do semestre; mudanças nas regras do proxy; atualização do navegador em momentos diferentes nas duas coortes.
EX038. Frase de estimativa, frase de incerteza, frase de interpretação — separadas.
EX039. Exclusão dos dispositivos não gerenciados (direção desconhecida); janela curta (provavelmente subestima as falhas com destinos raros).
EX040. Pedir ao fornecedor suporte ao novo codepoint, desviar temporariamente a inspeção do TLS 1.3 para destinos conhecidos e manter o grupo híbrido nos caminhos não afetados.
EX041. O resumo deveria declarar que os dados são sintéticos (neste livro) e que o efeito diz respeito a um único modelo de proxy; "a reversão é desnecessária" vale apenas para a Larkspur.
EX042. Uma abertura que formule a pergunta em cada capítulo.
EX043. "No Fenwick, o excesso no caminho do proxy foi de +1,2 por 10.000 (IC 95% −0,8 a 3,2): nenhum efeito relevante, o que indica que o defeito da Larkspur é específico do produto."
EX044. Passos, ambiente, soma de verificação dos dados, um comando por tabela.
EX045. Dependências ausentes, chaves de hash não explicadas, rótulos de caminho, licença da bancada, intervalos de datas não documentados.
EX046. Participação por coorte de caminho, versão do navegador, tipo de dispositivo, prédio do campus.
EX047. Um fallback do navegador poderia fazer uma série ter sucesso após uma falha; o desfecho primário conta as falhas de série, e uma análise secundária relata as falhas na primeira tentativa para expor o fallback oculto.
EX048. Produto, versão do firmware, comportamento observado, método da bancada, prazo de 90 dias, contato; nenhum passo de evasão.
EX049. Decisão: aprovar a atualização do proxy; manter a proteção ligada; resultado esperado e monitoramento.
EX050. Por exemplo, só navegadores gerenciados foram observados — um estudo futuro acrescenta amostragem da rede de visitantes, com consentimento e minimização.