Primero, permítame decir que esto es esencialmente una reafirmación de la respuesta vinculada a su pregunta.
Le sugiero que utilice el cifrado de clave simétrica para proteger los archivos y el cifrado de clave asimétrica (pública) para proteger las claves de cifrado simétrico. Puede usar un par de claves PGP / GPG existente o, para hacerlo transparente, generar un par de claves explícitamente para su aplicación. Si hace esto último, por favor use el código probado para generar las claves.
Usted declaró el requisito de que no se almacenen claves en el servidor porque "no quiero dar al encargado del servicio la capacidad de acceder a los datos del usuario". Mientras las claves almacenadas en el servidor estén encriptadas, el responsable del servicio no tiene acceso a los datos, por lo que he interpretado que "no hay claves en el servidor" como "no hay claves que permitan el acceso a los datos".
El proceso funciona así: cuando se carga un archivo, se debe cifrar (mediante una aplicación en el cliente del remitente) utilizando un algoritmo simétrico como AES y una clave generada aleatoriamente. La clave debe ser generada por un generador de números aleatorios criptográficamente seguro ( CSPRNG )
El archivo cifrado se carga en el servidor. La clave simétrica, encriptada con la clave pública del remitente, se carga como metadatos del archivo, asociada con la ID del remitente. Si un usuario carga un archivo con el ID [email protected], los metadatos se verían así:
[email protected] | cifrado (con K A ) clave simétrica
En este punto, solo Alice puede leer el archivo porque solo Alice tiene la clave privada que descifra la clave simétrica cifrada del archivo. (La aplicación debe haber descartado la copia no cifrada de la clave simétrica poco después de la actualización de los metadatos).
Si Alice quiere permitir que [email protected] recupere el archivo, agrega a los metadatos una línea como esta:
[email protected] | clave simétrica cifrada (con K B )
Alice hace eso al recuperar sus propios metadatos, descifrar la clave simétrica con su clave privada y volver a cifrarla con la clave pública de Bill.
Suponiendo que el archivo de metadatos en sí no está protegido, Bill puede pasar el acceso a Charlie realizando el mismo tipo de operación. Eso no solo está bien, es bueno. Bill, obviamente, puede descargar el archivo y darle una copia a quien quiera. Si el acceso se pasa a través de los metadatos del archivo, entonces hay un registro de lo que sucedió. (Bill puede todavía pasar el archivo a otros, pero ya no está obligado a tomar esa ruta).
Debido a su requisito de que solo se use una contraseña, deberá usar la contraseña que desbloquea la clave privada como contraseña de inicio de sesión. Una forma de hacerlo podría ser almacenar en el servidor un autenticador para cada usuario, cifrado con la clave pública del usuario. Solo un usuario con la clave privada correspondiente puede descifrarla y devolver el autenticador de texto sin formato al servidor.
Todo hasta el inicio de sesión implica cifrado de extremo a extremo, por lo que todo lo que pasa "por cable" se cifra. Para la autenticación de inicio de sesión, el cliente debe devolver el autenticador de texto sin formato, y eso significa que se necesita una conexión TLS.