Descifrado parcial usando un servicio de descifrado no confiable

Question

Descifrado parcial usando un servicio de descifrado no confiable

#1 de HTLee (1 votos)

1

Si bien hay formas de cifrar y descifrar la información, la mayoría parece bastante pesada. Debido a esto, estoy pensando en dividir el descifrado en dos partes: una es computación pesada y la otra es computación liviana. La primera parte se realiza en el servidor remoto no confiable utilizando algún tipo de clave de sesión, mientras que la segunda parte se realiza en el lado del cliente sabiendo la clave real.

El usuario tiene una clave K y hay información cifrada T en el servidor. El usuario genera algo de K1 desde su K y lo envía al servidor. El servidor intenta descifrar T con K1 y obtiene algo de T1 en su lugar. Todavía no está completamente descifrado y ninguno de T, T1, K1 permite que el servidor calcule K. Sin embargo, K1 se genera de una manera en que el usuario puede descifrar fácilmente T1.

¿Es este enfoque posible en absoluto? ¿Cuáles podrían ser problemas potenciales?

Actualización: Vine con un ejemplo de cómo se podría hacer: el usuario genera varias claves: K1, K2, K3 ... KN, las baraja y agrega su propia clave K en la mezcla. Luego envía todas esas claves al servidor y le pide que descifre T con cada una de estas claves. El servidor no sabe qué clave es la correcta, mientras que el usuario sabe cuál de T1 ... TN es la información descifrada real, mientras que el resto es basura. Este enfoque en particular tiene muchas debilidades inherentes y no permite usar el servidor para el cifrado (es decir, es de "solo lectura"), pero es algo de lo que estoy buscando.

Actualización 2: (desde que me gasté mi reputación en recompensas, ya no puedo hacer comentarios sobre las respuestas). La idea es tener una función que se pueda aplicar a una tecla y su función inversa que se pueda aplicar a un "texto simple" que sea fácil de calcular y que el servidor no pueda predecir (es decir, que no sea constante). El "generar basura" y "descartar basura" son ejemplos de esto. El "generar hash desde la clave" y "no hacer nada" no son lo suficientemente buenos: el servidor simplemente puede omitir el cifrado, por lo que esto solo funcionaría si el hash es diferente para cada sesión.

No sé si esto es posible, pero tampoco puedo demostrar que sea imposible.

cryptography encryption decryption

pregunta aragaer 07.06.2016 - 13:54

fuente

1 respuesta

Lea otras preguntas en las etiquetas cryptography encryption decryption

TOTP: Almacenar secretos simétricos ¿Es seguro usar OAuth (concesión de credenciales de contraseña del propietario del recurso) para la autenticación?

score 1 · Answer 1

Su premisa es incorrecta, pero conceptualmente creo que el problema al que se está refiriendo ha sido resuelto por los administradores de contraseñas basados en el servidor mediante el uso de funciones de derivación de claves basadas en contraseñas (por ejemplo, PBKDF2).

La razón por la que su premisa no es correcta es que el cifrado y descifrado simétricos (por ejemplo, AES) es rápido incluso en JavaScript. En estos días, el costo es bajo, especialmente cuando muchos dispositivos de los consumidores tienen hardware dedicado para procesarlo.

Por otra parte, el cifrado asimétrico (basado en claves públicas y privadas) es costoso, y si su procesamiento se vuelve prohibitivo en una aplicación, es muy probable que se aplique incorrectamente.

Aunque con un algoritmo como el cifrado y descifrado AES es rápido, si no conoce la clave correcta, tardará una eternidad en adivinar la correcta porque hay demasiados para adivinar (especialmente con 256 bits). Esto se ve agravado por el uso de PBKDF2, que explicaré en un momento.

Aunque dice que el servidor no es de confianza, confía lo suficiente para recibir y almacenar sus datos cifrados, pero supongo que no confía en que reciba y almacene directamente cualquier tipo de datos confidenciales en texto plano. Otra suposición que haré es que el servidor intentará asegurarse de que los datos cifrados solo se le envíen a usted y no a todos los que simplemente los solicitan. Suponiendo que esto sea razonable, presentaré un esquema utilizando PBKDF2 que muchos servicios de administrador de contraseñas basado en servidor utilizan.

¿Qué es PBKDF2? Crea una clave a partir de otra clave, como su K a K1. Lo interesante de PBKDF2 es que puede hacerse tan rápido o tan lento como desee, cuanto mayor sea el número de rondas de iteración, más lenta será.

Registro en el servidor para establecer credenciales de autenticación y enviar datos cifrados:

//// JavaScript client side
PBKDF2(password, 1000 rounds) => encryption key // fast because low number of rounds
encrypt(encryption key, data) => encrypted data // fast even with AES 256
hash(encryption key) => auth key

// send encrypted data and auth key to server

//// Server side
PBKDF2(auth key, 100000) => server hash // slow because high number of rounds
// store server hash and encrypted data

Cuando posteriormente accedes al servidor:

//// JavaScript client side
PBKDF2(password, 1000 rounds) => encryption key // fast because low number of rounds
hash(encryption key) => auth key

// send auth key to server

//// Server side
// verify auth key
PBKDF2(auth key, 100000) => server hash // slow because high number of rounds

// if server hash matches what was previously stored return encrypted data
// send encrypted data back to client

//// JavaScript client side
decrypt(encryption key, encrypted data) => data // fast

Tenga en cuenta que mi referencia a PBKDF2 anterior es una simplificación para demostrar su función en lugar de su uso real.

Creo que esta propuesta resuelve el problema inherente que creo que estás preguntando, sin necesidad de un nuevo tipo de cifrado, y en cambio confía en técnicas criptográficas fuertes conocidas. Todo en el lado de JavaScript del cliente es bastante rápido, ya que conoce la contraseña / clave, mientras que tratar de obtener sus datos cifrados y luego romper el cifrado desde el lado del servidor es costoso.

Aspectos destacados de la propuesta:

Todo en el lado del cliente es rápido.
- PBKDF2 tiene un número bajo de rondas por lo que es rápido
- El cifrado y descifrado AES es rápido
El servidor nunca tiene conocimiento de:
- Contraseña de texto sin formato.
- Datos confidenciales (descifrados).
El servidor almacena datos encriptados. Obtener información de aquí es caro.
- La autenticación requerida para obtener los datos cifrados es relativamente lenta. Primera línea de defensa.
- Si una entidad malintencionada logra de alguna manera obtener los datos encriptados, seguirán demorándose en descifrar, ya que no conocen la clave de encriptación. Segunda línea de defensa.