Este desafío conlleva una recompensa de 200 puntos para que el primero responda y permanezca invicto durante al menos 3 días.Reclamado por el usuario 3080953 .
Últimamente se habla mucho sobre el cifrado de extremo a extremo y se presiona a las empresas para que lo eliminen de sus productos. No estoy interesado en los aciertos y errores de eso, pero me preguntaba: ¿qué tan corto puede ser el código que presionaría a una empresa para que no lo use?
El desafío aquí es implementar un intercambio de claves Diffie Hellman entre dos sistemas en red, luego permitir a los usuarios comunicarse de un lado a otro utilizando la clave simétrica generada. Para el propósito de esta tarea, no se requieren otras protecciones (por ejemplo, no es necesario cambiar la clave, verificar identidades, proteger contra DoS, etc.) y puede asumir un Internet abierto (cualquier puerto que escuche está disponible para todos). ¡El uso de builtins está permitido y fomentado!
Puede elegir uno de dos modelos:
- Un servidor y un cliente: el cliente se conecta al servidor, luego el servidor o el cliente pueden enviar mensajes al otro. Los terceros entre los dos deben ser incapaces de leer los mensajes. Un ejemplo de flujo podría ser:
- El usuario A inicia el servidor
- El usuario B inicia el cliente y lo dirige al servidor del usuario A (por ejemplo, a través de IP / puerto), el programa abre una conexión
- El programa del usuario A reconoce la conexión (opcionalmente, solicita primero el consentimiento del usuario)
- El programa del usuario B comienza a generar un secreto DH y envía los datos requeridos (clave pública, primo, generador, cualquier otra cosa que su implementación necesite) al usuario A
- El programa del usuario A utiliza los datos enviados para completar la generación del secreto compartido y envía los datos requeridos (clave pública) al usuario B. Desde este punto, el usuario A puede ingresar mensajes (por ejemplo, a través de stdin) que serán encriptados y enviados al usuario B (por ejemplo, stdout).
- El programa del usuario B completa la generación del secreto compartido. Desde este punto, el usuario B puede enviar mensajes al usuario A.
- O bien: un servidor con dos clientes conectados: cada cliente habla con el servidor, que reenvía su mensaje al otro cliente. El servidor en sí (y cualquier tercero intermedio) no debe poder leer los mensajes. Además de la conexión inicial, el proceso es el mismo que el descrito en la primera opción.
Reglas detalladas:
- Puede proporcionar un solo programa o múltiples programas (por ejemplo, servidor y cliente). Su puntaje es el tamaño total del código en todos los programas.
- Su programa debe ser teóricamente capaz de comunicarse a través de una red (pero para las pruebas, localhost está bien). Si su idioma de elección no admite redes, puede combinarlo con algo que sí lo haga (por ejemplo, un script de shell); en este caso, su puntaje es el tamaño total del código en todos los idiomas utilizados.
- La generación de claves Diffie Hellman puede usar valores codificados "p" y "g".
- La clave compartida generada debe ser de al menos 1024 bits.
- Una vez que se comparte la clave, la elección del cifrado de clave simétrica depende de usted, pero no debe elegir un método que actualmente se sabe que tiene un ataque práctico contra ella (por ejemplo, un cambio César es trivial para revertir sin conocer la clave ) Ejemplo de algoritmos permitidos:
- AES (cualquier tamaño de clave)
- RC4 (teóricamente roto, pero no hay ataques prácticos de los que pueda encontrar mención, por lo que está permitido aquí)
- Los usuarios A y B deben poder enviarse mensajes entre sí (comunicación bidireccional) de manera interactiva (p. Ej., Leer líneas de stdin, avisos continuos o eventos como presionar un botón). Si lo hace más fácil, puede asumir una conversación alterna (es decir, después de que un usuario envía un mensaje, debe esperar una respuesta antes de enviar su próximo mensaje)
- Se permiten los idiomas incorporados (no es necesario escribir sus propios métodos criptográficos o de redes si ya son compatibles).
- El formato de comunicación subyacente depende de usted.
- Los pasos de comunicación dados anteriormente son un ejemplo, pero no es necesario que los siga (siempre y cuando se comparta la información necesaria y ningún intermediario pueda calcular la clave o los mensajes compartidos)
- Si los detalles necesarios para conectarse a su servidor no se conocen de antemano (por ejemplo, si escucha en un puerto aleatorio), estos detalles deben imprimirse. Puede suponer que se conoce la dirección IP de la máquina.
- No se requiere el manejo de errores (por ejemplo, direcciones no válidas, conexiones perdidas, etc.).
- El desafío es el código de golf, por lo que gana el código más corto en bytes.
p
yg
permitido?