Necesita un algoritmo uno a uno muy rápido, posiblemente cifrado

Question

Necesito un algoritmo uno a uno muy, muy rápido. El algoritmo no necesita ser irrompible. Razonablemente fuerte es suficiente, pero debe ser muy rápido. Lo estaré implementando en hardware. El área también es una preocupación, por lo que no debería usar demasiada lógica.

Debería ser una función f_N (x) cuya entrada es un número de N bits y cuya salida es un número de N bits. N es una constante, probablemente entre 20-70. La función debe ser uno a uno. (es decir, invertible, lo que significa que es posible descifrar. La velocidad de descifrado es irrelevante.)

Necesito cifrar en menos de 3 ns, que es de aproximadamente 333M entradas por segundo. DES, por ejemplo, hace unos 50Mbits por segundo. Necesito 333M entradas por segundo.

Hasta ahora he estado usando un cifrado Feistel con aproximadamente 6 rondas. Eso parece tomar alrededor de 3ns.

Sugerencias?

Más notas

Ha habido algunas preguntas así que explicaré. Necesito poner llaves en una tabla hash. El método estándar es marcar la clave de entrada y usar el resultado como un índice en una tabla. Cada fila de la tabla debe almacenar la clave original. Teoría de la información nos dice que las filas de la tabla en realidad no necesitan ser tan anchas como la clave de entrada, pero más ancha que la clave de entrada menos el número de bits en la dirección de la tabla. Por ejemplo:

• entrada: x (N bits)
• hash: x% 128 (8 bits)
• verificador: piso (x / 128) (N-8 bits)

Sería tonto en una CPU donde los enteros usualmente tienen el mismo ancho pero lo estoy haciendo con hardware.

x% 128 es un hash fácil de romper. De hecho, si las claves de entrada solo difieren en los primeros bits, habrá roto el hash en un accidente. Quiero un hash que no se rompa en caso de accidente y que incluso podría ser difícil de romper a propósito. También probé un LFSR . Los LFSR son rápidos, pero dos LFSR de igual longitud generan resultados de hash que se correlacionan linealmente. (Si f (x) y g (x) dan el mismo hash para dos polinomios diferentes, f (x + 1) yg (x + 1) se correlacionan fácilmente.)

Entonces, necesito una función con entrada de N bits y V bits, salida de bits H (V + H = N) donde es difícil encontrar dos entradas de longitud N, de manera que ambas generen la misma H. El cifrado encaja a la perfección porque deja la salida de la misma longitud que la entrada y es difícil de revertir. También podría funcionar algo distinto al cifrado, aunque parece que lo que quiero es casi la misma definición de cifrado.

Lo siento por no explicar todo esto de antemano. Espero que esto aclare las cosas.

Answer 1

Cuando dices " rápido " ¿te importa solo el rendimiento, o la latencia es de la mayor importancia?

Si la latencia no es tan importante como el rendimiento, ¿hay alguna razón por la que no pueda usar un estándar Cifrado de Feistel que se sabe que es seguro, y en lugar de tener el número completo de rondas (p. Ej., Como 16 en Blowfish) de la lógica combinatoria, inserte un registro entre cada ronda, para que canalice el algoritmo de cifrado ? Básicamente, requeriría la misma cantidad de hardware (un poco más para agregar algunos flip-flops para los registros) como un algoritmo de cifrado seguro conocido, pero el retardo de propagación solo sería el de una ronda de la red Feistel + el retardo de propagación de los flip-flops.

Answer 2

Me pregunto si no está preocupado por la fortaleza del cifrado, entonces tal vez no necesite estar cifrado en absoluto. La parte más importante de un algoritmo de cifrado es su solidez. Si el cifrado es débil, entonces no estás haciendo ningún bien al cifrar en primer lugar.

Answer 3

Aquí hay algunos puntos de referencia con algunos algoritmos: http: /gd.tuwien.ac.at/privacy/crypto/libs/cryptlib/benchmarks.html

Tenga en cuenta que estos puntos de referencia están probando implementaciones de algoritmos, por lo que puede que no sea lo que está buscando.

Answer 4

Recomendaría a mi viejo amigo, el Algoritmo de cifrado minúsculo

Es una huella rápida y extremadamente baja, que probablemente también tenga que considerar al implementar en hardware.

Answer 5

Lo siguiente no satisface su requisito de una función de uno a uno, pero quizás podría ser útil si la velocidad es primordial. (Si no funciona, entonces sugeriría una ruta de dividir y conquistar: usted está trabajando en hardware, por lo que, en teoría, debería poder cifrar y descifrar en paralelo, a menos que el cifrado de una entrada dependa de los cifrados de las entradas anteriores). )

Casi el algoritmo hardware más rápido para lo que yo llamaría " munging " es tratar sus entradas conceptualmente como un flujo de bits, y XORARLAS con la salida del flujo de bits de un generador de bits reconstruible y criptográficamente seguro, que se puede reconstruir si desea descifrarlo. Un ejemplo que es simple y rápido como un rayo, pero que por sí mismo no es seguro, es un registro de desplazamiento de retroalimentación lineal (LFSR). Elija un período largo (2 ¹²⁸ - 1 o 2 ²⁵⁶ - 1 o algo así). La página de wikipedia sugiere modificaciones para mejorar la seguridad. También puede intentar ocasionalmente (p. Ej., Una vez cada M bits donde M = 4096, 16384, 65536, lo que sea) XORIando el estado del LFSR con la salida de un flujo de bits más lento pero más seguro (ya sea un cifrado de flujo o un cifrado de bloque que encripta un conjunto predeterminado de entradas, por ejemplo, una secuencia incremental, o una instantánea demorada del estado LFSR) - aunque esto se debe a la técnica criptográfica de no inventar, su idea es que las técnicas criptográficas bien conocidas tienen una gran Cantidades de energía invertidas en las pruebas para determinar si tienen vulnerabilidades.

Answer 6

¿Qué tiene de malo usar una clave " de 64 bits " " valor y xor-ing cada byte? Puede desplazarse por la clave tantas veces como sea necesario para xor los bits de texto sin formato después de los primeros 64.

Una clave de 64 bits puede ser una contraseña de 8 caracteres o un hash de 8 bytes de una frase de contraseña.

Dado que la clave tiene casi tantos bits como el mensaje, en realidad será bastante fuerte y extremadamente rápido.

Answer 7

Si está haciendo esto en hardware, ¿por qué no usa un cifrado de bloque estándar en un DSP?

¿Qué tan bien son los DSP de gama alta adecuados para el AES? ¿Algoritmos?