La mayor dificultad que tendrá en la construcción de este sistema no es técnica, sino más política y legal. Serás el blanco de todos los gobiernos del mundo. El gobierno será su mayor amenaza, y no puedo ver dónde podría obtener un alojamiento adecuado sin algún tipo de "puerta trasera / canal" para las agencias gubernamentales.
Por ejemplo, aquí en los Estados Unidos, es probable que reciba una Carta de seguridad nacional que significa que ganó. Incluso ser capaz de reconocer que están obligados a entregar las llaves. El gobierno probablemente promocionará el terrorismo y el crimen como el razonamiento de la NSL, por lo que pasará mucho tiempo tratando de despegar en cualquier país del mundo. Así que en las partes técnicas de esto, junto con los obstáculos que deberá superar para que sea realmente seguro.
Comenzaré respondiendo a tu última pregunta: " ¿Hay algo que nos falta aquí? " Esto es esencialmente lo que estás buscando hacer
PersonUsingService —> connects to your systems —> encrypt/decrypt email
Escenario 1) La máquina de PersonUsingService está fuera de control. Cualquier software malicioso (rootkits, registradores de pulsaciones de teclas, etc.) significa que su sistema falló, a pesar de que hizo su trabajo. Imagine que construyó algo que llamó la atención de, por ejemplo, EFF / ACLU, utilizaron el servicio solo para descubrirlo, sus comunicaciones terminaron en Pastebin . Todo lo que sabrán es que pasó por sus sistemas, y al final, su reputación se resentirá.
Escenario 2) PersonUsingService's es MITM antes de llegar a su servidor. De hecho, los gobiernos colocan Narus tocan en las IXP , o simplemente roban su certificado, o le pagan mucho a una CA. Tu sistema falla.
Escenario 3) Tomas el tiempo para crear un maravilloso esquema, pero nunca protegiste tu infraestructura interna, alguien accidentalmente hace clic en un enlace mientras está en tu equipo de desarrollo. Permite a los gobiernos, o pícaros, acceder a su sistema clave.
Puedo dar docenas de ejemplos de por qué esta es una batalla perdida. Si bien entiendo de dónde vendría usted al solicitar un sistema de este tipo, la realidad es que es muy complejo, no desde el punto de vista tecnológico, sino desde el ámbito legal.
Regrese a sus preguntas: "¿Se almacenan las claves privadas (cifradas)?" (se detienen aquí) NO HAY UNO, pero el propietario de la clave debería tener acceso a su clave privada, de lo contrario el sistema falla. Todo el propósito del cifrado era mantener privadas las claves privadas. Sin embargo, en un mundo ideal, habría confianza en lo que usted declaró inicialmente: "Las personas que viven en países con regímenes totalitarios, opresivos y otros que amenazan", debe recordar que estos tipos de regímenes no tienen problemas al usar " Rubber Hose crypto " para acceder a sus sistemas (y claves).
Desde la perspectiva técnica, tal vez sea mejor echar un vistazo a Vanish y el modelo presentado a partir de ellos, y construir alrededor de eso. Por ejemplo:
PersonUsingService —> log in —> create disappearing (24-48hr key) —> encrypt message
System —> 24-48 expiry —> erase keys
En algo como este modelo, necesitabas preocuparte por almacenar las claves, ya que la probabilidad de una "redada de respuesta rápida" para obtener una clave de criptografía es baja. Mi percepción de por qué nadie está perdiendo el tiempo respondiendo a esto, es porque las empresas lo han intentado en el pasado (Hushmail) y han quemado mucho dinero al hacerlo. Por no mencionar al final, la ley prevalece sobre las opiniones personales, las creencias, etc. Si un gobierno declara que renuncias a las llaves, tienes una pelea de por vida que intenta demostrar tu punto.