El conocimiento es poder. En otras palabras, si el usuario debe poder realizar alguna acción y nadie más debe poder hacer la misma acción, entonces debe haber algún valor (una "tecla ") que solo el usuario sabe, y nadie más.
Además, el uso de un valor significa necesariamente tener ese valor a la mano; cuando descifre con una clave, entonces tendrá esa clave, al menos mientras descifre. Si el usuario debe conocer la clave solo una vez, esto implica que el descifrado se producirá solo en un sistema que está bajo el control exclusivo del usuario. En pocas palabras, el descifrado tendrá que ocurrir en la máquina del usuario (sistema de escritorio, computadora portátil, tableta ...) y no en ningún sistema que nunca debería ver la clave (por ejemplo, su servidor).
Por lo tanto, tienes dos problemas que resolver:
- Cómo almacenar la clave para que el usuario pueda acceder a ella, pero solo ese usuario puede acceder a ella.
- Cómo hacer que el descifrado ocurra en el sistema cliente de una manera que no pueda eludir fácilmente.
El primer problema se puede solucionar utilizando un archivo local o un área de almacenamiento. Hasta cierto punto, puede ayudar al cliente con algún almacenamiento del lado del servidor y cifrado basado en contraseña: si tiene algún dato D , entonces puede almacenar en el servidor E p ( D ), que es el cifrado de D con una contraseña p que el servidor NO sabe. El cifrado basado en contraseña es difícil en general; Comience por leer esta respuesta . En ese modelo, el conocimiento realmente específico del usuario es la contraseña p , que el usuario transporta en su cabeza.
El segundo problema es más problemático. No lo resolverá en JavaScript puro (en un contexto web) porque cualquier cosa que JavaScript ejecute el cliente será enviada por su servidor , por lo que su servidor siempre tendrá la capacidad conceptual de enviar, una vez , un JavaScript malicioso que toma la contraseña / clave / lo que sea y se la envía de vuelta a usted. Supongo que su problema aquí no es solo dar la capacidad de descifrar datos solo al usuario, sino también hacerlo convincentemente , es decir, poder demostrar a terceros que realmente no puede acceder los datos. En el mejor de los casos, esto es difícil; una posible estrategia es hacer que el cliente use algún código de aplicación local que pueda manejar el descifrado, y está firmado por usted, y es fácil de realizar ingeniería inversa (C # / .NET y Java vienen a la mente aquí). Si existe una aplicación cliente de este tipo, puede afirmar que no puede saquear discretamente los datos del usuario porque implicaría incluir una aplicación maliciosa en su sistema, que luego podría ser de ingeniería inversa, y la firma lo incriminará.
En la Web pura sin una aplicación local, olvídalo. El modelo Java applet podría haber sido aplicable, pero será difícil de hacer en la práctica porque no hay mucha gente que admita applets de Java en la actualidad ( y .NET + SilverLight es incluso menos ampliamente implementado).