Ciertamente, puede implementar un sistema que use cifrado de extremo a extremo y tenga la parte del servidor escrita en PHP [1] . Solo tendrá que implementar la parte criptográfica como algo que se ejecuta en los "extremos", es decir, los navegadores, por lo que de manera realista necesitará implementarlo en JavaScript, y su código PHP servirá esta JS a los puntos finales. El código PHP también tendría que proporcionar las claves públicas [2] para todas las personas que se supone deben tener acceso a los datos que se cifran. Dependiendo de cómo vaya a almacenar las claves privadas, el PHP probablemente almacenará (y servirá) una versión "encriptada" (es decir, encriptada) de esas, también.
La parte del lado del servidor (PHP) de todo este proyecto termina siendo un poco más complicada que una aplicación web típica. Debe poder autenticar usuarios, lo cual es normal, pero sin habilitar a los administradores suplantar a los usuarios (esto no es normal) [3] . Probablemente deba poder almacenar (y controlar el acceso a) los datos privados por usuario (las claves secretas envueltas), los datos públicos por usuario (las claves públicas) y los datos compartidos de acceso restringido (los datos reales encriptados del usuario). ). Dependiendo de qué tipo de datos se almacenan, cuánto de ellos, si necesita poder ajustar quién tiene acceso a ellos después del hecho, y si necesita algún tipo de capacidad de búsqueda, puede encontrarse con cualquiera host de complejidades adicionales. Los sistemas seguros de extremo a extremo son difíciles . Íntimidad4 ">
La parte del lado del cliente (JS) de esta cosa va a ser donde ocurre el levantamiento de pesas, criptográficamente, sin embargo. Eso es un poco incómodo, porque JS no es bueno en crypto. Existen implementaciones puras de JS de las funciones criptográficas estándar, pero tienden a tener problemas (como ser relativamente lentas y potencialmente exponer vulnerabilidades de canal lateral como los ataques de tiempo). Algunos navegadores admiten la realización de operaciones criptográficas nativas utilizando datos de JS, que es más rápido y más seguro (suponiendo que confía en el desarrollador del navegador, algo que necesita hacer aquí), pero aún no es universal.
[1] Probablemente no debas . PHP es una mala elección para cualquier código altamente sensible a la seguridad, ya que es relativamente fácil cometer errores de seguridad. El código seguro en PHP (moderno, completamente parcheado) es ciertamente posible, pero recomendaría usar un lenguaje que lo haga es más difícil sacar tu propio pie, como Java, C #, VB.NET, o tal vez Go o Python.
[2] Esto presenta una debilidad de seguridad que necesita para encontrar una manera de evitarlo, ya que el sistema de punto final (el usuario y su navegador web) no tienen forma de saber si las claves públicas se enviaron al cliente (para los datos que se están cifrando) son las claves públicas right . Un administrador de servidor malintencionado podría agregar su propia clave pública a la lista de claves, y cualquier dato cifrado con esa lista de claves sería legible por el administrador malintencionado. Necesita alguna forma de verificar la autenticidad de la clave.
[3] Un punto difícil aquí es que, si bien el servidor nunca debe almacenar la contraseña del usuario, el servidor normalmente ve la contraseña, brevemente, al crear la cuenta y siempre que Se usa la contraseña (iniciar sesión, cambiar la contraseña, etc.). Un administrador de servidor malintencionado podría modificar el servidor para robar esta contraseña. Si esa contraseña es todo lo que se necesita para iniciar sesión como ese usuario, por ejemplo, si conocer la contraseña del usuario le permite desenvolver la clave privada del usuario, el administrador malintencionado podría descifrar los datos a los que se supone que no deben tener acceso. para hacerse pasar por un usuario legítimo.
[4] Honestamente, esto suena como un proyecto para alguien con más experiencia en seguridad de la información y como desarrollador. No es un problema fácil, y el cifrado es difícil de hacer bien.