Solución para almacenar datos confidenciales sin tener acceso a ellos

1

Necesito desarrollar un sistema en el que tengamos que almacenar datos confidenciales criptográficos, pero no tenga acceso directo a ellos.

Lo que creo es algo así como un par de claves private / public-ish . Mantendremos el privado para encriptar los datos que los Usuarios pueden ingresar y darles la clave public-ish . Los datos solo se pueden descifrar con ambos el privado y la public-ish .

De esta manera, podemos almacenar los datos, pero no tenemos acceso a ellos. Además, una vez que los Usuarios desean obtener su información, deberán informar su clave, para que podamos descifrarla y enviarla de vuelta.

¿Esto tiene sentido? ¿Hay un estándar criptográfico para algo como esto? ¿O hay otro concepto / sistema de criptografía que podría usar en este caso?

¡Gracias!

    
pregunta jonatas.baldin 20.07.2017 - 04:06
fuente

2 respuestas

2

A partir de su descripción, asumo que (A) en realidad no necesita acceder a los datos de los usuarios (B) en ningún momento. Es decir. A almacena los datos de B, nada más.

Si es así, toda tu idea suena bastante mal.

Algo sobre el cifrado asimétrico normal primero:

  • La clave pública se utiliza para en crypt. La clave pública, no la clave privada. La idea es que descifrar es difícil. No será difícil si necesita la clave pública para ello.
  • No hay algo como una clave pública / semiprivada. Una de las dos llaves siempre puede calcular la otra clave también (pero no al revés), es decir, la clave privada puede usarse para calcular la clave pública.
  • No hay un esquema de encriptado asimétrico (único) donde el descifrado necesita ambas claves. Podrías usar dos pares de kay, es decir. 4 teclas, para hacer algo así, pero no un solo par público / privado.

Dijo que el siguiente problema es su definición de "almacenamiento sin acceso". Si A quiere almacenar datos sin tener acceso, ¿por qué B debería enviar los datos simples a A? Porque eso es exactamente lo que está proponiendo: B envía datos a A para que A pueda cifrarlos en ese momento. Antes de encriptar, A tiene mucho acceso. La misma historia más tarde, cuando se descifra en el lado de A otra vez antes de que los datos se devuelvan a B.

Tercero, A le da a B una clave, y luego B envía la clave a A? ¿Cómo estás seguro de que A no mantendrá la clave para tener acceso todo el tiempo? ¿Y por qué las llaves se envían alrededor?

Lo que podrías hacer (y es mucho más fácil): A almacena los datos, como dijiste, y nada más . No invente estrategias de cifrado no genéticas que involucren a ambos lados. Si B desea que los datos sean privados, B puede cifrarlos solo, con sus propias claves y métodos, antes enviándolos a A. A nunca obtendrá ninguna clave.

Y si tiene eso, también debería pensar en integridad + autenticidad.

    
respondido por el deviantfan 20.07.2017 - 04:54
fuente
0

Si tiene un par de llaves asimétricas (clave pública y clave privada): si está cifrada con la clave pública, entonces la clave privada se utiliza para realizar el descifrado y viceversa. No utiliza ambos simultáneamente para realizar el descifrado. ¿No está seguro de si esto es un malentendido del sistema clave o simplemente un error tipográfico?

En segundo lugar, las claves asimétricas tienden a ser una mala opción para cifrar grandes cantidades de datos. Un algoritmo de clave simétrica como AES sería preferible, consulte lo siguiente para obtener más información: RSA vs AES

Si desea que el usuario pueda almacenar datos, no puede descifrarlos y luego descifrarlos. Podría tener más sentido para el usuario cifrarlo con una clave simétrica como AES en el lado del cliente antes de que lo reciba. Luego, pueden solicitar la devolución de los datos cifrados y descifrarlos ellos mismos.

No estoy seguro de si está sugiriendo que el usuario envíe datos sin cifrar, ¿que luego cifrará con una clave privada? ¿Qué se les devuelve para descifrarlos con una clave pública al final? En ese caso, los datos sin cifrar todavía están siendo expuestos a ustedes mismos al principio. ¡Pido disculpas de nuevo si me he malinterpretado!

    
respondido por el 0zero 20.07.2017 - 17:41
fuente

Lea otras preguntas en las etiquetas