¿Correo electrónico PGP bidireccional sin publicar su clave / dirección en un servidor de claves?

Transmisión de clave confidencial

Tienes que discriminar entre diferentes temas:

1. Claves de transmisión privada

   Este es su principal desafío, acerca de cómo obtener la clave para el otro lado sin revelarla al público. Puede hacer esto de la forma que desee, en la que también confiaría en lo que respecta a la transmisión de datos confidenciales. Si OTR está bien para usted, entonces también lo es para transmitir sus claves.

   Enviar claves sin utilizar servidores de claves es tan fácil como

   gpg --armor --export [key-id] > key.asc     # Send file key.asc to the recipient
   gpg --import key.asc                        # Recipient can import the key
   

2. Verificación de la validez de las claves

   Este es un problema completamente desconectado, que también ocurre si no transmite datos clave en privado (es decir, mediante los servidores clave). Por lo general, esto se realiza mediante la comunicación de la huella digital de la clave (una especie de suma hash) a través de un canal seguro, a menudo comunicación cara a cara.

Si ya estableció un canal seguro y confiable (como OTR con claves verificadas), podría usar esto para hacer ambas cosas: sabe que nadie puede evesdrop y el otro lado está autenticado.

Si confía en que sus operadores de correo y de red no manipularán los correos sin texto sin firmar (y no los evasará), y las agencias gubernamentales no son un vector de ataque que le importe, un simple El correo de texto puede estar bien para hacerlo. Si todo lo que quiere hacer es evitar que los spammers obtengan su clave (que incluye su dirección de correo), es muy probable que esta sea una forma suficientemente privada de intercambiar claves, solo considere quién podría tener acceso a la ruta de transmisión: probablemente los spammers no estén entre ellos.

¿Vale la pena el esfuerzo?

O mejor: ¿cuánto esfuerzo vale?

Tenga en cuenta que cualquiera que sea hombre en el medio podrá observar con quién se está comunicando de todos modos. El spam es un problema con las claves en los servidores de claves públicas, pero tienes que lidiar con eso de todos modos. Mantener las claves privadas solo funciona mientras nadie cometa un error; se dice que la carga de las claves incorrectas o incluso todas en el almacén de claves local suceda (y se realiza fácilmente).

OpenPGP con su infraestructura de servidor de claves está diseñado principalmente para mantener los contenidos de su comunicación en privado, al tiempo que garantiza la autenticidad al compartir sus claves públicas y firmas. Si bien puede usarse de la manera que usted quisiera, tenga en cuenta que este no es uno de los objetivos principales. Si desea utilizar OpenPGP sin cargar las claves, espere que se haga público de todos modos y no confíe en él si una clave pública con fugas sería un desastre.

Uso del correo cifrado del gobierno

  

¿Y muchas personas conscientes de la privacidad (como los miembros de las fuerzas del orden público, como los agentes de la NSA) hacen esto para evitar que sus direcciones de correo electrónico (gubernamentales) sean "excluidas" públicamente al estar en las listas públicas de claves de PGP? ¿Tal vez tienen sus propios servidores PGP privados dentro de cada organización para encargarse de eso?

Muy probablemente, simplemente no usan OpenPGP. Estas son organizaciones organizadas centralmente, que a menudo son mejores al usar sistemas jerárquicos como X.509. Y lo que es peor, no estaría muy seguro de que el uso de los mensajes cifrados de extremo a extremo esté ampliamente difundido de todos modos.

Si lo hacen, lo más probable es que utilicen las claves S / MIME y X.509 junto con un servidor de claves interno que esté integrado en su base de datos de usuarios. Es muy probable que no haya una lista completa de claves / certificados disponibles; pero cuando ya se estén comunicando con usted, es muy probable que compartan el certificado firmando sus correos (en S / MIME, el certificado que contiene la clave pública se adjunta a cualquier mensaje firmado).

No tiene que incluir su dirección de correo electrónico.

Una ID de usuario generalmente consta de un nombre, un comentario (a menudo se omite) y una dirección de correo electrónico, pero esto es no requerido por la especificación OpenPGP.

Tenga en cuenta que las herramientas para crear claves OpenPGP pueden requerir ingresar la ID de usuario de alguna manera específica, sin embargo. GnuPG 1.4, por ejemplo, requiere un nombre con más de 4 caracteres (que no puede comenzar con un número), pero el comentario y la dirección de correo electrónico son opcionales.

Contra

No especificar una dirección de correo electrónico tiene tres posibles inconvenientes:

• {a} Algunos socios de comunicación pueden confundirse al administrar su clave. ( ¿Eh, por qué falta la dirección de correo electrónico? ¿De quién fue la clave de nuevo? ¿A cuál de los tres John ¿Sé que pertenece esta clave? )

