Resumo

  • A RFC 3385 mostrou que “soma de 32 bits” não descrevia a proteção inteira: polinômio, tamanho do bloco, distribuição do erro e viés dos dados alteravam a chance de falha silenciosa.
  • O CRC32C foi considerado uma boa base para iSCSI sob hipóteses declaradas de corrupção acidental, nunca uma garantia criptográfica ou universal.

Uma rajada compacta atravessa uma soma aditiva e é capturada por um CRC, embora os dois resultados ocupem os mesmos quatro bytes. A largura visível mede redundância; não descreve quais padrões cada código separa. A RFC 3385 tornou essa diferença uma decisão de engenharia verificável.

Publicada em setembro de 2002 como Informational, ela estimava erros não detectados para orientar iSCSI. Não era o protocolo completo, certificação de produto nem relato de adoção. Seus números pertenciam a modelos explícitos, não a todas as redes.

iSCSI levava comandos SCSI e dados de armazenamento sobre IP. Corrupção silenciosa podia chegar ao disco como conteúdo aparentemente válido. O volume agravava a exposição: o texto pensava em petabytes e exigia bom comportamento ao menos até blocos de 8 KiB.

A RFC 3347 explicara por que o checksum TCP não encerrava a questão. Alguns erros podiam escapar. Um proxy podia terminar TCP, reconstruir cabeçalhos iSCSI e recalcular o checksum. Dados, comandos e estado precisavam de uma fronteira de digest do próprio iSCSI.

A análise separou erros em rajada e erros independentes. Memória, interconexão interna ou software também podiam gerar corrupção agrupada. Não bastava saber quantos bits mudaram: distribuição, duração e comprimento do bloco definiam o risco.

Um CRC calcula redundância com um polinômio gerador. Uma palavra errada passa apenas quando o padrão de erro também tem estrutura de palavra do código. Distância mínima e distribuição de pesos delimitam o invisível. Trinta e dois bits dizem quantidade, não geometria.

Em códigos encurtados, polinômios do mesmo grau podiam divergir muito em comprimentos práticos. Os estudos citados encontraram diferenças de ordens de grandeza entre polinômios de 32 bits para certas rajadas. Classificar por largura apagaria justamente a diferença relevante.

O CRC IEEE 802 e CRC32C tinham a mesma largura, mas CRC32C usava 0x11EDC6F41. O gerador mudava quais erros eram divisíveis e, portanto, distância e não detecção em cada faixa.

As estimativas assumiam taxa de rajada, taxa independente, distribuição de duração e bloco de 8 KiB. Uma rajada de tempo fixo atinge mais bits em links rápidos. Trocar canal, carga, tamanho ou distribuição muda a afirmação. Um número diminuto sem premissas não é evidência íntegra.

Fletcher e Adler mostraram outra diferença. Nas condições analisadas, o CRC foi estimado cerca de 12 mil vezes melhor que Fletcher e 22 mil que Adler para erros independentes. Padrões curtos podiam se cancelar em somas aditivas, e dados reais enviesados pioravam seus pontos cegos.

Fletcher32, Adler32, CRC IEEE-802 e CRC32C apareciam juntos na tabela final: 32 bits, mas distâncias e probabilidades distintas. Os autores escolheram CRC32C pela proteção, menor sensibilidade ao viés e capacidade em blocos longos.

O custo também foi medido. Na síntese citada, CRC32C usava mais células que CCITT-CRC32, mas ainda menos de um por cento de um chip pequeno representativo. A decisão não dizia que o custo era zero; mostrava sua proporção diante do ganho.

Interoperabilidade exigia ainda ordem dos bits, inicialização, complemento, padding e mapeamento do resto. O texto mostrou hardware serial e paralelo, enquanto software podia usar tabelas. Nomear o mesmo polinômio sem repetir o procedimento não garantia o mesmo valor.

A linearidade permitia atualizar CRC quando um intermediário alterava cabeçalho, sem reler todo o bloco. O destino final podia verificar a composição e incluir mudanças acidentais do caminho. Era eficiência e cobertura, não autenticação do intermediário.

A RFC 7143 consolidou depois iSCSI. HeaderDigest e DataDigest têm None como padrão, mas iniciadores e alvos implementam CRC32C e None. Uma vez negociado, o digest cobre os PDU da fase completa. A própria norma o chama de não criptográfico.

Implementar, oferecer, selecionar, cobrir, validar e manter proteção depois de iSCSI são fatos diferentes. Compatibilidade não prova ativação em toda sessão.

O limite de segurança era direto: quem altera os dados pode recalcular o código. CRC detecta acidente, não autentica origem nem autorização. Passar na verificação não prova resistência a ataque.

RFC 3309, RFC 4960 e RFC 9260 reutilizaram CRC32C em SCTP. Isso mostra adoção do código, não equivalência de modelos. Comprimentos, campos, camadas e recuperação mudam a evidência.

RFC 1071 tratou o checksum Internet; RFC 1141 e RFC 1624, atualização incremental, com correção posterior. RFC 2151 apresentou Fletcher para UDP e RFC 1950, Adler-32 para zlib. “Checksum” é uma família, não um nível único.

O memorando também avisou que links mais rápidos fazem uma rajada temporal ocupar mais bits. CRC superior não mantém sozinho o risco constante. Codificação e taxa de erro das camadas inferiores continuam no controle.

A especificação inicial mínima de Lu Heng ajuda a localizar a decisão: protocolo fixa polinômio, representação e cobertura; implementações otimizam depois. Liberdade só começa quando “verificado” significa a mesma coisa.

Pelas camadas de realidade, campo presente, algoritmo suportado, digest negociado, PDU coberto, valor aprovado, corrupção acidental excluída e integridade adversarial são fatos distintos. “Tem checksum de 32 bits” comprime sete camadas e quase nada demonstra.

A contribuição histórica da RFC 3385 foi transformar slogan em evidência delimitada. Bits eram o invólucro; polinômio, bloco, carga, caminho e ameaça davam significado ao invólucro.

Fontes