Acabo de terminar mi primer curso de Hardware Digital. Cubrimos circuitos combinacionales, circuitos secuenciales y FSM.
Ahora necesitamos crear un proyecto de diseño final. Tenemos 2 semanas para hacerlo y trabajamos en equipos de 2.
Quiero implementar el cifrado RSA en el hardware. Esencialmente, la FPGA tomaría una señal de audio como entrada, ejecutaría RSA en ella y emitiría la señal de audio encriptada. Usaremos Verilog y una placa DE2. Sin embargo, me preocupa que esto pueda llevar demasiado tiempo.
¿Alguien podría decirme si implementar RSA en hardware es un objetivo razonable para un proyecto de 2 semanas para alguien que solo ha tomado un curso de electrónica digital? Este es mi primer proyecto de ingeniería, por lo que todavía no soy muy bueno en el alcance.
Gracias.
RSA no será fácil de implementar y puede requerir un FPGA muy grande. RSA es mucho más adecuado para ejecutarse en una CPU de uso general que en una FPGA. He visto algunas implementaciones de RSA en un FPGA que usan un núcleo suave para ejecutar el algoritmo y el FPGA para acelerar algunas de las matemáticas, pero el algoritmo completo no está implementado en Verilog. Y, en general, cuando un archivo está "cifrado con RSA", generalmente no lo está: el archivo generalmente está cifrado con AES y la clave AES luego está cifrada con RSA, ya que AES es mucho más rápido que RSA. Si desea implementar un algoritmo de cifrado en un FPGA, especialmente para una señal de transmisión, AES sería una idea mucho mejor que RSA. Probablemente pueda implementar AES en una semana, es un algoritmo bastante simple.
RSA no es adecuado para cifrar directamente grandes cantidades de datos. No solo es demasiado lento, sino que también es más débil que algunos otros algoritmos contra un oponente que tiene una gran cantidad de pares conocidos de texto sin formato/texto cifrado. Para protegerse contra esto, los datos que se cifran con RSA generalmente se rellenan con bits aleatorios de antemano. Como consecuencia, el texto cifrado RSA generalmente será considerablemente más grande que el tamaño de la carga de datos.
El patrón de uso normal para RSA es generar una clave aleatoria para algún otro criptosistema y generar un "bloque de texto claro" RSA que contiene esa clave aleatoria junto con información adicional opcional sobre el archivo que se cifrará, llenando cualquier espacio adicional con bits aleatorios. Luego, ese bloque se encriptará y se enviará al destinatario previsto junto con una copia del archivo real, encriptado usando el otro sistema criptográfico con la clave que se incluye en el bloque encriptado con RSA.
Creo que diseñar un circuito de "acelerador RSA" en serie para realizar de manera eficiente una multiplicación NxK donde K es un valor fijo y N puede ser arbitrariamente grande podría ser un buen desafío. Hágalo de manera que una vez que el circuito se cargue con el multiplicando corto, cada fragmento del multiplicando largo sincronizado (LSB primero) generará el fragmento del mismo tamaño de datos de resultado. Si usa un tamaño de fragmento de un bit, el multiplicador podría implementarse como dos registros de N bits; si X se carga con el valor del bit K y R con cero, entonces cada paso debe realizar:
if input is 1
output = R[0] xor (input and K[0])
R = (R+K)>>1
else
output = R[0]
R = (R>>1)
endif
Implementar cosas de esa manera precisa requeriría una cadena de transporte de K-bit que podría operar en un ciclo. Sin embargo, si se piensa un poco, agregar otro registro de bits K permitiría que el circuito se comporte como el anterior, pero con un retraso de propagación bastante corto en el peor de los casos. Además, la cantidad de circuitos adicionales necesarios para manejar dos bits a la vez no sería mucho mayor que la necesaria para manejar un bit a la vez.
Diseñar un multiplicador que pueda conectarse fácilmente a un microcontrolador a través de uno o dos puertos SPI (si hay dos, haga un modo maestro y el otro modo esclavo con su reloj vinculado al maestro) podría ser un desafío razonable. Si uno estuviera dispuesto a restringir el módulo RSA a la forma 1000...000xxxxx con 256 ceros cerca de los bits iniciales (esto requeriría usar un módulo que fuera 256 bits más largo de lo que sería necesario para un nivel de seguridad dado) un Nx256 El multiplicador probablemente requeriría algo alrededor de un FPGA de 2048 puertas, pero permitiría que incluso un pequeño micro realice encriptaciones RSA en una fracción de segundo.
Esto es bastante desafiante y, a menos que use una implementación de rsa de código abierto o fácilmente disponible, 2 semanas es una exageración.
Si utiliza alguna biblioteca lista para la implementación, es posible envolver la biblioteca para satisfacer sus necesidades.
Esto supone que tiene un kit de desarrollo probado que puede usar.