Hubo un gran revuelo (y mucha discusión) con la inclusión del cifrado Speck en el kernel de Linux hace algunos meses y durante este tiempo ha dado mucho de que hablar durante este tiempo.
La razón detrás de esta hostilidad es el origen del algoritmo: Speck fue de hecho creado por la NSA, un hecho que genera más que unos pocos sospechosos en los insiders.
La agencia del gobierno de Estados Unidos no ha hecho una buena reputación que a inserción de puertas traseras y el respeto de la vida privada.
Pero más allá de eso ni siquiera tiene que dar razones válidas para muchas de las opciones de implementación de algoritmos.
La polémica
De hecho, la NSA se ha negado a dar explicaciones sobre por qué se eligió un cierto número de rondas, por ejemplo, cuando se solicitó una comparación a los criptólogos.
La NSA incluso se había dirigido al creador de Linux, Linus Torvalds, para crear una puerta trasera en el Kernel de Linux. Una oferta a la que Linus Torvalds se negó de inmediato.
La renuencia de la NSA para proporcionar más detalles sobre el algoritmo a continuación ha alimentado las sospechas de que algunas decisiones han sido hechas conscientemente.
Con la intención de ocultar puerta trasera que permitiría a la agencia para penetrar las defensas no alteradas de los sistemas criptográficos.
El algoritmo en cuestión, Speck, es un ‘cifrado débil (cifrado de bloques liviano) diseñado para dispositivos con bajos poderes informáticos, es decir, Dispositivos IoT.
La NSA quería que Speck y su algoritmo compañero Simon se convertirá en un estándar global para la próxima generación de gizmos y sensores de Internet-de-cosas.
La NSA intentó impulsar agresivamente este algoritmo hasta el punto de que algunos criptógrafos alegaron hostigamiento y acoso a manos de la NSA.
El problema con el algoritmo es que la Organización Internacional de Estándares (ISO) rechazó a Speck y Simon.
Speck se incluyó en el Kernel de Linux 4.17 entre los algoritmos compatibles y Linux 4.18 había visto su llegada entre los algoritmos utilizados en el cifrado de sistemas de archivos (a través de fscrypt).
La razón detrás de la inclusión, a pesar de las preocupaciones, estaba en la parte de la solicitud de Google para incluir el algoritmo para utilizarlo en algunos dispositivos con Android de gama baja, para los que otros algoritmos de cifrado no garantizan un nivel suficiente de seguridad.
El problema persiste, pero…
Esta solicitud, sin embargo, llegó a caer una vez que la NSA no proporcionó explicaciones suficientes para diseñar opciones.
Tanto es así que Google creó el nuevo algoritmo HPolyC específicamente para dispositivos con potencia de cálculo baja.
Aunque también a principios del mes pasado Google revirtió sus planes para usar Speck como un medio de encriptación de sistema de archivos barato para dispositivos Android Go de gama baja.
En su lugar está desarrollando HPolyC como un nuevo enfoque y más seguro. Los desarrolladores de Google dijeron que no se opondrían al código Speck del kernel de Linux.
Hubo entonces un RFC para eliminar el código Speck del kernel de Linux, pero hasta la fecha no se ha actuado.
Con las actualizaciones actuales del código criptográfico para Linux 4.19 no hay cambios en el código Speck.
Además, desde Linux 4.18 y en 4.19 Git hasta el momento, el soporte de fscrypt basado en Speck permanece así que mientras más tiempo haya en el núcleo.
Mayor será la probabilidad de que Speck se mantenga en la línea principal para no romper el soporte existente para cualquiera que ya haya probado este método de encriptación del sistema de archivos.
Por lo tanto, no hay otros patrocinadores importantes para Speck que puedan justificar su inclusión en el kernel: por esta razón se decidió eliminar por completo el cifrado.
Los parches ahora están listos para su eliminación, que se completará con Linux 4.20 / 5.0, pero es posible que Speck se elimine incluso antes de que los parches estén listos como puertos de respaldo para los kernels actuales.