Diseño Hardware de una familia de cifradores lightweight ASCON

TRABAJO DE FIN DE GRADO EN INGENIERIA ELECTRONICA INDUSTRIAL Diseño Hardware de una familia de cifradores lightweight ASCON Trabajo Fin de Grado presentado por David González Villalba, siendo el tutor de este el profesor Carlos Jesús Jiménez Fernández. En Sevilla a 2 de enero de 2024 UNIVERSIDAD DE SEVILLA ESCUELA POLITECNICA SUPERIOR Grado en Ingeniería Electrónica Industrial Escuela Politécnica Superior – Universidad de Sevilla GRADO EN INGENIERIA ELECTRONICA INDUSTRIAL ESCUELA POLITECNICA SUPERIOR TRABAJO FIN DE GRADO CURSO ACADÉMICO [2023-2024] TÍTULO: Diseño Hardware de una familia de cifradores lightweight ASCON AUTOR: DAVID GONZÁLEZ VILLALBA TUTOR: D. CARLOS J. JIMENEZ FERNANDEZ DEPARTAMENTO: TECNOLOGIA ELECTRONICA ÁREA DE CONOCIMIENTO: TECNOLOGIA ELECTRONICA Grado en Ingeniería Electrónica Industrial Escuela Politécnica Superior – Universidad de Sevilla - 2 - Grado en Ingeniería Electrónica Industrial Escuela Politécnica Superior – Universidad de Sevilla RESUMEN En 2018 el NIST inició un proceso para solicitar, evaluar y normalizar esquemas que proporcionen cifrado autenticado con datos asociados (AEAD) y, opcionalmente funcionalidades hash, para entornos con recursos restringidos (lightweight). Este proceso finalizó en febrero de 2023 eligiendo a ASCON como el ganador. Este Trabajo de Fin de Grado se centra en la Criptografía lightweight, analizando, implementando en hardware y evaluando ASCON. ASCON ofrece un cifrado y descifrado eficiente junto con un mecanismo de autenticación, e incorpora también la funcionalidad de generar Hash. El objetivo principal consistió en trasladar el algoritmo matemático de ASCON a una descripción hardware en VHDL, diseñando un sistema funcional y eficiente. La creación de una máquina de estados en VHDL fue fundamental para asegurar el cifrado, descifrado y autenticación correcta. Se desarrolló una interfaz intuitiva que facilita la interacción con el sistema de cifrado y permite realizar pruebas exhaustivas en diversos escenarios. Finalmente, se evaluó el rendimiento del cifrador en términos de consumo de recursos y uso del espacio en la FPGA, identificando oportunidades de optimización. PALABRAS CLAVE: Criptografía lightweight; Algoritmo ASCON; VHDL; Autenticación; FPGA, NIST, CAESAR. Grado en Ingeniería Electrónica Industrial Escuela Politécnica Superior – Universidad de Sevilla - 4 - ABTRACT In 2018, the NIST initiated a process to solicit, evaluate, and standardize schemes that provide Authenticated Encryption with Associated Data (AEAD) and, optionally, hash functionalities for environments with restricted resources (lightweight). This process concluded in February 2023, selecting ASCON as the winner. This Final Year Project focuses on lightweight cryptography, analyzing, implementing in hardware, and evaluating ASCON. ASCON offers efficient encryption and decryption along with an authentication mechanism, and also incorporates the functionality to generate a hash. The main objective was to translate the mathematical algorithm of ASCON into a hardware description in VHDL, designing a functional and efficient system. The creation of a state machine in VHDL was crucial to ensure correct encryption, decryption, and authentication. An intuitive interface was developed to facilitate interaction with the encryption system and allow for comprehensive testing in various scenarios. Finally, the performance of the encryptor was evaluated in terms of resource consumption and space usage on the FPGA, identifying opportunities for optimization. KEYWORDS: Lightweight cryptography; ASCON algorithm; VHDL; Authentication; FPGA; NIST; CAESAR. - I - ÍNDICE CAPITULO 1: INTRODUCCION ..................................................................................... 3 CAPITULO 2: Criptografía lightweight necesidad e implementaciones ........................ 11 2.1 Necesidad y características de la criptografía lightweight. ............................. 11 2.1.1 Competencia Caesar .............................................................................. 12 2.1.2 Proyecto de criptografía lightweight del NIST ......................................... 13 2.1.3 Métricas ................................................................................................... 21 2.1.4 Funciones de la criptografía lightweight .................................................. 22 2.1.5 Cifradores AEAD ..................................................................................... 23 2.2 Tecnologías de implementación ..................................................................... 24 2.2.1 FPGA: Características Principales .......................................................... 25 2.2.2 Metodología de Diseño ........................................................................... 26 2.2.3 Placas de desarrollo ................................................................................ 27 2.3 Introducción a la familia de cifradores ASCON .............................................. 28 2.3.1 Familia de Cifradores ASCON: Diseños de Encriptación Autenticada ... 29 2.3.2 Fases de ASCON .................................................................................... 33 2.3.3 Permutaciones ASCON .......................................................................... 37 CAPITULO 3: Implementación hardware del algoritmo ASCON .................................. 41 3.1 Interfaz ........................................................................................................... 41 3.1.1 Componentes Principales del Diseño ..................................................... 44 3.1.2 Operación del Cifrador ............................................................................ 44 3.1.3 Carga de la Clave ................................................................................... 45 3.1.4 Carga del nonce ...................................................................................... 45 3.1.5 Procesamiento del Dato Asociado .......................................................... 46 3.1.6 Procesamiento del Texto Plano/Cifrado .................................................. 47 3.1.7 Proceso de Finalización .......................................................................... 47 3.1.8 Procesamiento de Bloques Parciales ..................................................... 47 3.2 Diseño Hardware ASCON .............................................................................. 48 3.2.1 Flujo de datos .......................................................................................... 53 3.2.2 Funcionamiento detallado de cada estado del cifrador ........................... 60 3.3 Comparativa del algoritmo ASCON-Hash con ASCON ................................. 69 3.3.1 Funcionamiento detallado de cada estado del cifrador ASCON-Hash ... 69 3.3.2 Estados y Transiciones en el Algoritmo ASCON-Hash ........................... 71 GONZÁLEZ VILLALBA, DAVID - II - CAPITULO 4: Test Bench y análisis de las implementaciones. ................................... 73 4.1 Test Bench ....................................................... ¡Error! Marcador no definido. 4.2 Analisis de las implementaciones .................................................................. 81 4.2.1 Análisis de "Slice Registers" y "Slice LUTs" ........................................... 81 CONCLUSIÓN ................................................................ ¡Error! Marcador no definido. BIBLIOGRAFÍA ............................................................................................................. 90 ANEXOS ......................................................................... ¡Error! Marcador no definido. - 3 - Figura 1. Nexys4 DDR .................................................................................................. 28 Figura 2. Proceso de (a) cifrado, (b) descifrado. Fuente: https://ascon.iaik.tugraz.at .. 34 Figura 3. Adición de constantes de ronda. Fuente: https://ascon.iaik.tugraz.at. .......... 38 Figura 4. Numero de rondas que se le asigna a una constante. Fuente: https://ascon.iaik.tugraz.at. ........................................................................................... 38 Figura 5. S-BOX. Fuente: https://ascon.iaik.tugraz.at. ................................................. 39 Figura 6. S-BOX. Fuente: https://ascon.iaik.tugraz.at .................................................. 39 Figura 7. Mezcla de 5 bits en cada posición de cada palabra de 64 bits. Fuente: https://ascon.iaik.tugraz.at ............................................................................................ 40 Figura 8. S-box. Fuente: https://ascon.iaik.tugraz.at. ................................................... 40 Figura 9. Interfaz para ASCON ..................................................................................... 42 Figura 10. Diagrama de flujo ASCON ........................................................................... 49 Figura 11. Diagrama de flujo Hash ............................................................................... 72 GONZÁLEZ VILLALBA, DAVID - 10 - - 11 - CAPITULO 2: Criptografía lightweight necesidad e implementaciones En el ámbito de la seguridad digital, la criptografía juega un papel fundamental, adaptándose continuamente a las exigencias de un mundo tecnológicamente avanzado. Los sistemas criptográficos se dividen principalmente en dos tipos: los basados en claves públicas y privadas, y los sistemas de clave secreta. La criptografía asimétrica, que utiliza un par de claves pública y privada, facilita operaciones seguras como la firma digital y el intercambio de claves, esenciales para la protección de la comunicación en la web. Paralelamente, la criptografía simétrica, que emplea una clave secreta compartida para el cifrado y descifrado de mensajes, destaca por su rapidez y eficacia, siendo ideal para el manejo de grandes volúmenes de datos. Dentro de la criptografía simétrica, el Estándar de Cifrado Avanzado (AES) representa un hito por su robustez y adaptabilidad, permitiendo el uso de claves de diversos tamaños y garantizando una protección efectiva en múltiples plataformas. No obstante, el surgimiento del Internet de las Cosas (IoT) y la proliferación de dispositivos de baja capacidad han impulsado la necesidad de sistemas criptográficos ligeros. Estos sistemas están diseñados para operar bajo severas limitaciones de recursos, proporcionando seguridad sin comprometer el rendimiento de dispositivos como etiquetas RFID, nodos de sensores y microcontroladores, lo que subraya la importancia de desarrollar soluciones que equilibren eficacia y eficiencia en entornos de recursos restringidos. 2.1 Necesidad y características de la criptografía lightweight La criptografía lightweight se destaca por su adaptación a las necesidades de dispositivos con recursos limitados, característicos del Internet de las Cosas (IoT). Estos dispositivos, que van desde sensores ambientales hasta dispositivos de comunicación portátiles, requieren soluciones de seguridad que consuman mínimos recursos mientras mantienen altos estándares de protección de datos. Una característica principal es su optimización para un bajo consumo energético y uso reducido de memoria. Esto es crucial para dispositivos que funcionan con baterías pequeñas o que tienen limitaciones de hardware. Además, estos sistemas criptográficos son diseñados para ser altamente eficientes, permitiendo un procesamiento rápido de datos, lo que es esencial para aplicaciones en tiempo real o dispositivos que necesitan responder rápidamente a inputs sensoriales. GONZÁLEZ VILLALBA, DAVID - 12 - Otra característica importante es la simplicidad de los algoritmos utilizados. A diferencia de la criptografía tradicional, que puede requerir complejas operaciones matemáticas y grandes cantidades de datos para garantizar la seguridad, se enfoca en algoritmos más sencillos que reducen la carga computacional sin comprometer la seguridad. Esta simplicidad también contribuye a una mayor facilidad de implementación en plataformas diversas, desde microcontroladores básicos hasta sistemas integrados más complejos. Otra característica esencial es la escalabilidad. A medida que los dispositivos IoT evolucionan y su número crece, los sistemas criptográficos deben ser capaces de adaptarse a diferentes niveles de seguridad, dependiendo de las necesidades específicas de cada dispositivo o red. La justificación para la adopción de la criptografía lightweight no solo reside en su adaptabilidad y eficiencia, sino también en la necesidad imperiosa de proteger información sensible en dispositivos altamente distribuidos y a menudo vulnerables. La continua evolución y mejora de estos sistemas es crucial para enfrentar las crecientes amenazas de seguridad en un mundo cada vez más conectado. 2.1.1 Competencia Caesar La información presentada en esta sección se basa principalmente en datos obtenidos de la fuente [1] Competitions.cr.yp.to. (nd). CAESAR: Competition for Authenticated Encryption: Security, Applicability, and Robustness. de https://competitions.cr.yp.to/caesar-call.html La Competición de Cifrado Autenticado: Seguridad, Aplicabilidad y Robustez (CAESAR) representa una iniciativa internacional clave diseñada para impulsar el desarrollo de esquemas de cifrado autenticados que sean más seguros y eficientes. Lanzada en el taller Early Symmetric Crypto en 2013 y concluyendo con la presentación de su portafolio final en 2019, CAESAR ha tenido un impacto significativo en la evolución de la criptografía. Esta competencia se centró en identificar nuevos algoritmos que no solo protegieran la confidencialidad de los datos cifrando el contenido, sino que también verificaran su integridad y autenticidad, lo cual es vital en entornos donde la manipulación de datos puede tener consecuencias graves. El portafolio final de CAESAR se categorizó en tres casos de uso principales, optimizados para diferentes escenarios: aplicaciones ligeras diseñadas para entornos con recursos limitados, aplicaciones de alto rendimiento para el procesamiento de datos a gran escala, y estrategias de defensa en profundidad para seguridad en múltiples niveles. Los ganadores de esta competencia fueron: - 13 - • Ascón y BELLOTA, que se destacaron por su eficiencia en el uso de recursos, lo que los hace especialmente adecuados para dispositivos con restricciones de energía y capacidad de procesamiento. • En la categoría de alto rendimiento, los algoritmos que se llevaron el reconocimiento fueron AEGIS-128 y OCB, ambos elogiados por su capacidad para procesar rápidamente grandes volúmenes de datos, ideal para aplicaciones que demandan una alta velocidad de procesamiento. • Para defensa en profundidad, los algoritmos seleccionados fueron Deoxis-II y COLM, que ofrecen soluciones robustas y seguras para entornos donde la seguridad de múltiples niveles es crítica. El comité de CAESAR, compuesto por criptógrafos renombrados como Daniel J. Bernstein y Joan Daemen, no solo evaluó las propuestas, sino que también orientó la competencia hacia soluciones que superaran los estándares existentes, como AES-GCM. Los algoritmos propuestos fueron sometidos a rigurosos criterios de rendimiento, facilidad de implementación y resistencia a ataques, buscando soluciones aplicables a una amplia gama de necesidades, desde sistemas altamente restringidos hasta aquellos que demandan una seguridad máxima. 2.1.2 Proyecto de criptografía lightweight del NIST La información presentada en esta sección se basa principalmente en datos obtenidos de la fuente [2] National Institute of Standards and Technology. (2023). Final steps of the NIST lightweight cryptography standardization process. El National Institute of Standards and Technology (NIST), parte del Departamento de Comercio de los Estados Unidos, fue fundado en 1901 originalmente como el National Bureau of Standards. La misión primordial de NIST es promover la innovación y la competitividad industrial de EE. UU. a través del avance de la ciencia de la medición, los estándares y la tecnología. Esta misión subraya el compromiso del instituto con la seguridad económica y la mejora de la calidad de vida a través de innovaciones que sostienen tanto el sector privado como el público. NIST emplea a más de 3,400 trabajadores federales y trabaja con aproximadamente 3,500 asociados, incluyendo investigadores y contratistas externos. Ha sido reconocido con varios Premios Nobel, destacando su excelencia en investigación y desarrollo en diversas disciplinas científicas y tecnológicas. Un componente crucial de NIST es la Computer Security Division (CSD), que se enfoca en desarrollar estándares criptográficos robustos. La CSD ha liderado competiciones internacionales para el desarrollo de nuevos estándares criptográficos, tales como AES (Advanced Encryption Standard) y GONZÁLEZ VILLALBA, DAVID - 14 - SHA-3. También ha jugado un papel crucial en la adopción de estándares existentes como RSA y HMAC y ha hecho propuestas sobre modos de la operación de cifrado en bloque. Estas actividades están documentadas en varias publicaciones de NIST, incluyendo los Federal Information Processing Standards (FIPS) y las NIST Special Publications (SPs), que ofrecen directrices y recomendaciones técnicas para su uso. Los principios que guían el trabajo de NIST incluyen la transparencia, apertura, integridad, mérito técnico, y la mejora continua, asegurando que sus estándares y recomendaciones sean globalmente aceptados y utilizables. El Advanced Encryption Standard (AES), publicado en 2001 bajo el Federal Information Processing Standard (FIPS) 197, es uno de los logros más significativos del National Institute of Standards and Technology (NIST). El AES fue adoptado tras una competición pública que buscaba reemplazar el antiguo estándar DES debido a sus limitaciones de seguridad y rendimiento. Tras una revisión exhaustiva después de veinte años, AES fue actualizado en mayo de 2023 para ajustarse a las necesidades modernas de seguridad, manteniendo su posición como el cifrador más utilizado globalmente, influyendo considerablemente en la economía y la seguridad digital. El AES se implementa junto con varios modos de operación especificados en el documento SP 800-38 de NIST [11], incluyendo CBC, OFB, y GCM, entre otros. Estos modos permiten el uso de AES en diferentes contextos de seguridad, ofreciendo flexibilidad en la protección de la integridad y la confidencialidad de los datos. A pesar del éxito de AES, la evolución continua de las tecnologías y los modelos de amenazas ha llevado a NIST a explorar nuevos primitivos criptográficos. Los nuevos desarrollos también buscan ofrecer algunas características como resistencia al mal uso de Nonces, resistencia inherente a canales laterales, seguridad post-cuántica. El rápido crecimiento de dispositivos como etiquetas RFID, redes sensores o nodos IoT ha creado una necesidad de estándares criptográficos optimizados para entornos con recursos limitados. En respuesta a esta necesidad, el NIST lanzó un proyecto similar a las competiciones AES, SHA-3 y PQC, pero centrado en la criptografía lightweight para generar un nuevo estándar. El objetivo de este nuevo estándar no es sustituir al AES, sino crear uno más adaptado a estos nuevos dispositivos. La temporización del proyecto de criptografía lightweight del NIST es la siguiente: - 15 - Fase Inicial (julio 2015 – agosto 2018) Durante la fase inicial, el NIST se centró en recopilar información sobre las necesidades y requisitos específicos para la criptografía lightweight. Esta fase incluyó la organización de dos talleres principales: 1. Primer Taller de Criptografía lightweight (20 – 21 de julio, 2015): Tuvo como objetivo entender las necesidades de la industria y recoger opiniones de expertos sobre las características y requisitos de seguridad deseados para la Criptografía lightweight. 2. Segundo Taller de Criptografía lightweight (17 – 18 de octubre, 2016): Continuó las discusiones sobre aplicaciones específicas y refinó los requisitos basados en la retroalimentación recibida. Publicaciones como el Informe NISTIR 8114 sobre Criptografía lightweight [3] proporcionaron pautas fundamentales y delinearon los perfiles para el proceso de estandarización de la criptografía lightweight. Convocatoria de Presentaciones (agosto 2018 – abril 2019) En agosto de 2018, el NIST publicó los ‘Requisitos de Presentación y Criterios de Evaluación para el Proceso de Estandarización de la Criptografía lightweight’. El plazo para las presentaciones se fijó para febrero de 2019. Los requisitos incluyeron: • Requisitos de seguridad: Un nivel de seguridad mínimo de 112 bits para mensajes de hasta 250 bytes, respetando el Nonce. El tamaño de clave debía ser al menos 128 bits. • Requisitos de diseño: Rendimiento superior a los estándares de NIST (AES-GCM, SHA-2), optimizados para mensajes cortos. • Requisitos de implementación: Implementación de referencia y optimizada compatible con la API (Interfaz de Programación de Aplicaciones) especificada en el documento "Hardware API for Lightweight Cryptography" [12]. Primera Ronda (abril 2019 – agosto 2019) Durante aproximadamente cuatro meses, 56 candidatos fueron evaluados basándose en su seguridad, incluyendo aspectos como ataques de distinción, falsificaciones prácticas de etiquetas, problemas de separación de dominios, y nuevos diseños sin análisis de terceros. El Informe NIST IR 8268 detalla las razones por las cuales sólo 32 candidatos fueron seleccionados para avanzar a la segunda ronda. GONZÁLEZ VILLALBA, DAVID - 16 - Segunda Ronda (agosto 2019 – marzo 2021) Durante unos 20 meses, los 32 candidatos de la segunda ronda participaron en talleres adicionales para profundizar en el análisis y la mejora de sus propuestas: • Tercer Taller de Criptografía lightweight (4 – 6 de noviembre, 2019). • Cuarto Taller de Criptografía lightweight (19 – 21 de octubre, 2020). El Informe NIST IR 8369 explica cómo los 10 finalistas fueron seleccionados para avanzar a la ronda final. Ronda Final (marzo 2021 – febrero 2023) La evaluación de los diez finalistas duró aproximadamente dos años. Los finalistas fueron los siguientes: Tabla 1. Finalistas del proyecto de criptografía lightweight del NIST. Evaluar de manera justa a los finalistas fue una tarea completa, que involucró la asignación de diferentes pesos para distintos criterios, variadas afirmaciones de seguridad, funcionalidades, y ataques de diferentes complejidades. Los recursos limitados para el análisis de seguridad y la evaluación comparativa también presentaron desafíos. La decisión final se basó en los análisis y los resultados de evaluación comparativa de todos los candidatos, que están disponibles públicamente, asegurando que los estándares propuestos no solo fueran técnicamente sólidos, sino también viables y aplicables en el contexto deseado. A continuación, se resumen las principales características de los finalistas mostrados en la tabla 1: ASCON Tiene un esquema de cifrado y Hashing basado en permutaciones (con un registro de estado de 320-bit), con AEAD usando el modo MonkeyDuplex que incluye inicialización y finalización con clave, y Hashing de tipo esponja. No se realizaron ajustes en el diseño, pero se añadió una nueva variante en la ronda ASCON Photon-Beetle Sparkle Grain-128AEAD Isap Xoodyak Elepahnt ROMULUS Tinyjambu Gift-Cob - 17 - final al incluirlo en el portafolio final de CAESAR para la encriptación autenticada lightweight. ELEPHANT Esquema AEAD basado en permutaciones (esponja y Keccak [200]). Utiliza un modo paralelo único de cifrar y luego MAC basado en Nonce. El algoritmo fue ligeramente modificado para garantizar autenticidad bajo reutilización de Nonce. GIFT-COCB: Esquema AEAD basado en el cifrado de bloque GIFT-128, utilizando el algoritmo de realimentación combinada (COFB). No se realizaron ajustes en el diseño. GRAIN-128-AEAD Esquema AEAD basado en un registro de desplazamiento con realimentación. Se realizó un ajuste en la parte de inicialización respecto a las versiones anteriores incluidas en el portafolio eSTREAM y en la norma ISO/IEC 29167- 13:2005. ISAP Esquema AEAD basado en permutaciones (ASCON y Keccak) que puede combinarse con ASCON Hash. Utiliza un modo de cifrar y luego MAC basado en Nonce. No se realizaron ajustes en la variante principal, aunque se actualizó. PHOTON BEETLE Familia de esquemas de cifrado y Hashing basados en permutaciones (permutación Photon de 256-bit), operando en un modo similar a Esponja con realimentación combinada. No se realizaron ajustes en el diseño. ROMULUS Familia de esquemas AEAD y de Hashing basados en cifrados de bloque ajustables (Skinny). Incluye variantes que respetan y que abusan del Nonce, con ajustes en el diseño que reducen el número de rondas de 56 a 40, eliminación de variantes no primarias y adición de nuevas variantes. SPARKLE Familia de esquemas AEAD (SCHWAEMM) y de Hashing (ESCH) basados en permutaciones, con un diseño basado en ARX. Utiliza una construcción Esponja con realimentación combinada. Se realizó un ajuste para cambiar la variante primaria. TINYJAMBU GONZÁLEZ VILLALBA, DAVID - 18 - Esquema AEAD basado en permutaciones con clave, utilizando un registro de desplazamiento no lineal de 128-bit. Inspirado en JAMBU (candidato de CAESAR), con un ajuste en el diseño que aumenta el número de rondas para mejorar el margen de seguridad. XOODYAK Familia de esquemas de cifrado y Hashing basados en permutaciones, utilizando la permutación Xoodoo de 384-bits. Opera en modo Cyclist, con un ajuste en la inicialización para mejorar el rendimiento en mensajes cortos. Todos los finalistas debían cumplir con requisitos de seguridad que incluían claves de al menos 128 bits y tamaños de mensajes de entrada de hasta 250 bytes (ver Tabla 2 para los finalistas de cifradores y Tabla 3 para los finalistas del hash). Todos los finalistas cumplieron con los requisitos de seguridad y proporcionaron márgenes de seguridad suficientes: • Ninguna de las reclamaciones de seguridad hechas por los participantes fue invalidada. • La madurez del diseño fue uno de los factores importantes en la evaluación de la seguridad. Esto incluyó preguntas como: ¿Está el finalista basado en principios de diseño bien establecidos? ¿Recibió el diseño suficiente análisis por terceros? ¿Hay ajustes en el diseño que invaliden los análisis de seguridad anteriores? ¿Existen preocupaciones adicionales como el mal uso de Nonce, seguridad relacionada con la clave, seguridad RUP o seguridad post-cuántica? Selección de ASCON. En febrero de 2023, el NIST anunció la familia ASCON como la ganadora debido a: • Un alto margen de seguridad y un gran número de análisis por terceros, dado que fue diseñado en 2014. • Elección principal para aplicaciones ligeras en el portafolio final de CAESAR (en 2019). • No necesitaba ajustes en el diseño. • Ventajas de rendimiento sobre los estándares del NIST (AES-GCM y SHA-2) tanto en hardware como en software. • Flexibilidad de implementación y diseño. • Mecanismo de protección a nivel de modo contra fugas y costo adicional bajo para implementaciones protegidas. • Soporte para funcionalidades adicionales como XOF, MAC dedicado, además de Hash. - 19 - Variantes a estandarizar: • Estándarizar ASCON-128 o ambos, ASCON-128 y ASCON-128a. • No incluir ASCON-80pq. • Estandarizar XOF en lugar de funciones Hash. Tamaños de parámetros de las variantes: • Variante AEAD: ASCON-128 y ASCON-128a con claves/Nonces/tags de 128 bits. • Variante: ASCON-80-pq con claves de 160 bits y Nonces/tags de 128 bits. • Hash: ASCON-Hash y ASCON-Hasha con resúmenes de 256 bits. • XOF: ASCON-XOF y ASCON-XOFa con resúmenes de longitud arbitraria. Posibles actualizaciones: • Soporte de tags más cortos: de 64 y 96 bits. • Soporte para cadenas de personalización. • Codificación little endian de las entradas para implementaciones más eficientes. • Soporte para funcionalidades adicionales como PRF (función pseudoaleatoria), MAC (código de autenticación de mensajes), KDF (función de derivación de clave), DRBG (generador de números pseudoaleatorios basado en la demanda), entre otros. Finalistas Variantes Bloque de construcción Modo Key Size Nonce Size Tag Size ASCON ASCON-128 ASCON Permutación MonkeyDuplex 128 128 128 ASCON-128a ASCON Permutación MonkeyDuplex 128 128 128 ASCON-80pq ASCON Permutación MonkeyDuplex 160 128 128 Elephant Dumbo Spongent-π [160] Encrypt-then- MAC 128 96 64 Jumbo Spongent-π [176] Encrypt-then- MAC 128 96 64 Delirium KECCAK-ρ [200] Encrypt-then- MAC 128 96 128 GIFT-COFB GIFT-COFB GIFT-128 Combined Feedback 128 128 128 GONZÁLEZ VILLALBA, DAVID - 26 - Una de las ventajas más significativas de las FPGAs es su capacidad para ejecutar múltiples operaciones en paralelo. A diferencia de los procesadores tradicionales que procesan las instrucciones de manera secuencial, las FPGAs pueden configurarse para realizar cálculos complejos en paralelo, lo que aumenta enormemente la velocidad de procesamiento de las aplicaciones. Esta característica es valiosa para aplicaciones que requieren un gran volumen de procesamiento de datos y cálculos en tiempo real, como el procesamiento de señales, comunicaciones móviles y aplicaciones de video, donde el rendimiento del sistema es crítico. Además, ofrecen una mayor eficiencia energética en comparación con los sistemas basados en CPU o GPU tradicionales. Al poder configurar exactamente las rutas de hardware necesarias para una tarea específica, los FPGAs eliminan la necesidad de componentes superfluos que consumirían energía adicional. Además, al operar a velocidades de reloj más bajas que las CPUs para muchas tareas específicas, pueden ofrecer una disminución significativa en el consumo de energía, lo cual es crucial en dispositivos portátiles y aplicaciones donde la eficiencia energética es fundamental. Esta eficiencia también se traduce en menos calor disipado, lo que simplifica los requisitos de enfriamiento y reduce los costos de mantenimiento. Además, los FPGAs pueden ser diseñados con características de seguridad integradas, como la criptografía a nivel de hardware y la protección contra manipulaciones físicas. Estas características los hacen ideales para su uso en aplicaciones donde la seguridad es de máxima prioridad, como en sistemas de pago, aplicaciones militares y de infraestructura crítica. 2.2.2 Metodología de Diseño La metodología de diseño de las FPGA se centra fundamentalmente en el uso de lenguajes de descripción de hardware (HDLs), como VHDL y Verilog, que son fundamentales para definir la estructura y el comportamiento de los sistemas electrónicos. Estos lenguajes permiten a los diseñadores crear modelos a nivel de transferencia de registros (RT) de componentes electrónicos que luego se implementan físicamente en un FPGA. La precisión y flexibilidad que ofrecen estos lenguajes son esenciales para explotar plenamente las capacidades de las FPGAs, permitiendo diseños complejos que pueden ser reiteradamente modificados y optimizados antes de su implementación final. Los lenguajes de descripción de hardware proporcionan estructuras sintácticas y semánticas que facilitan la descripción detallada del circuito a nivel de bit o de dato, lo que permite simular el diseño antes de la fabricación. Esta capacidad es crucial para validar la lógica y detectar errores en las fases tempranas del desarrollo. Además, el uso de HDLs facilita la iteración rápida y la optimización - 27 - del diseño, permitiendo a los diseñadores realizar cambios y evaluar los efectos inmediatos sin necesidad de prototipos físicos costosos. La metodología de diseño basada en HDLs tiene un impacto significativo en la velocidad y el costo de producción de las FPGA. Al permitir una descripción precisa del hardware deseado, los HDLs reducen el riesgo de errores costosos en las etapas finales de desarrollo y producción. Además, al facilitar la reutilización de componentes probados en nuevos proyectos, los HDLs pueden disminuir significativamente el tiempo de desarrollo y los costos asociados, acelerando el ciclo de innovación en la electrónica digital. Junto con los HDLs, diversas herramientas de desarrollo juegan un papel crucial en el diseño de FPGA. Software de síntesis, herramientas de simulación y procesos de Place and Route son parte integral del desarrollo, con ejemplos populares como Quartus II de Intel y Vivado o ISE de Xilinx. Estas herramientas proporcionan entornos integrados que facilitan todo el proceso de diseño de las FPGA. En cuanto a los fabricantes, empresas como AMD-Xilinx e Intel-FPGA lideran el mercado, ofreciendo soluciones que se adaptan a una amplia gama de aplicaciones industriales y comerciales. Xilinx, en particular, ofrece varias familias de FPGAs, como Virtex, Artix y Spartan, diseñadas para diferentes niveles de rendimiento y aplicaciones específicas, desde telecomunicaciones de alto rendimiento hasta dispositivos portátiles y aplicaciones comerciales generales. 2.2.3 Placas de desarrollo Las placas de desarrollo FPGA son herramientas esenciales en ingeniería electrónica, proporcionando una plataforma efectiva para el desarrollo, prueba y prototipado de soluciones electrónicas. Estas plataformas son valiosas tanto en contextos educativos como profesionales, ya que permiten a los usuarios diseñar y modificar circuitos sin el alto costo y tiempo asociado con la fabricación de hardware personalizado. Son especialmente útiles para la experimentación y la validación de conceptos en etapas tempranas de diseño, acelerando el proceso de desarrollo de nuevos productos y tecnologías. GONZÁLEZ VILLALBA, DAVID - 28 - La Nexys4 DDR de Digilent es una placa de desarrollo que se destaca en el ámbito educativo y de investigación debido a su balance óptimo entre costo y funcionalidad. Está equipada con un dispositivo XC7A100T de la serie 7 de Xilinx, y viene con una variedad de características y elementos que apoyan el desarrollo avanzado de aplicaciones electrónicas. El dispositivo FPGA, que se encuentra en la placa Nexys4 DDR, es responsable de realizar todas las operaciones de procesamiento y lógica digital en la placa. Las FPGAs de la familia Artix-7 tienen un alto rendimiento y flexibilidad, permitiendo a los usuarios configurar el dispositivo para realizar una amplia gama de funciones digitales que van desde el procesamiento de señales simples hasta operaciones complejas de procesamiento de datos. La placa Nexys4 DDR incorpora 128MB de memoria DDR2, que es esencial para aplicaciones que manejan grandes volúmenes de datos o requieren altas velocidades de procesamiento. La memoria DDR2 es crucial para soportar aplicaciones intensivas como el procesamiento de imágenes o la ejecución de algoritmos complejos que necesitan un acceso rápido y eficiente a los datos [8]. 2.3 Introducción a la familia de cifradores ASCON La información que se presenta en esta sección se basa principalmente en datos obtenidos de la fuente Graz University of Technology. (n.d.). ASCON – Authenticated Encryption and hashing de https://ascon.iaik.tugraz.at/ [9]. Esta Figura 1. Nexys4 DDR - 29 - propuesta es fruto del trabajo conjunto de renombrados especialistas en criptografía como Christoph Dobraunig, María Eichlseder, Florián Mendel y Martin Schläffer. Se aborda en esta sección tres componentes clave: los diseños de encriptación autenticada de ASCON, las fases detalladas del proceso de encriptación, que explican cómo se aplica el algoritmo fase por fase, y las permutaciones específicas que aseguran la seguridad y optimización del algoritmo. 2.3.1 Familia de Cifradores ASCON: Diseños de Encriptación Autenticada El conjunto de cifradores ASCON incluye una familia de diseños para encriptación autenticada y la función de Hash ASCON-Hash, que utiliza la función de salida extensible ASCON-Xof. Los diseños se definen con base en parámetros específicos y se describen a continuación en la tabla 4, incluidos los procedimientos de cifrado y descifrado. La familia de ASCON están parametrizados por la longitud de la clave (k menor o igual a 160 bits), el tamaño del bloque de datos r y los números de rondas internas (a y b). A partir de estos valores se especifica un algoritmo de encriptación autenticada, E (k, r, a, b), y un algoritmo de descifrado, D (k, r, a, b) donde se fijan los valores de los parámetros. El procedimiento de encriptación autenticada, E (k, r, a, b), toma las siguientes entradas: • Una clave secreta K con k bits. • Un Nonce N con 128 bits. • Datos asociados A de cualquier longitud. • Un texto plano P de cualquier longitud. Este procedimiento produce: • Un texto cifrado C de la misma longitud que el texto plano P. • Una etiqueta de autenticación T de 128 bits que autentica los datos asociados y el mensaje cifrado. Procedimiento de Descifrado y Verificación D (k, r, a, b) recibe como entradas: • La clave K. • El Nonce N. • Los datos asociados A. • El texto cifrado C. • La etiqueta de autenticación T. La salida es el texto plano P si la verificación de la etiqueta es correcta, o un error "?" si la verificación falla. GONZÁLEZ VILLALBA, DAVID - 30 - Encriptación: ASCON mezcla la clave secreta, el Nonce y los datos asociados para configurar el estado interno. Luego, incorpora el texto plano al estado, generando el texto cifrado y la etiqueta de autenticación. Descifrado: Utiliza la misma clave y Nonce, junto con los datos asociados, para reconstruir el estado interno y procesar el texto cifrado, recuperando el texto plano y verificando la etiqueta de autenticación. Esta configuración permite que ASCON se adapte a diversas necesidades de seguridad y rendimiento, asegurando una encriptación y autenticación eficaz y segura de mensajes, especialmente en entornos con recursos limitados. K Clave secreta K de k ≤ 160 bits. N, T Nonce N, etiqueta T, todos de 128 bits. P, C, A Texto plano P, texto cifrado C, datos asociados A (en bloques de r bits Pi, Ci, Ai). M, H Mensaje M, valor de Hash H (en bloques de r bits Mi, Hi). ? Error, la verificación del texto cifrado autenticado falló. S El estado de 320 bits S de la construcción de esponja. Sr, Sc La parte de la tasa de r bits y la capacidad de c bits del estado S. p, pa, pb Permutaciones pa, pb que consisten en a, b rondas de actualización p, respectivamente. X ϵ {0,1}k Cadena de bits x de longitud k (variable si k = λ). 0k Cadena de bits de k bits (longitud variable si k = λ), todos 0. |x| Longitud de la cadena de bits x en bits. |x|k Cadena de bits x truncada a los primeros (más significativos) k bits. [x]k Cadena de bits x truncada a los últimos (menos significativos) k bits. x || y Concatenación de cadenas de bits x e y. x ⊕ y XOR de cadenas de bits x e y. x mod y Resto en la división entera de x por y. [𝑥𝑥] Función techo, el entero más pequeño mayor que x. pc,ps,pL adición de constante, sustitución y capa lineal de p = pL ∘ ps ∘ pc. x0,….,x4 Las cinco palabras de 64 bits del estado S. x0,i,….,x4,i Bit i, 0 ≤ i < 64, de las palabras x0, ..., x4, con x_0,0 el bit más a la derecha (LSB). Tabla 4. Notación utilizada para la interfaz, modo y permutación de ASCON. - 31 - Esquemas Recomendados de Encriptación Autenticada Aunque la propuesta del algoritmo no fija el tamaño de la clave ni el tamaño de los bloques de datos, ASCON propone dos configuraciones principales para la encriptación autenticada, denominadas ASCON-128 y ASCON-128a, que fueron seleccionadas en la competición CAESAR como las recomendadas para casos de uso ligeros. En ambas configuraciones el tamaño de clave es de 128 bits. Los valores de los parámetros se muestran en la tabla 5. Nombre Algoritmos Tamaño de clave Nonce Tag Data block pa pb ASCON-128 E, D 128 128 128 64 12 6 ASCON- 128ª E, D 128 128 128 128 12 8 Tabla 5. Parámetros para esquemas recomendados de encriptación autenticada. ASCON también especifica recomendaciones para el Hashing, con ASCON- Hash siendo la principal y única recomendación la que se muestra en la tabla 6. Nombre Algoritmos Tamaño de clave Data block pa pb ASCON-Hash X 256 64 12 12 ASCON-Hasha X 256 12 12 8 Tabla 6. Parámetros para algoritmos de Hashing recomendados. La instancia recomendada de Hashing, ASCON-Hash, utiliza un tamaño de bloque de datos de 64 bits y 12 rondas para la permutación, produciendo una salida de Hash de 256 bits. ASCON-Hasha se distingue de ASCON-Hash principalmente en el número de rondas de la permutación pb, siendo ASCON- Hasha más ligero con 8 rondas en lugar de las 12 rondas utilizadas en ASCON- Hash. Para emparejar la encriptación autenticada con el Hashing, se recomienda combinar ASCON-128 y ASCON-Hash, ya que ambos comparten el mismo tamaño de bloques. Construcciones adicionales basadas en la Permutación de ASCON Además de las recomendaciones principales, la permutación de ASCON se puede utilizar para otros propósitos y en diferentes configuraciones de parámetros. GONZÁLEZ VILLALBA, DAVID - 32 - • ASCON-Xof: Se define una función de salida extensible que utiliza el algoritmo X0,64,12 con una tasa de 64 bits y 12 rondas para pa, produciendo una salida de Hash de longitud arbitraria. • ASCON-80pq: Se define un nuevo esquema de encriptación autenticada que utiliza los algoritmos E, D160,64,12,6 con un tamaño de clave aumentado a 160 bits, un tamaño de Nonce y etiqueta de 128 bits, una tasa de 64 bits, 12 rondas para pa y 6 rondas para pb. Estado interno La familia ASCON opera utilizando un estado interno de 320 bits, el cual se actualiza mediante permutaciones designadas como Pₐ (con a rondas) y pb (con b rondas). Este modelo de funcionamiento está basado en la construcción de esponja criptográfica, donde el estado se divide en dos partes principales: una parte externa (Sr) y una parte interna (Sc), con una tasa (r) y una capacidad (c = 320 - r) que varían según la variante de ASCON empleada. El estado de 320 bits (S) se divide en: • Parte externa (Sr): de r bits, la cual interactúa directamente con los datos durante las fases de absorción y extracción de la esponja. • Parte interna (Sc): de c bits, que sirve para mantener la seguridad de los datos al no interactuar directamente con ellos y asegurar la no reversibilidad del proceso. Para la descripción y aplicación de las transformaciones de ronda, el estado de 320 bits (S) se divide en cinco registros de 64 bits denominados palabras. 𝑆𝑆=𝑆𝑆𝑟𝑟∥ 𝑆𝑆𝑐𝑐= Esta disposición permite que las operaciones sobre el estado se realicen de manera eficiente, aprovechando las propiedades de la arquitectura del hardware donde se implemente ASCON, como procesadores de 64 bits. Interfaz de Esponja y Codificación Cuando se necesita interpretar el estado como un array de bytes (o cadena de bits) para la interfaz de esponja, se comienza con el byte (o bit) más significativo. Esta forma de interpretación es crucial para la conversión entre la representación del estado interno y los datos que se están procesando (por ejemplo, durante la absorción del mensaje en la fase de esponja o la generación del cifrado y la etiqueta de autenticación). - 33 - Este modelo de funcionamiento permite a ASCON realizar tanto la encriptación autenticada como operaciones de Hashing de manera segura y eficiente, optimizando el uso del estado para garantizar tanto la confidencialidad como la integridad de los datos procesados. La división del estado en registros de 64 bits facilita la implementación de las permutaciones y las transformaciones de ronda, elementos clave para la seguridad del algoritmo. 2.3.2 Fases de ASCON ASCON utiliza un modo de operación basado en esponja dúplex para la encriptación autenticada, optimizado para seguridad y eficiencia en entornos con recursos limitados. La configuración recomendada para la longitud de clave, etiqueta y Nonce es de 128 bits. El algoritmo se caracteriza por las siguientes fases mostradas en la figura 2: 1. Inicialización: Se inicia el estado con la clave secreta K y el Nonce N Esta fase prepara el estado de la esponja para el procesamiento de datos. 2. Procesamiento de los datos asociados: Actualiza el estado con bloques de datos asociados Ai. Los datos asociados son procesados para integrarlos en el estado, pero no se cifran. 3. Procesamiento de Texto Plano: Inyecta bloques de texto plano Pi en el estado y extrae bloques de texto cifrado Ci. Esta es la fase donde se realiza el cifrado del mensaje. 4. Finalización: Inyecta la clave K nuevamente y extrae la etiqueta T para autenticación. La etiqueta asegura la integridad y la autenticidad del mensaje cifrado. Después de cada bloque inyectado (excepto el último bloque de texto plano), se aplica la permutación central pb al estado completo. Durante la inicialización y la finalización, se utiliza una permutación más fuerte pa con más rondas. Los números de rondas a y b, así como la tasa y capacidad de la esponja, dependen de la variante de ASCON. Los parámetros recomendados son: ASCON-128: 128 bits para clave, Nonce y etiqueta; tasa de 64 bits, capacidad de 256 bits, 12 rondas en pa y 6 rondas en pb. ASCON-128a: 128 bits para clave, Nonce y etiqueta; tasa de 128 bits, capacidad de 192 bits, 12 rondas en pa y 8 rondas en pb. Estas configuraciones permiten un equilibrio entre seguridad y rendimiento, haciendo a ASCON adecuado para una amplia gama de aplicaciones, GONZÁLEZ VILLALBA, DAVID - 34 - especialmente en dispositivos donde el espacio y el consumo de energía son consideraciones críticas. Inicialización El estado inicial de 320 bits de ASCON se forma por la clave secreta K de k bits y el Nonce N de 128 bits, así como un IV que especifica el algoritmo (incluyendo el tamaño de la clave k, la tasa r, el número de rondas de inicialización y finalización a, y el número de rondas intermedias b, cada uno escrito como un entero de 8 bits): IVk,r,a,b = k | r | a | b | 0160-k = 0x80400c0600000000 para ASCON-128 0x80800c0800000000 para ASCON-128a 0xa0400c06 para ASCON-80pq Donde S ← IV {k, r, a, b} | K | N En la inicialización, se aplican a rondas de la transformación de ronda p al estado inicial, seguido por un XOR de la clave secreta K: S ← pa(S) ⊕ (0320-k || K) Figura 2. Proceso de (a) cifrado, (b) descifrado. Fuente: https://ascon.iaik.tugraz.at - 35 - Procesado del dato asociado ASCON procesa los datos asociados A en bloques de r bits. Añade un único 1 y el menor número de 0s a A para obtener un múltiplo de r bits y lo divide en s bloques de r bits, A1||…||As. En caso de que A esté vacío, no se aplica ningún relleno y s = 0: A1,…,As ←r bit blocks of A || 1 || 0r-1-(|A| mod r) si |A| > 0 A1,…,As ← Ǿ si |A| = 0 Cada bloque Ai con i = 1,…,s se hace un XOR con los primeros r bits Sr del estado S, seguido por la aplicación de la permutación de b rondas pb a S: S ← pb ((Sr ⊕ Ai ) || Sc) Después de procesar As (también si s=0), se hace un XOR a S con una constante de separación de dominio de 1 bit: S ← S ⊕ (0319 || 1) Procesado del texto plano / texto cifrado ASCON procesa el texto plano P en bloques de r bits. El proceso de relleno añade un único 1 y el menor número de 0s al texto plano P de tal manera que la longitud del texto plano rellenado sea un múltiplo de r bits. El texto plano rellenado resultante se divide en t bloques de r bits, P1 hasta Pt. P1,…,Ps ←r bit blocks of P || 1 || 0r-1- ( |P| mod r) GONZÁLEZ VILLALBA, DAVID - 42 - Figura 9. Interfaz para ASCON - 43 - SEÑALES DE ENTRADA Señal Tamaño (Bits) Descripción Clk 1 Señal de reloj Reset 1 Señal de reset activo en alta Init 1 Señal de inicio Key_Update 1 Señal de inicio de carga de la clave Hash_Signal 1 Señal de inicio para el Hash Data_In 32 Bus de datos de entrada dValid 1 Señal de que el dato de entrada es valido descryptIn 1 Señal que indica si ciframos/desciframos dEob 1 Señal que indica que se está procesando el último bloque dEop 1 Señal que indica que se está procesando el último paquete. Partial 1 Señal que indica que el ultimo bloque es parcial PartialBits 3 Señal que indica el tamaño (bytes) que tiene el ultimo bloque SEÑALES DE SALIDA Señal Tamaño (Bits) Descripción Data_Out 32 Bus de datos de salida OutValid 1 Señal que indica el dato en el bus de salida es valido authValid 1 Señal que indica la validez de la operación de descifrado dReady 1 Señal que indica que el cifrador está listo para recibir dato de entrada. Tabla 7. Señales de entrada y salida del Diseño ASCON. GONZÁLEZ VILLALBA, DAVID - 44 - 3.1.1 Componentes Principales del Diseño El diseño para el cifrado/descifrado se compone de dos componentes esenciales: • Top: Se encarga de orquestar la operación del cifrador. Aquí reside la máquina de estados, que dirige las fases de cifrado, junto con la lógica combinacional necesaria para procesar las señales de entrada y salida. • ASCONPermutation: Este módulo ejecuta la permutación específica que utiliza el algoritmo de cifrado, esencial para la seguridad del sistema. La interfaz está compuesta por distintos tipos de señales: • Buses de Datos: como dataIn y dataOut, que manejan la transferencia de los datos cifrados y a cifrar. Ambos de 32 bits. • Señales de Control: que incluyen keyUpdate, dValid, dEob, dEop, init, partial, partialBits y decryptIn, que controlan el proceso de carga de datos y la realización del proceso de cifrado/descifrado. • Señales de Indicación: como outValid, authValid y dReady, que ofrecen información sobre el estado y la validez de los datos procesados. El bus de entrada tiene un ancho de 32 bits, pero según el algoritmo, los datos se tienen que procesar en bloques de 64 bits. Esto implica que los datos son introducidos en dos ciclos de reloj, con una adaptación específica para bloques parciales. 3.1.2 Operación del Cifrador El sistema con reset asíncrono activo en alto que pone al diseño en un estado de espera de inicio de una operación. En este estado se pueden realizar tres operaciones mostrados en la tabla 8: • Carga de la Clave: Se activa mediante la señal keyUpdate, con una prioridad superior que permite su preeminencia sobre otras señales. • Inicio del Cifrado/Descifrado: Señales como init y decryptIn dictan el comienzo y la naturaleza de la operación a ejecutar. • Inicio de la generación de un Hash: La señal hash_signal marca el inicio de esta operación, para la que sólo se necesitan los datos para los que generara el hash. - 45 - INIT KEY_UPDATE HASH_SIGNAL ESTADO 0 0 0 N/A - 1 - LOAD_KEY 1 0 0 CIFRADO/DESCIFRADO 1 0 1 HASH 0 0 1 N/A Tabla 8. Señales para inicialización. Nos centramos ahora en el proceso de cifrado y descifrado. El modo hash se verá más adelante. La inclusión de un Nonce y la gestión de bloques de datos (asociados, texto plano/cifrado, y tag) se realizan a través de un esquema detallado que abarca la carga de datos, la señalización precisa para el procesamiento de bloques completos o parciales, y la finalización adecuada del proceso de cifrado o descifrado. Iniciamos el proceso con una señal de activación que prepara el sistema para las operaciones de cifrado o descifrado. Esta activación se señala mediante las entradas init y decryptIn, que marcan el inicio de la operación y definen su naturaleza, respectivamente. La operación comienza oficialmente cuando init se pone a “1”, momento en el cual el sistema está listo para recibir el Nonce a través del bus de entrada, marcando este dato como válido con la señal dValid. 3.1.3 Carga de la Clave La carga de la clave se activa cuando el cifrador está en estado de espera y el valor de la entrada keyUpdate cambia a '1'. Es importante destacar que esta señal tiene mayor prioridad que la señal init. Por lo tanto, si ambas señales (keyUpdate e init) están en '1' simultáneamente, se procederá a cargar la clave en lugar de iniciar el proceso de cifrado/descifrado indicado por la señal decryptIn. El proceso de carga de la clave, ilustrado en la Figura 3.6, consiste en introducir, mediante el bus de entrada Data_In, cuatro palabras de 32 bits que constituyen los 128 bits de la clave que se usará durante la operación del cifrador. Estas palabras deben asignarse al bus de entrada durante los 4 ciclos de reloj que dura GONZÁLEZ VILLALBA, DAVID - 46 - el periodo de carga tras la señal keyUpdate comenzando por los 32 bits más significativos. 3.1.4 Carga del nonce La carga del nonce se realiza de forma similar a la carga de la clave, actualizando el bus de entrada con las porciones del Nonce en los siguientes cuatro ciclos de reloj tras recibir la señal init, comenzando también por los 32 bits más significativos. Posteriormente, el sistema está listo para procesar el siguiente bloque de datos, cuya naturaleza se determina por las señales dEob y dEop. El cifrador maneja varios tipos de bloques de datos en un orden específico, utilizando principalmente señales de control como dEob, dEop, partial, y partialBits para el procesamiento como podemos ver en la tabla 9. Tabla 9. Próximo bloque a procesar según dEop y dEob al finalizar el nonce 3.1.5 Procesamiento del Dato Asociado El procesamiento del Dato Asociado comienza inmediatamente después de la carga del Nonce. La continuidad del proceso depende de la señal dReady, que indica cuándo se puede actualizar el bus de entrada con las siguientes palabras del Dato Asociado. Como el procesado se hace en bloques de 64 bits, pero el bus de entrada del ASCON es de 32 bits, se preparan los 64 bits, introduciendo primero los 32 bits menos significativos y después los 32 más significativos. En el último bloque de datos hay que poner, en el caso de sea un bloque parcial la entrada partial = “1” y el valor del parcial según la tabla 10. DEob dEop Próximo bloque a tratar 0 0 Dato asociado 0 1 Texto plano/cifrado 1 - Tag DEob dEop Próximo bloque a tratar 0 0 Dato asociado 0 1 Texto plano/cifrado 1 1 Tag - 47 - Tabla 10. Próximo bloque a procesar según dEop y dEob al finalizar el dato asociado. 3.1.6 Procesamiento del Texto Plano/Cifrado Similar al Dato Asociado, el procesamiento de Texto Plano/Cifrado sigue la misma metodología, con la diferencia en la gestión de las señales dEob y dEop al final del bloque, ya que este puede ser el último bloque opcional antes del Tag. La señal outValid se activa para indicar que el bus de salida contiene el resultado del proceso de cifrado o descifrado. Se muestra en la tabla 11. Tabla 11. Próximo bloque a procesar según dEop y dEob al finalizar el texto plano/cifrado 3.1.7 Proceso de Finalización La operación termina con la generación o verificación del Tag, según se esté cifrando o descifrando. Este paso es diferente en el descifrado, ya que requiere la asignación del Tag al bus de entrada, similar a cómo se manejan el Dato Asociado y el Texto Plano/Cifrado. La señal authValid se utiliza para confirmar la validez del descifrado. 3.1.8 Procesamiento de Bloques Parciales Una característica notable del sistema es su capacidad para manejar bloques parciales, es decir, aquellos cuyo último componente tiene un tamaño inferior a 64 bits. En estos casos, las señales partial y partialBits se ajustan para indicar la presencia y el tamaño de estos bloques parciales( ver tabla 12), asegurando un tratamiento adecuado durante el ciclo de reloj correspondiente. DEob dEop Próximo bloque a tratar 0 0 Texto plano/cifrado 1 0 Tag GONZÁLEZ VILLALBA, DAVID - 48 - Tabla 12. Valores de Partial y Partil_Bits en función del tamaño del último bloque. 3.2 Diseño Hardware ASCON En este apartado nos adentraremos en el núcleo principal del trabajo: el diseño del cifrador ASCON mediante VHDL. Este apartado del trabajo se centra en detallar el diseño realizado, el cual se ha abordado a través de una máquina de estados finitos diseñada específicamente para optimizar y ejecutar el proceso de cifrado de manera eficaz, eficiente y fácil de analizar. En este apartado se aborda la implementación de ASCON-128, una versión específica del algoritmo ASCON. Es importante señalar que esta discusión se limita a las capacidades de cifrado y descifrado de ASCON-128, dejando de lado las funcionalidades relacionadas con la generación de Hash, las cuales se detallan en el siguiente apartado. Tamaño del último bloque (Bits) Partial Partial_Bits 64 0 000 56 1 001 48 1 010 40 1 011 32 1 100 24 1 101 16 1 110 8 1 111 - 49 - Figura 10. Diagrama de flujo ASCON GONZÁLEZ VILLALBA, DAVID - 50 - El diagrama de flujo mostrado en la Figura 10 ilustra de manera visual el funcionamiento detallado del cifrador. A continuación, se ofrece una descripción general de las principales etapas representadas en el diagrama donde más adelante se verán detalladamente cada etapa: Inicio y carga de clave: • El proceso comienza en el estado "Waiting", esperando una señal de actualización de clave (key_update = 1). • Una vez recibida la señal, se carga una clave dentro del estado "LOAD_KEY", utilizando data_in para recibir la clave. Después de cargar la clave, el proceso vuelve al estado inicial "Waiting". Inicialización con nonce: • Cuando estando en el estado “Waiting” se activa la señal Init, se pasa al proceso de absorver un nonce (un valor que se utiliza una única vez) mediante "Absorb_nonce". El nonce se recibe también a través de data_in. • Tras recibir el nonce, el algoritmo ejecuta una serie de permutaciones iniciales en el estado "Ini" para configurar el sistema. Absorción de datos asociados: • La absorción de datos asociados se maneja en múltiples estados, comenzando con "Absorb_Ad", que recibe un bloque de datos asociados. • Dependiendo de los bits de fin de absorción de datos (DEOB) y de operación de dominio (DEOP), el flujo puede seguir diferentes caminos: o Si ambos bits son cero, se absorben bloques adicionales en "Absorb_Ad_2". o Si DEOB es “1”, se procesa el último bloque de datos asociados en "Partial_Ad". o Se aplican permutaciones y rellenos en "Pad_Ad" y "Process_Pad" según sea necesario. • Un bit de separación de dominio se gestiona en "Domain_Ad". Absorción y Procesamiento del Mensaje: • Los bloques de mensaje para cifrar o descifrar se reciben en "Absorb_Pt". • Si el bloque no es el último (DEOB = 0 y DEOP = 0), el flujo continúa en "Absorb_Pt_2", donde se completan operaciones adicionales. - 51 - • Si es el último bloque (DEOB = 1), se procesa en "Partial_Pt". • Los bloques cifrados o descifrados se emiten en "Emit_Pt". Relleno y Operaciones con la Clave: • Los bloques de mensaje se procesan con permutaciones en "Process_Pt". • Se aplica un relleno en "Pad_Pt" y operaciones adicionales con la clave en "Add_key_1". Generación y Verificación del TAG: • En la fase final, se generan y verifican los TAGs (etiquetas) para garantizar la integridad del mensaje. • Si el modo es cifrar, se emite el TAG en "Emit_Tag". • Si el modo es descifrar, se verifica el TAG recibido en "Verify_Tag". • Finalmente, el proceso retorna al estado "Waiting". En el diseño del cifrador, se han detallado las señales de entrada y salida mostradas en la tabla 13 que rigen las operaciones fundamentales de cifrado y descifrado. Sin embargo, para comprender el mecanismo interno y la eficiencia del sistema, es esencial entender también las señales intermedias. Estas señales juegan un papel crítico en facilitar las transiciones de estado, controlar los procesos de permutación, y gestionar los datos de entrada y salida a lo largo del ciclo de cifrado. A continuación, se presenta una descripción detallada de estas señales intermedias. Variable /Señal Tipo / Tamaño (Bits) Descripción estado tipo_estado Mantiene el estado actual del cifrador. estado_siguiente tipo_estado Determina el próximo estado al que transitará el sistema. estado_anterior tipo_estado Almacena el estado anterior para referencias de flujo de control. modo tipo_cifrado Indica si el sistema está cifrando o descifrando. GONZÁLEZ VILLALBA, DAVID - 58 - a) Si falta 1 byte:  reg_state (63 downto 0) <= reg_state (63 downto 0) XOR ("10000000" & data_in_64(55 downto 0))  reg_state (63-8*1 downto 0) <= data_in_64(63- 8*1 downto 0)  data_out_64 <= (others => '0')  data_out_64(63-8*1 downto 0) <= reg_state (63- 8*1 downto 0) XOR data_in_64(63-8*1 downto 0) b) Si faltan 2 bytes:  reg_state (63 downto 0) <= reg_state (63 downto 0) XOR (x"00" & "10000000" & data_in_64(47 downto 0))  reg_state (63-8*2 downto 0) <= data_in_64(63- 8*2 downto 0)  data_out_64 <= (others => '0')  data_out_64(63-8*2 downto 0) <= reg_state (63- 8*2 downto 0) XOR data_in_64(63-8*2 downto 0) c) Si faltan 3 bytes:  reg_state (63 downto 0) <= reg_state (63 downto 0) XOR (x"0000" & "10000000" & data_in_64(39 downto 0))  reg_state (63-8*3 downto 0) <= data_in_64(63- 8*3 downto 0)  data_out_64 <= (others => '0')  data_out_64(63-8*3 downto 0) <= reg_state (63- 8*3 downto 0) XOR data_in_64(63-8*3 downto 0) d) Y así sucesivamente dependiendo de cuantos bytes falten. e) Emitir el dato descifrado en bloques de 32 bits por data_out:  Primer ciclo de reloj: data_out <= data_out_64(31 downto 0)  Segundo ciclo de reloj: data_out <= data_out_64(63 downto 32) - 59 - f) Pasar a generar el TAG. Generar tag • Aplicar XOR entre reg_state (191 downto 64) y key: reg_state (191 downto 64) <= reg_state (191 downto 64) XOR key • Realizar 12 rondas de permutaciones en reg_state. • Aplicar XOR entre reg_state (127 downto 0) y key: reg_state (127 downto 0) <= reg_state (319 downto 192) XOR key (127 downto 0) • Si estamos en proceso de cifrar: a) Primer ciclo: data_out <= reg_state (31 downto 0) b) Segundo ciclo: data_out <= reg_state (63 downto 32) c) Tercer ciclo: data_out <= reg_state (95 downto 64) d) Cuarto ciclo: data_out <= reg_state (127 downto 96) • Si estamos en proceso de descifrar, antes de generar el TAG se comprueba que por el bus de entrada el Tag coincide con el generado. a) Primer ciclo: if data_in = reg_state (31 downto 0) then data_out <= reg_state (31 downto 0); else generar error b) Segundo ciclo: if data_in = reg_state (63 downto 32) then data_out <= reg_state (63 downto 32); else generar error c) Tercer ciclo: if data_in = reg_state (95 downto 64) then data_out <= reg_state (95 downto 64); else generar error d) Cuarto ciclo: GONZÁLEZ VILLALBA, DAVID - 60 - if data_in = reg_state (127 downto 96) then data_out <= reg_state (127 downto 96); else generar error 3.2.2 Funcionamiento detallado de cada estado del cifrador En este apartado, se ofrece una explicación exhaustiva de cada estado del algoritmo de cifrado, con un enfoque en las operaciones específicas y las transiciones que ocurren a lo largo del proceso. Se examina cómo el sistema gestiona las señales y los datos en cada etapa, abarcando desde la espera inicial hasta la generación y verificación del TAG. Waiting Este es el estado inicial, donde se determina la acción que va a ocurrir. Al reiniciar algunas señales a '0', se prepara para cualquier operación nueva. Dos eventos principales pueden sacar al sistema de este estado: la señal Key_Update activada a '1', que mueve al sistema al estado load_Key para la carga de una nueva clave, indicando así la necesidad de una actualización de clave; o la señal init activada a '1', sin requerir actualización de clave, lo que lleva al sistema al estado Absorb_Nonce para comenzar la absorción del Nonce, marcando el comienzo del proceso de cifrado o descifrado según lo determinado por la señal descryptIn, la cual se activa a la vez que init. Load_Key En este estado se carga la clave en el cifrador. Primero verifica el contador para determinar si aún hay partes de la clave (Key) que cargar con los datos entrantes (data_in). Concatena data_in con la clave existente, decrementando el contador después de cada operación. Cuando el contador llega a 0, indicando que la clave está completamente cargada (4 ciclos de reloj), desactiva dReady y, si init es '1', reinicia el contador a "100" y cambia el estado a Absorb_Nonce para comenzar la absorción del Nonce, ajustando también el modo de operación (cifrar o descifrar) según descryptIn. Absorb_nonce En este estado, el sistema se prepara para absorber el Nonce, activando la señal dReady para indicar que está listo para recibir datos. Si d_valid es '1', indicando que hay datos válidos para procesar, el sistema verifica si el contador aún es mayor a 0 para incorporar estos datos en el segmento específico de reg_state. La lógica decrementa el contador después de cada absorción de datos. Este proceso lo hace durante 4 ciclos de reloj que son los 128 bits del Nonce. - 61 - Cuando el contador llega a "001”, equivalente al último bloque, el sistema evalúa las señales dEob (end of block) y dEop (end of packet) para determinar el flujo siguiente del proceso: • Si dEob es '0' y dEop es '0', el estado_siguiente se establece en absorb_Ad, preparándose para absorber datos asociados. • Si dEob es '0' y dEop es '1', el estado_siguiente se establece en Domain_Ad, con estado_anterior configurado a Absorb_pT para indicar de dónde viene la transición. • Si dEob es '1’, el estado_anterior se establece igualmente en Domain_Ad, pero con estado_anterior ajustado a Add_Key_1, reflejando un tratamiento diferente del bloque de datos. El contador se reinicia a "010" para un nuevo ciclo de procesamiento, la señal dReady se desactiva, y se inicia una preparación de estado con estado cambiando a Ini.. Una vez absorbido el Nonce ya podremos a proceder a la incialización del cifrador. El reg_state será nuestro registro principal, que se usará para las permutaciones, incialización, finalización y posibles operaciones de procesado. Habiendo absorbido previamente la clave, reg_state se configurará de la siguiente forma: • reg_state(191 downto 64) almacenará la clave (key). • reg_state(63 downto 0) contendrá el IV. • reg_state(319 downto 192) se asignará al Nonce. INI Se realizan las permutaciones necesarias utilizando la instancia Inst_ASCONp del módulo ASCONp, que afecta a reg_state según el contador de rondas, en este caso será 12 rondas. Cada permutación mezcla los datos de forma segura, con el resultado actualizándose en reg_state. Esta instancia se configura con una asociación de puertos que incluye: • state_in: La entrada del estado actual reg_state, que se somete a la permutación. • rcon: Un contador de rondas utilizado para controlar el proceso de permutación. • state_out: La salida del estado permutado reg_permu_out, que refleja el resultado de aplicar la permutación al estado de entrada. Después se realiza una operación XOR entre una sección de reg_state y la clave key, como un paso final en el proceso de inicialización. Luego, se reinicia el GONZÁLEZ VILLALBA, DAVID - 62 - contador a "010", preparando el sistema para el próximo estado, y se transita al estado_siguiente determinado previamente. Absorb_Ad En este estado se absorbe los datos asociados (AD) y los prepara para permutaciones subsiguientes. Se activa la señal dReady para indicar que el sistema está listo para recibir datos. Si d_valid es 1, mostrando que hay datos válidos para procesar, y el contador es mayor a 0, se forma un bloque de 64 bits concatenando el dato entrante con una parte de data_in_64. Luego, se decrementa el contador. Al llegar el contador a “001”, se evalúan las señales dEob y dEop para determinar el próximo paso: Actualización de estado_anterior: • Si dEob y dEop son 1, indicando el último bloque de datos, se ajusta estado_anterior a Add_Key_1. • Si dEob es 1 y dEop es 0, se configura estado_anterior a Absorb_pT. Actualización de estado: • Si partial y dEob son 1, indicando un bloque final parcial, el estado cambia a partial_AD, se desactiva dReady, y se asigna a partialBits_signal el valor de partialBits que nos dirá cuál es el tamaño del bloque parcial. • Si partial es 0 y dEob es 1, mostrando un bloque completo y siendo el último, se establece partialBits_signal a 000 y se cambia al estado partial_AD, desactivando también dReady. En otros casos, el proceso continúa en Absorb_Ad_2 para más tratamiento de datos antes de las permutaciones. Absorb_Ad_2 Al no ser el último bloque de datos asociados se finaliza la absorción del bloque y se prepara para el procesamiento de éstos mediante la desactivación de la señal dReady. Se establece el número de rondas a Rounds_B, (6 rondas). Luego, se realiza una operación XOR entre los últimos 64 bits de reg_state y data_in_64, integrando así los datos recibidos en el estado del registro. Finalmente, se actualiza estado a Process_Ad. Partial_AD Este estado se ocupa del procesamiento del bloque de datos asociados (AD) que es parcial o completo, pero necesita ser rellenado antes de las - 63 - permutaciones. Dependiendo del valor de partialBits_signal, que indica cuánto del bloque está lleno, se realiza una operación XOR específica para mezclar los datos entrantes con el estado actual de reg_state, y se ajusta el relleno necesario según el caso: • "000": Se aplica directamente un XOR entre reg_state(63 downto 0) y data_in_64, sin necesidad de relleno adicional y se guardará en reg_state. Luego, se actualiza el estado a Pad_Ad. • "001" a "111": En estos casos, se ajusta el relleno según la cantidad de bits efectivamente usados en data_in_64, desde"001" en adelante, se añade un relleno progresivo: "001" conlleva añadir un prefijo de 8 bits (x"80") seguido del dato de entrada reducido en 8 bits, "010" implica añadir un prefijo de 8 ceros y x"80" seguido del dato de entrada menos 16 bits, y así sucesivamente. Esta estrategia asegura que cada bloque parcial se procese de manera consistente, extendiendo el dato con un bit de parada (x"80") y ceros necesarios para completar el bloque antes de aplicar la operación XOR, garantizando la integridad y la correcta alineación de los datos en el reg_state. Un ejemplo para el caso “011” (24 bits de relleno ): reg (63 a 0) <= reg (63 a 0) xor (x"0000" & "10000000" & data_in_64(39 a 0)) En todos los casos, se establece el número de rondas a Rounds_B (6 rondas), y se cambia el estado a Process_Pad o Pad_Ad, dependiendo de si el bloque es parcial o completo. Process_Ad En este estado, después de realizar las permutaciones necesarias con Inst_ASCONp para el procesamiento de un bloque de datos asociados, se vuelve a actualizar el estado a Absorb_Ad para comenzar a procesar el siguiente bloque de datos asociados, si lo hubiere. Activa la señal dReady a '1', indicando que el sistema está listo para recibir más datos asociados. También reinicia el contador a "010", preparando el sistema para procesar el nuevo bloque de datos asociados. Pad_Ad En este estado, después de realizar las permutaciones necesarias con Inst_ASCONp para el procesamiento de relleno del dato asociado, se vuelve a actualizar el estado a Process_Ad, Además, realiza una operación XOR entre los 8 bits más bajos de reg_state y x"80", introduciendo así un bit de relleno específico al final del estado del registro. El contador de rondas se reinicia a GONZÁLEZ VILLALBA, DAVID - 64 - Rounds_B (6 rondas), preparando el sistema para la próxima fase de permutaciones. Process_Pad En este estado, después de volver a realizar las permutaciones necesarias con Inst_ASCONp para el procesamiento de relleno del dato asociado sobre el registro que ahora incluye tanto los datos asociados (AD) como el relleno específico, se actualiza el estado a Domain_Ad. Domain_Ad En este estado se finaliza el procesamiento del paquete de datos asociados (AD) aplicando una operación XOR en el bit 312 de reg_state con '1', marcando así el bloque con información de dominio específica para diferenciarlo claramente. Tras esta marcación, reinicia el contador a "010" y decide el próximo estado basándose en estado_anterior: si era Absorb_Pt, el estado pasa a absorb_pt para continuar el procesamiento de la parte del texto plano/cifrado; de lo contrario, si no hay texto plano o cifrado avanza hacia Pad_Pt, preparándose para realizar un padding adicional antes de proceder a la generación del tag de autenticación. Absorb_Pt Se prepara para recibir el texto plano o cifrado, activando la señal dReady para indicar que está listo para procesar los datos entrantes. Cuando detecta datos válidos d_valid = '1', comienza a absorberlos, concatenando el dato entrante data_in con el contenido previo de data_in_64 para formar bloques de 64 bits, y decrementa el contador que lleva la cuenta de cuántos bloques o segmentos de datos faltan por procesar. Al llegar el contador a “001”, se evalúan las señales dEob y dEop para determinar el próximo paso: • Si es el último bloque y no es el fin del paquete dEob = '1' y dEop = '0', se prepara para pasar al estado ADD_key_1, indicando que se necesita añadir la clave nuevamente para continuar con el procesamiento del cifrado o descifrado. • Si el último bloque es parcial partial = '1', el sistema se dirige al estado partial_Pt para manejar este último segmento de datos parciales, asignando a partialBits_signal el valor actual de partialBits para procesar adecuadamente la cantidad de datos válidos restantes. • En caso de que el último bloque esté completo (partial = '0'), el sistema también transita a partial_Pt, pero se asume que no hay datos válidos - 65 - restantes partialBits_signal = "000", preparándose para aplicar un relleno estándar antes de continuar. • Si no se cumplen las condiciones anteriores, es decir, aún hay más datos por procesar, el sistema pasa al estado Absorb_Pt_2 para seguir absorbiendo y procesando el texto. Absorb_Pt_2 Al no ser el último bloque de datos se finaliza la absorción del bloque y se prepara para el procesamiento de éstos mediante la desactivación de la señal dReady. Se establece el número de rondas a Rounds_B, (6 rondas), preparando el sistema para una serie de permutaciones que se aplicarán antes de emitir el texto procesado. El sistema transita al estado Emit_Pt, donde se manejarán los datos procesados para su salida, y se actualiza estado_anterior a Absorb_Pt. Antes de proceder al estado Emit_Pt se realizan una serie de operaciones según sea, cifrar o descifrar: • Si el modo es cifrar, realiza una operación XOR entre el segmento de 64 bits menos significativo de reg_state y data_in_64, actualizando tanto reg_state como data_out_64 con el resultado. Esto mezcla los datos de entrada con el estado actual del sistema antes de su emisión, cifrando efectivamente el texto plano. • Si el modo es descifrar, asigna directamente data_in_64 al segmento de 64 bits menos significativo de reg_state y luego establece data_out_64 como el resultado de una operación XOR entre reg_state y data_in_64. Este paso revierte el cifrado, recuperando el texto plano original a partir del texto cifrado. Partial_Pt Este estado se ocupa del procesamiento del bloque de datos que es parcial o completo, pero necesita ser rellenado antes de las permutaciones. Dependiendo del valor de partialBits_signal, que indica cuánto del bloque está lleno, se realiza una operación XOR específica para mezclar los datos entrantes con el estado actual de reg_state, y se ajusta el relleno necesario según el caso. Primero, desactiva la señal dReady, indicando que no está listo para recibir más datos. Luego, según si el modo es descifrar o cifrar, el sistema procede de manera diferente: Descifrar Dependiendo del valor de partialBits_signal se realiza una de las siguientes operaciones: GONZÁLEZ VILLALBA, DAVID - 66 - • "000": Asigna directamente data_in_64 al segmento de 64 bits más bajo de reg_state. Tambien realiza una operación XOR entre el segmento de 64 bits más bajo de reg_state y data_in_64, actualizando data_out_64. Tras procesar, el estado cambia a Emit_Pt también actualiza estado_anterior a Pad_Pt. • "001" a "111": En estos casos, se ajusta el relleno según la cantidad de bits efectivamente usados en data_in_64, desde"001" en adelante, se añade un relleno progresivo: "001" conlleva añadir un prefijo de 8 bits (x"80") seguido del dato de entrada reducido en 8 bits, "010" implica añadir un prefijo de 8 ceros y x"80" seguido del dato de entrada menos 16 bits, y así sucesivamente. Un ejemplo para el caso “011” (24 bits de relleno): reg (63 a 0) <= reg (63 a 0) xor (x"0000" & "10000000" & data_in_64(39 a 0)) Se realiza la operación XOR entre reg_state y data_in_64, ajustando data_out_64 para contener solo la porción válida de los datos descifrados. Un ejemplo para el caso “100” (32 bits de relleno ): data_out_64(63 -8*4 a 0) <=reg_state (63-8*4 a 0) XOR data_in_64(63-8*4 a 0) Tras procesar, el estado cambia a Emit_Pt para emitir el texto descifrado. También actualiza estado_anterior a Partial_Pt. Cifrar Dependiendo del valor de partialBits_signal se realiza una de las siguientes operaciones: • "000": Realiza una operación XOR entre el segmento de 64 bits más bajo de reg_state y data_in_64, actualizando data_out_64 y reg_state. • Tras procesar, el estado cambia a Emit_Pt también actualiza estado_anterior a Pad_Pt. • "001" a "111": En estos casos, se ajusta el relleno según la cantidad de bits efectivamente usados en data_in_64, desde"001" en adelante, se añade un relleno progresivo: "001" conlleva añadir un prefijo de 8 bits (x"80") seguido del dato de entrada reducido en 8 bits, "010" implica añadir un prefijo de 8 ceros y x"80" seguido del dato de entrada menos 16 bits, y así sucesivamente. - 67 - Un ejemplo para el caso “011” (24 bits de relleno): reg (63 a 0) = reg (63 a 0) xor (x"0000" & "10000000" & data_in_64(39 a 0)) Se realiza la operación XOR entre reg_state y data_in_64, ajustando data_out_64 para contener solo la porción válida de los datos descifrados. Un ejemplo para el caso “011” (24 bits de relleno): data_out_64(63 -8*3 a 0) =reg_state (63-8*3 a 0) XOR data_in_64(63-8*3 a 0) Tras procesar, el estado cambia a Emit_Pt para emitir el texto descifrado. También actualiza estado_anterior a Partial_Pt. Emit_Pt En este estado se emite el texto procesado, ya sea cifrado o descifrado. Se activa la señal outValid para indicar que los datos de salida son válidos y están listos para ser transmitidos o almacenados. Aquí, se utiliza una lógica de alternancia (toggle) para determinar qué parte del bloque de 64 bits (data_out_64) se envía en cada ciclo: • Si toggle está en '0', se emiten los 32 bits inferiores de data_out_64 y luego toggle se cambia a '1', preparándose para emitir la siguiente mitad del bloque en el próximo ciclo. • Si toggle está en '1', se emiten los 32 bits superiores de data_out_64 y toggle se reinicia a '0', completando la emisión del bloque de 64 bits actual. Después de emitir la parte correspondiente de data_out_64, el sistema decide el próximo estado basándose en cuál fue el estado anterior: • Si viene del estado Absorb_Pt, se transita a Process_Pt para continuar procesando más texto plano o cifrado. • Si el estado anterior fue Pad_Pt, indica que se estaba procesando padding, por lo que el sistema regresa a Pad_Pt • Si el estado anterior fue Partial_Pt, significa que se ha completado el procesamiento de un bloque parcial, y el sistema avanza a Add_Key_1 para añadir la clave de cifrado y seguir con el proceso de finalización. Process_Pt En este estado, después de realizar las permutaciones necesarias con Inst_ASCONp para las operaciones del procesamiento del texto plano/cifrado, se desactiva la señal outValid, se vuelve a actualizar el estado a Absorb_Pt para retomar la fase de absorción de más texto plano o cifrado, señala que está listo para recibir más datos activando la señal dReady a “1”, y reinicia el contador a "010", preparándose así para el procesamiento del siguiente bloque de datos. GONZÁLEZ VILLALBA, DAVID - 74 - 2. Inicialización • Tras un ciclo de espera, se activan las señales init y descryptIn en '1' para iniciar el proceso de descifrado, restableciéndose en '0' en el siguiente ciclo. 3. Cargar el Nonce • Se espera a que dReady esté en '1' para indicar que el sistema está listo para recibir el nonce. • Se activa d_valid y se cargan los 4 bloques de 64 bits del Nonce, desactivando d_valid después del último bloque. 4. Cargar datos asociados (AD) • Similar al nonce, se espera a que dReady esté en '1'. • Se activa d_valid, se cargan los datos asociados y se marca el final del bloque con dEob en '1', luego d_valid se desactiva. 5. Cargar el texto cifrado (CT) o texto plano (PT) • Se cargan los distintos bloques de datos a cifrar o descifrar, asegurándose que dReady esté en '1', activando d_valid y desactivándolo tras marcar el final del bloque con dEob. 6. Verificar TAG o Emit Tag: • Cuando authValid está en '1', se activa d_valid para cargar la etiqueta de autenticación (TAG), desactivándolo después del último bloque. 4.1.2 Desafíos del enfoque inicial Al implementar este enfoque manual, se encontraron varios problemas: 1. Tediosidad y margen de error • Especificar manualmente cada señal en el momento exacto era tedioso y propenso a errores, lo que incrementaba el tiempo de prueba y la posibilidad de fallos. 2. Visibilidad y depuración • La depuración se dificultaba debido a la gestión manual de cada aspecto del test, haciendo complicada la identificación de problemas específicos y prolongando las sesiones de depuración sin garantías de una solución rápida. - 75 - 3. Rigidez y escalabilidad • La rigidez del método limita la capacidad de adaptar o escalar el test bench, ya que cada ajuste requería una revisión completa de los ciclos de reloj y señales involucradas. 4. Comunicación Limitada • Explicar la configuración específica de las señales a colaboradores, como el tutor, resultaba complejo y propenso a malentendidos o errores de interpretación. 5. Falta de Automatización • La falta de automatización impedía realizar pruebas exhaustivas de manera eficiente, limitando la profundidad y amplitud de las pruebas. Tras completar el diseño del cifrador, se elaboró un test bench considerablemente más automatizado, recurriendo a un conjunto de funciones y procedimientos diseñados para optimizar el flujo de trabajo. 4.2 Test Bench inicial ASCON-Hash Tras detallar el funcionamiento del test bench general para el cifrador ASCON- 128, a continuación, se describe una variante específica de este test bench, realizada para probar el ASCON_Hash. Esta versión se centra exclusivamente en la generación de hash a partir de los datos de entrada, siguiendo un proceso que, aunque similar en estructura al descrito previamente, posee características únicas adaptadas para el manejo de hashes. Este test bench simplifica algunas de las operaciones mientras se enfoca en la eficiencia y precisión del cálculo de hashes. Descripción del Test Bench ASCON_Hash: El funcionamiento del test bench para ASCON_Hash es esencialmente idéntico al del cifrador general, pero con un enfoque exclusivo en la manipulación y procesamiento de hashes. El proceso se inicia con la activación de la señal Hash_Signal y la señal Init, que preparan el sistema para recibir datos y comenzar el proceso de hashing. A continuación, los datos son introducidos secuencialmente en bloques específicos, con cada bloque procesado durante un ciclo de reloj determinado. Inicio del Proceso: Hash_Signal y Init se establecen en '1' para indicar el comienzo del hashing. Se espera un ciclo de reloj para que las configuraciones tomen efecto. GONZÁLEZ VILLALBA, DAVID - 76 - Carga de Datos: Los datos se cargan en el sistema mediante la señal data_in, mientras que d_valid se activa para indicar que los datos son válidos. Cada bloque de datos es procesado en su respectivo ciclo de reloj, seguido por la desactivación temporal de d_valid para preparar el siguiente bloque. Finalización y Generación de Hash: Una vez todos los datos han sido introducidos, se manejan las señales de fin de operación (dEob y partial) para asegurar que el sistema procese correctamente el último bloque. El proceso concluye con una espera final durante el cual el hash es calculado y almacenado. Este test bench específico para ASCON_Hash permite realizar pruebas de hashing de manera efectiva, asegurando que el algoritmo funcione correctamente bajo diversas condiciones de entrada y generando el TAG correspondiente solo cuando se procesa la totalidad de los datos. 4.3 Test Bench final ASCON-128 Este enfoque se basó en la utilización de fichero de texto, que contenía un compendio de todas las pruebas a realizar, así como sus respectivos resultados. De manera meticulosa, se examinaba cada dato del cifrador (clave, Nonce, datos asociados, texto cifrado/plano y etiqueta de autenticación), extrayendo y almacenando la información relevante en variables. Este proceso permite manipular los datos de forma automatizada, facilitando la evaluación de aspectos cruciales como los tamaños de los datos y la cantidad de bloques enviados y recibidos. Una vez almacenadas todas las variables y usando los procedimientos, el sistema podía ejecutar de manera autónoma el cifrado y descifrado para cada conjunto de prueba, verificando los resultados automáticamente. Este avance cambió completamente la forma en que se realizaban las pruebas, permitiendo no solo hacerlas más rápido sino también con mayor precisión al encontrar y arreglar fallos. Con la automatización, se pudo profundizar más en el análisis, lo que realmente mejoró la eficiencia y efectividad al probar el cifrador. Para comprender mejor cómo opera este test bench y la lógica detrás de su construcción, aquí se explica paso a paso sus componentes y la función que cumplen dentro del proceso de prueba. Primero se explicarán algunos componentes iniciales. Estos incluyen archivos para el manejo de estímulos y resultados, señales específicas para representar - 77 - diferentes tipos de datos, y una variedad de funciones y procedimientos diseñados para automatizar y facilitar el proceso de pruebas. 4.3.1 Estructura Archivos de estímulo y resultados Se emplean dos archivos principales: datos.txt y resultados.txt. El archivo datos.txt se utiliza para leer los datos de prueba, mientras que resultados.txt sirve para registrar los resultados obtenidos de las pruebas. El archivo datos.txt se estructura siguiendo un formato específico que incluye los vectores de prueba, que son esenciales para verificar la correcta funcionalidad del cifrador. Estos vectores de prueba contienen una variedad de datos de entrada, como claves, nonces, mensajes de texto plano y los correspondientes textos cifrados y etiquetas de autenticación (TAG) valores de Hash y etiquetas de autenticación del Hash mostrados en la figura 12. Estos vectores son cruciales para evaluar tanto la seguridad como la eficiencia del cifrador bajo diferentes condiciones y tipos de datos. El contenido específico de estos vectores de prueba proviene del archivo test_vectors.txt, disponible en la versión v1 del repositorio de GitHub de ASCON [13]. Figura 12.Captura parcial del archivo de texto "test_vectors" GONZÁLEZ VILLALBA, DAVID - 78 - Señales Se definen varias señales, como key,tag,Nonce,ad (datos asociados), `pt` (texto plano), y `ct` (texto cifrado), junto con sus tamaños correspondientes para poder guardarlas. A continuación, se detallan las funciones y procedimientos diseñados específicamente para manipular y procesar estas señales dentro del test bench. Cada función y procedimiento tiene un rol específico en la preparación y envío de los datos. Funciones definidas Una función actúa como una herramienta especializada que procesa datos de entrada y siempre retorna un resultado específico, sin modificar señales externas; es ideal para realizar cálculos u operaciones repetitivas donde se requiere un resultado directo y claro. • Función reverse_byte: Esta función invierte los bytes de un vector lógico, asegurando que los datos se procesen en el formato correcto (little/big endian), es necesario para la coherencia entre los datos de prueba y cómo los interpreta el cifrador. • Función hex_to_slv: Convierte una cadena hexadecimal a un vector lógico estándar (std_logic_vector). Se necesita traducir los datos de prueba escritos en formato hexadecimal a un formato que el test bench y el diseño del cifrador puedan manejar directamente. Procedimientos definidos Un procedimiento es un conjunto de instrucciones que ejecuta acciones más complejas dentro del diseño, pudiendo alterar tanto señales internas como externas y no necesariamente retorna un valor; se emplea para ejecutar tareas como configurar registros o manejar secuencias de control, agrupando varias operaciones que influyen en el estado del circuito. Se han definido los siguientes procedimientos: • Procedimiento SEND_KEY: Inicia invirtiendo los bytes de la clave de cifrado mediante la función reverse_byte, adaptando el formato de la clave a las necesidades del cifrador. Divide la clave en 4 bloques de 32 bits y los envía secuencialmente en cada ciclo de reloj, imitando cómo se transmitirían en un escenario real. • Procedimiento SEND_NONCE: - 79 - Similar al procedimiento de la clave, además de invertir y enviar el nonce en 4 bloques de 32 bits, este procedimiento maneja señales adicionales como dEob y dEop, que indican que se va a procesar a continuación si es dato asociado, o texto plano/ texto cifrado. Dependiendo de si existe o no para ese cifrado. • Procedimientos SEND_AD, SEND_PT, y SEND_CT: Estos procedimientos envían los datos asociados, el texto plano, y el texto cifrado, respectivamente. Cada uno toma el respectivo conjunto de datos, lo invierte para alinear con el formato esperado y lo envía en bloques de 32 bits. Durante este proceso, se utilizan señales como d_valid para indicar cuándo los datos son válidos y se deben procesar. Además, se emplean señales como partial, partialBits, dEob y dEop para gestionar particularidades como bloques de datos parciales y marcar el final de los datos, asegurando que el cifrador procese correctamente toda la información. • Procedimiento SEND_TAG: Envía la etiqueta de autenticación al sistema. Al igual que con los otros componentes, la etiqueta se invierte y se envía en segmentos, completando así el ciclo de pruebas al validar que los mensajes descifrados sean auténticos y no hayan sido alterados. • Procedimiento Configuración: Este procedimiento configura cómo se deben tratar los bloques parciales de datos (es decir, los últimos bloques que no llenan completamente un bloque de datos estándar). 4.3.2 Secuencia El código del test bench para el cifrador ASCON se organiza en una serie de pasos secuenciales. A continuación, se detalla cómo se estructura este proceso: Lectura de documento de texto El proceso se inicia con la lectura de un archivo de texto (`datos.txt`), donde se almacenan los datos de prueba, incluyendo las claves, nonces, datos asociados, textos planos y cifrados, y etiquetas de autenticación. Se leen todos los datos relativos a cifrado o descifrado. Análisis y recolección de señales Una vez leído los datos, el siguiente paso es analizar esta información y recoger las señales relevantes. Se extrae cada elemento necesario para el proceso de prueba, como la clave de cifrado, el Nonce, y demás, almacenándolos en GONZÁLEZ VILLALBA, DAVID - 80 - variables adecuadas para su posterior uso. Se leen todos los datos relativos a cifrado o descifrado. Cifrado Con todas las señales preparadas, el proceso continúa con el cifrado del mensaje. Aquí, se simula cómo el cifrador ASCON procesaría los datos, utilizando las claves, nonces, y datos asociados recolectados usando las funciones y procedimientos previamente explicados. Descifrado Después del cifrado, se procede a descifrar el mensaje cifrado para verificar si el proceso ha sido exitoso y coherente, comprobando que el mensaje descifrado coincide con el texto plano original usando las funciones y procedimientos previamente explicados. Preparación para el siguiente mensaje: Una vez completados los pasos de cifrado y descifrado para un conjunto de datos, el test bench se prepara para procesar el siguiente mensaje, repitiendo este ciclo hasta haber evaluado todos los mensajes en el fichero de texto. El diseño implementa estos pasos dentro de un proceso llamado stim_pro`. Este proceso incluye un bucle principal L1 que gestiona el flujo de ejecución para cada caso de prueba. Dentro de este bucle, se utiliza un sub-bucle L2 para leer y procesar cada línea del archivo de estímulo, extrayendo las señales necesarias y asignándolas a las variables correspondientes. Dentro del bucle L2, se encuentra el bucle L3. La función de L3 es leer y procesar cada carácter de la línea actual obtenida por L2. Esto incluye la extracción de los caracteres que conforman los datos de prueba (como la clave, Nonce, etc.) y la preparación de estos datos para su posterior conversión a std_logic_vector. Si la longitud de los datos extraídos no es un múltiplo de 16 caracteres ( que son 64 bits), L3 también se encarga de aplicar el padding necesario. Las señales se procesan y preparan para el cifrado/descifrado mediante una serie de casos (`case`), dependiendo del primer carácter de cada línea leída, que indica el tipo de señal (por ejemplo, clave, Nonce, datos asociados, etc.). Finalmente, el proceso se encarga de cerrar el archivo de resultados una vez completadas todas las pruebas, marcando el fin del test bench. Este enfoque estructurado y secuencial asegura una evaluación detallada y efectiva del cifrador ASCON, facilitando la identificación de cualquier anomalía o comportamiento inesperado en su funcionamiento. - 81 - Con este test bench se pudo comprobar que el ASCON desarrollado, tanto en su versión de cifrado/descifrado como en su versión hash, funcionaban correctamente. 4.4 Analisis de las implementaciones Las simulaciones se han realizado utilizando el programa Xilink ISE versión 14.7, y las implementaciones se han realizado en un dispositivo Artix-7 incorporado en la placaNexys 4 DDR. Esta placa ha sido utilizada en el entorno académico y específicamente seleccionado para este trabajo por estar disponible en la Universidad. Con estos análisis se buscó conocer los recursos consumidos por las implementaciones (en diferentes casos) y también la frecuencia máxima de operación. 4.4.1 Análisis de "Slice Registers" y "Slice LUTs" El código que se ha desarrollado cuenta con una variable llamada “UROL” que permite cambiar el número de permutaciones que se hacen en un ciclo de reloj. Los diferentes valores de esta variable afectan directamente a la complejidad del circuito que realiza las permutaciones y al número de ciclos de reloj que se necesitan para realizar dichas permutaciones, afectando el rendimiento del sistema. En la tabla 14 se muestran las tres configuraciones de la variable UROL que se han utilizado. La configuración v1 realiza las permutaciones de 12 y 6 rondas en 12 y 6 ciclos de reloj, la configuración v3 las realiza en la mitad de los ciclos 6 y 3 ciclos de reloj y por último la configuración v5 las realiza en 3 y 1 ciclos de reloj. Recordamos que el número de permutaciones a realizar varía en función de qué elemento se esté procesando. Estado Ciclos en V1 Ciclos en V3 Ciclos en V5 Ini 12 6 3 Process_Ad 6 3 1 Padding_Ad 6 3 1 Process_Pt 6 3 1 Padding_Pt 6 3 1 Process_Tag 12 6 3 Tabla 14. Ciclos de reloj en cada estado con sus diferentes versiones. GONZÁLEZ VILLALBA, DAVID - 82 - Modelo V1 (12 y 6) V3 (6 y3) V5 (3 y 1) Utilización lógica Usado Utilización Usado Utilización Usado Utilización Número de registros de corte 643 0% 637 0% 639 0% Número de LUTs de corte 2315 3% 3145 5% 4085 6% Número de pares FF completamente LUT 449 17% 446 13% 447 10% Número de IOB vinculados 79 37% 79 37% 79 37% Número de BUFG/BUFGCTRLs 1 3% 1 3% 1 3% Tabla 15. Recursos del sistema con sus diferentes versiones. En la tabla 15 se analizan los recursos consumidos por cada una de las configuraciones. Slice Registers: El número de flip-flops que consumen las tres configuraciones se mantienen casi constantes, con valores muy parecidos en todas ellas. Esto es algo esperado, porque el cambio en el número de permutaciones a realizar en un ciclo sólo afecta a la lógica combinacional y no a la secuencial, por lo tanto, el almacenamiento el almacenamiento de datos y la gestión de estados no experimentan variaciones significativas con los cambios en el número de rondas de permutación, siendo un factor estable en el análisis del rendimiento del cifrador. Slice LUTs: Aquí es donde se observa una diferencia más marcada entre las versiones. Comenzando con la versión v1 que utiliza 2315 LUTs, pasando a la v3 con 3145 LUTs, y finalmente la versión v5 que aumenta el uso hasta 4085 LUTs. Este incremento refleja una mayor complejidad lógica que va en paralelo con la mejora en la eficiencia del procesamiento conforme se reduce el número de ciclos de reloj. La elección de la "mejor" versión depende de las prioridades entre la minimización de la complejidad lógica y la maximización de la eficiencia. Si se prefiere una implementación más sencilla y con menor uso de recursos, la versión v1 sería la adecuada. Por otro lado, si se busca una mayor rapidez en el procesamiento, aceptando un uso más intensivo de recursos, las versiones v3 y especialmente la v5 se presentan como opciones óptimas. La versión v5, en particular, ofrece el mayor rendimiento en términos de velocidad de cifrado y descifrado, a costa de un mayor consumo de recursos lógicos. - 83 - Se ha realizado también una comparación de los recursos consumidos por el ASCON desarrollado en este trabajo, con una versión desarrollada por los creadores del ASCON. Los datos de esta comparación se muestran en la tabla 16. En esta tabla se comparan únicamente versiones que realizan una permutación en un ciclo de reloj (versión v1). Se observan algunas diferencias interesantes en términos de utilización de recursos. Tabla 16. Comparación de recursos con original. La versión original utiliza 496 registros, mientras que la versión creada v1 utiliza 643. Este menor uso en la versión original sugiere una optimización eficiente en términos de almacenamiento temporal y gestión de estados, pero también puede deberse a que algunos datos se tienen que almacenar en registros externos al cifrador. Es importante destacar que alcanzar este nivel de optimización en la utilización de recursos puede aumentar significativamente la complejidad del diseño y la dificultad para realizar cambios o entender el funcionamiento interno del sistema. Esta optimización, aunque resulta en un sistema más eficiente desde el punto de vista del hardware, también introduce una capa de complejidad adicional en el diseño no sólo del cifrador en sí, sino también de los circuitos de interfaz que se comunican con el cofrador. Durante el proceso de este proyecto, quedó claro que alcanzar un alto nivel de optimización puede hacer que sea más complicado comprender y modificar el cifrador. Por esto se consideró especialmente importante llevar un balance entre la claridad y la optimización del diseño. Además, trabajar para optimizar los recursos supuso un aprendizaje sobre el equilibrio entre eficiencia y accesibilidad del diseño. Aunque inicialmente el enfoque estaba puesto en mejorar el rendimiento y reducir el uso de recursos, Modelo V1 Original Utilización de la lógica Usada Utilización Usada Utilización Número de registros de segmentos 643 0% 496 0% Número de LUTs de corte 2315 3% 2356 3% Número de pares FF completamente LUT 449 17% 492 20% Número de IOB vinculados 79 37% 136 64% Número de BUFG/BUFGCTRLs 1 3% 1 3% GONZÁLEZ VILLALBA, DAVID - 90 - - 91 - BIBLIOGRAFÍA [1] Competitions.cr.yp.to. (n.d.). CAESAR: Competition for Authenticated Encryption: Security, Applicability, and Robustness. https://competitions.cr.yp.to/caesar-call.html. Accedido el 31 de enero de 2024. [2] National Institute of Standards and Technology. (2023). Final steps of the NIST lightweight cryptography standardization process [PDF]. https://csrc.nist.gov/csrc/media/Presentations/2023/final-steps-of-the-nist- lightweight-cryptography-s/images-media/talk-cesar-2023-meltem-nov2023.pdf. Accedido el 31 de enero de 2024. [3] National Institute of Standards and Technology. (n.d.). NISTIR 8114 Report on Lightweight Cryptography. https://doi.org/10.6028/NIST.IR.8114. Accedido el 31 de enero de 2024. [4] Stallings, W. (2017). Cryptography and Network Security: Principles and Practice. Pearson. https://www.pearson.com/store/p/cryptography-and-network-security- principles-and-practice/P100000337223. Accedido el 31 de enero de 2024. [5] Rogaway, P. (2004). Authenticated Encryption with Associated Data. https://web.cs.ucdavis.edu/~rogaway/papers/ad.pdf. Accedido el 31 de enero de 2024. [6] NIST. (2016). Lightweight Cryptography. https://csrc.nist.gov/projects/lightweightcryptography. Accedido el 31 de enero de 2024. [7] Digikey. (n.d.). Fundamentals of FPGAs Part 4: Getting Started with Xilinx FPGAs., de https://www.digikey.com/es/articles/fundamentals-of-fpgas-part-4-getting- started-with-xilinx-fpgas. Accedido el 31 de enero de 2024. GONZÁLEZ VILLALBA, DAVID - 92 - [8] Digilent. (n.d.). Nexys 4 DDR Resource Center. https://digilent.com/reference/programmablelogic/nexys-4-ddr/start. Accedido el 31 de enero de 2024. [9] Graz University of Technology. (n.d.). ASCON – Authenticated Encryption and Hashing. https://ASCON.iaik.tugraz.at/. Accedido el 31 de enero de 2024. [10] Fernández García, C. (2022). Diseño microelectrónico de cifradores AEAD con introducción de técnicas de reducción del consumo de potencia . Repositorio de la Universidad de Sevilla [Trabajo de Fin de Máster]. https://idus.us.es/bitstream/handle/11441/141649/FERNANDEZ%20GARCIA% 2c%20CARLOS.pdf?sequence=1&isAllowed=y. Accedido el 31 de enero de 2024. [11] NIST SP 800-38A. Recommendation for Block Cipher Modes of Operation: Methods and Techniques. https://doi.org/10.6028/NIST.SP.800-38A Accedido el 31 de enero de 2024. [12] Hardware API for Lightweight Cryptography https://cryptography.gmu.edu/athena/LWC/LWC_HW_API.pdf. Accedido el 31 de enero de 2024. [13] Ascon hardware. (n.d.). Test vectors for ASCON LWC. GitHub. https://github.com/ascon/asconhardware/blob/master/hardware/ascon_lwc/KAT/v1/test_vectors.txt Accedido el 31 de enero de 2024.