• {b} Si los administradores de claves del cliente de correo electrónico asocian / preseleccionan automáticamente las claves al redactar un correo electrónico para un nuevo destinatario, esto obviamente fallará. ( Maldición, tengo que seleccionar la clave manualmente! )

• {c} Es posible que algunos participantes de Web of Trust no quieran firmar su clave si pierde una dirección de correo electrónico.

En su escenario, probablemente ninguno de estos asuntos:

• Acerca de {a}: Es probable que su compañero de comunicación entienda esto y sepa de quién es la clave (además, podría usar un (apodo) nombre que solo su compañero sabe / entiende).

• Acerca de {b}: su socio de comunicación tendría que asociar su clave con su dirección de correo electrónico en el cliente de correo solo la primera vez, después de lo cual el cliente generalmente recuerda esto.

• Acerca de {c}: no desea participar en la Web de Trust con esta clave (e incluso si, sin su dirección de correo electrónico de todos modos).

Pro

• {A} Incluso podría usar servidores de clave pública si la dirección de correo electrónico es su única preocupación.

• {B} Si su clave se publica en un servidor de claves de alguna manera, su dirección de correo electrónico no se filtrará.

Creo que estos son incluso los pros en tu escenario:

• acerca de {A}: podría usar servidores clave, lo que le facilitará la vida a usted y a su compañero de comunicación si cambia / actualiza las subclaves. Solo deberías usar la ID de la clave para encontrar la clave.

• acerca de {B}: Algunas herramientas pueden hacer que las claves de publicación sean demasiado fáciles, por lo que su compañero de comunicación podría accidentalmente publicarlas algún día.

Verificando que tiene la clave correcta funciona exactamente de la misma manera que si incluyera su dirección de correo electrónico: debe comunicarse con su socio a través de un canal seguro por una sola vez (solo) y compara las huellas dactilares.

Sí, el envío de la clave en el primer correo electrónico (texto sin formato) funcionaría.

Esto es esencialmente lo que hace la mayoría de las personas cuando aceptan ciegamente una nueva clave de host ssh.

Incluso si no va a verificar la identidad del otro lado - como debería -, antes de enviar datos levemente confidenciales, las apuestas siguen siendo buenas para usted:

• Quizás no te estén espiando cada vez. Su correo electrónico podría pasar.
• Si en algún momento empiezas a ser espiado, los intercambios pasados serían seguros.
• Es posible que no tengan el programa disponible / habilitado para MITM en todos sus intercambios de claves.
• No saben si vas a llamar inmediatamente a tu destinatario para confirmar la huella digital.
• Los mensajes de dos vías deben modificarse por un tiempo indefinido.
• Puedes verificar la identidad de tu pareja semanas / meses después.
• Hay un período de tiempo limitado para MITM en su intercambio (compare con la lectura de un archivo de correo electrónico).

A diferencia de una lectura pasiva de sus mensajes (como acceder al buzón del objetivo), realizar un MITM en un intercambio de claves es ruidoso (y probablemente más ilegal), y pondrá a la víctima en modo de paranoia si se descubre. Por lo tanto, a menos que seas un objetivo de alto perfil, no creo que sea sensato jugar con ese nivel (aunque puedes ser considerado más importante de lo esperado, y también hay atacantes estúpidos).

Entonces, sí, intercambiar sus claves a través de correo electrónico no cifrado es una solución viable. Pero haz tu parte y trata de verificarlos.

Cuidado: si trata con personas no técnicas, muchas personas técnicas y, en general, esperan muchas preguntas básicas sobre "cómo usar esto?", personas que le envían su clave privada con la pública, etc.

Algunas ideas:

Si solo va a intercambiar correos de PGP, puede filtrar automáticamente como spam todo lo que no esté firmado / encriptado en su clave. (Problema de spam)

Como la existencia del correo electrónico está destinada a ser secreta, puede utilizar una dirección de correo electrónico aleatoria como < huella digital > @dominio (solo una pieza para transmitir, en lugar de correo electrónico + huella digital). En el lado positivo, esto obliga a su interlocutor a obtener la huella digital correcta si va a iniciar la comunicación. En el lado negativo, los ataques de homógrafos son más fáciles.

Supongo que este sistema es de hecho utilizado por personas [gubernamentales] conscientes de la privacidad. La publicación de claves / huellas digitales en páginas https también es común.

Por mucho que el sistema X.509 pueda ser más adecuado para dicha organización, no creo que los utilicen. También está la duplicidad si están utilizando OpenPGP para otros corresponsales. Y, por supuesto, un agente secreto en una misión encubierta no estaría usando una clave X.509 (ni dirección de correo electrónico) que lo identifique como tal. ;)

PS: ejecuta gpg --search nsa.gov para algunas claves divertidas publicadas en los servidores de claves.