¿Lleva mucho tiempo implementar RSA en hardware?

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 propósito general que un FPGA. He visto algunas implementaciones de RSA en un FPGA que utiliza un softcore para ejecutar el algoritmo y el FPGA para acelerar algunas de las matemáticas, pero el algoritmo completo no está implementado en Verilog. Y generalmente cuando un archivo está "cifrado RSA", generalmente no lo está: el archivo generalmente está cifrado AES y la clave AES está cifrada RSA ya que AES es mucho más rápida 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 puedas 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 otros algoritmos contra un oponente que tiene una gran cantidad de pares de texto cifrado / texto cifrado conocidos. Para protegerse contra esto, los datos que se cifran utilizando RSA se suelen rellenar con bits aleatorios de antemano. Como consecuencia, el texto cifrado RSA generalmente será considerablemente más grande que el tamaño de la carga útil de datos.

El patrón de uso normal para RSA es generar una clave aleatoria para algún otro sistema criptográfico y generar un "bloque de texto claro" RSA que contiene esa clave aleatoria junto con información adicional opcional sobre el archivo que se va a cifrar, llenando cualquier espacio adicional con bits aleatorios. Ese bloque luego se cifrará y se enviará al destinatario deseado junto con una copia del archivo real, cifrado utilizando el otro sistema de cifrado con la clave que se incluye en el bloque cifrado RSA.

Creo que diseñar un circuito "acelerador RSA" en serie para realizar una multiplicación de NxK de manera eficiente, donde K es un valor fijo y N puede ser arbitrariamente grande podría ser un buen desafío. Asegúrese de que una vez que el circuito esté cargado con el multiplicando corto, cada fragmento del multiplicando largo registrado (LSB primero) generará el mismo tamaño de datos de resultados. Si utiliza un tamaño de fragmento de un bit, el multiplicador podría implementarse como dos registros de N bits; si X está cargado con el valor de K-bit y R con cero, entonces cada paso debe realizarse:

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 manera precisa requeriría una cadena de transporte de K bits que podría funcionar en un ciclo. Sin embargo, con un poco de reflexión, agregar otro registro de K bits permitiría que el circuito se comporte como el anterior, pero con un retardo de propagación en el peor de los casos bastante corto. Además, la cantidad de circuitos adicionales necesarios para abordar dos bits a la vez no sería mucho mayor que la requerida para manejar un bit a la vez.

Diseñar un multiplicador que se pueda conectar fácilmente a un microcontrolador a través de uno o dos puertos SPI (si hay dos, crea un modo maestro y el otro modo esclavo con su reloj conectado al maestro) puede 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 en torno a 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 un código abierto o una implementación rsa fácilmente disponible, 2 semanas es un tramo.

Si usa alguna biblioteca lista para la implementación, es posible envolver la biblioteca para que se ajuste a sus necesidades.

Esto supone que tienes un devkit probado que puedes usar.