AES-256 fronte a OFB: escolla unha construción de cifrado VPN completa
Un cifrado de bloque, un tamaño de chave e un modo son decisións distintas. Avalíe confidencialidade e integridade xuntas e despois siga a política de canle admitida.
AES-256 e OFB responden a preguntas distintas, e aquí é onde fallan as revisións de cifrado cando se tratan como opcións competidoras. Un nomea un cifrado de bloque cun tamaño de chave; o outro describe como un cifrado de bloque se converte nun fluxo para unha mensaxe máis longa. Un manual para escoller protección debe mirar a construción completa, incluído como o receptor detecta un paquete modificado.
Nomee as catro partes da construción
Cada revisión redúcese a catro preguntas: que primitiva e tamaño de chave, como se procesan as mensaxes con ela, como o receptor rexeita unha modificación non autorizada e como o protocolo xestiona as entradas, as chaves e a súa vida útil. Unha lista de nomes coñecidos só responde á primeira. A segunda e a terceira son onde viven as diferenzas reais, e a cuarta é onde as implementacións diverxen en silencio. Fágaas nesa orde e escriba as respostas.
OFB aparece entre os modos de confidencialidade na publicación de NIST sobre modos de cifrado de bloque, e a confidencialidade é todo o que ofrece. Un protocolo que emparexa un modo de cifrado cun MAC separado debe compoñelos correctamente, e o nome dun algoritmo non demostra esa composición. Por iso o nome do modo por si só non pode resolver unha decisión de despregamento.
A cuarta pregunta é a que un operador pode verificar realmente no sistema en marcha.
Preferir unha construción autenticada
O cifrado autenticado achega confidencialidade e integridade xuntas, e as construcións AEAD tamén protexen os datos asociados de modificacións sen cifralos. É unha propiedade da protección de paquetes e non ten relación con que unha persoa iniciase sesión correctamente.
A Guía de axustes criptográficos de OpenVPN de Netgate apunta a opcións AEAD, entre elas AES-GCM, para a canle de datos, e ese é o tipo de política admitida que cómpre seguir. Use as opcións que admiten a versión instalada e os clientes pares, en lugar de copiar unha clasificación histórica de modos nun despregamento novo. A compatibilidade herdada, os backends criptográficos e o soporte de offload limitan o que está realmente dispoñible.
Unha construción admitida vence a unha composición enxeñosa todas as veces.
Lea o resultado negociado, non a oferta
Un cifrado que aparece nunha lista aceptada non di nada sobre a sesión actual. Lea a protección negociada da canle de datos no cliente ou na pasarela e compárea coa política que quería aplicar. Unha configuración que aínda enumera unha opción herdada para un par antigo é unha decisión de compatibilidade, non unha afirmación sobre a sesión que ten diante.
openvpn --config client.conf --verb 4 2>&1 | grep -Ei 'cipher|data channel|auth'
Nunha pasarela a saída equivalente é a asociación de seguridade ou o detalle criptográfico da conexión, segundo a plataforma. En ambos os casos a oferta e o resultado son feitos distintos. Unha lista que inclúe unha opción herdada para un par antigo non significa que todas as sesións a usen, e a sesión que si a usa é o que necesitaba saber.
Rexistre ambos os feitos xuntos, coa data e a versión do cliente.
Mida só o que pode comparar
O rendemento depende do hardware dos extremos, a implementación, a aceleración, os tamaños de paquete e a configuración escollida. Nin a lonxitude da chave nin a palabra OFB lle din que despregamento será máis rápido. Por iso unha proba doutro sitio é como moito unha pista sobre o hardware que posúe outra persoa. Os seus propios números comezan polos seus propios extremos.
Para unha comparación autorizada, manteña constantes os extremos, a carga de traballo e a política requirida, e rexistre a protección negociada xunto coas versións de implementación. Despois xulgue o resultado por se a aplicación rematou, canto perdeu e que estaban facendo os extremos, en lugar de inferir o custo criptográfico dunha soa proba de velocidade. Un número producido noutras condicións é un relato, non unha medición.
Se un par antigo non pode cumprir a política, é unha decisión de compatibilidade do seu propietario.
Manteña a integridade fóra do trato
Desactivar as comprobacións de integridade ou aceptar un servidor non verificado non é unha optimización de rendemento nin unha solución de compatibilidade. Cambia a propiedade de seguridade para a que se escolleu a construción. O mesmo vale para ampliar a lista de cifrados aceptados ata que un par antigo se conecte: a conexión ten éxito e a política xa non existe.
Escriba a construción aceptada e o seu propietario no manual, para que o próximo cambio comece por unha decisión e non por unha preferencia.
O que quere é unha política que ambos os extremos poidan aplicar. Discutir que un nome é o máis forte é outra conversa, e adoita rematar sen decisión.