Asegúrese de que un archivo solo pueda ser descifrado después de una fecha específica

El tiempo es relativo. La criptografía vive en el mundo etéreo de las máquinas informáticas abstractas: hay máquinas que pueden hacer operaciones. Las máquinas más grandes pueden hacer operaciones más rápido. No hay un reloj que puedas imponer; El tiempo físico no tiene sentido. En otras palabras, si un atacante quiere obtener su archivo antes, solo tiene que comprar una computadora más rápida.

Ahora uno todavía puede hacer un esfuerzo. Puede estar interesado en los rompecabezas de bloqueo de tiempo . La idea es poder crear una instancia de problema que sea fácil de construir pero costosa de abrir, donde el costo es configurable. La solución encontrada por Rivest, Shamir y Wagner (que sé, este es el único rompecabezas práctico de bloqueo de tiempo conocido hasta ahora) funciona de la siguiente manera:

• Genere un módulo RSA aleatorio n = pq donde p y q son primos grandes (y también < em> p = 3 mod 4, y q = 3 mod 4).
• Genera un x módulo n al azar.
• Para algunos enteros w , defina e = 2 ^w , y calcule y = x^e mod n .
• Hash y con alguna función de hash, produciendo una cadena K que usas como clave para cifrar el archivo que deseas sincronizar.
• Publique x , n , w y el archivo cifrado. Deseche p , q , y y K .

El punto difícil es que computar y , en general, tiene un costo proporcional a w : es una sucesión de w Cuadros modulares. Si w está en el rango de miles de millones o más, entonces esto será caro. Sin embargo, cuando se conocen los factores p y q , entonces uno puede calcular e módulo p-1 y < em> q-1 , que será mucho más corto, y el cálculo de y se puede realizar en unos pocos milisegundos.

Por supuesto, esto no garantiza una publicación en una fecha específica; más bien, garantiza un mínimo de esfuerzo para desbloquear el rompecabezas. La conversión entre esfuerzo y fecha depende de cómo intenten los atacantes ...

El rompecabezas de bloqueo de tiempo expresado anteriormente tiene algunas características agradables, en particular, es impermeable al paralelismo. Si intenta romper uno y tiene dos computadoras, no obtendrá más rápido de lo que podría hacer con una sola computadora.

En un contexto similar, este rompecabezas de bloqueo de tiempo se usa en la función de hashing de contraseña de Makwa , candidato a la actual PHC . En el hashing de contraseñas, desea un esfuerzo de apertura configurable (aunque dentro de un marco de tiempo mucho más corto, generalmente menos de un segundo).

Si no desea involucrar a un tercero, usted (la parte que encripta el archivo) podría simplemente liberar la clave para descifrar el archivo en la fecha de destino.

He visto esto hecho para lanzamientos de videojuegos. Los clientes pueden descargar por adelantado una copia encriptada del juego. Luego, cuando llega el momento del lanzamiento, la compañía de juegos simplemente libera la tecla. De esa manera, las personas pueden comenzar a jugar inmediatamente cuando se lanza el juego, sin necesidad de esperar una descarga.

Coloque con cuidado una nave espacial que transmita la clave de descifrado en órbita alrededor de un agujero negro. La fuerza de la gravedad retrasará el mensaje hasta el momento adecuado.

O simplemente puede hacer como personas normales y colocar la nave espacial de transmisión clave a un número apropiado de años luz de distancia de la audiencia prevista.

Use el intercambio secreto para dividir una clave de cifrado privada en N partes, parametrizada para permitir la reconstrucción de la clave con K o más partes, donde K <= N . Se realiza mejor utilizando CRM, como se describe en la siguiente página:

enlace

Luego envíe cada parte a los servicios independientes que acepten publicar en una fecha determinada en el futuro.

Hasta K-1 de los servicios pueden "desertar" publicando temprano sin afectar el esquema.

Hasta N-K de los servicios puede fallar en la publicación, también sin afectar el esquema.

Creo que para diseñar correctamente tu sistema, necesitas definir qué significa "tiempo" en tu contexto y por qué elegiste un momento específico . Suponiendo que su mensaje se va a descifrar el 29 de agosto de 1997 a las 02:14 AM, ¿cuál es la diferencia entre el momento anterior y el momento posterior a la fecha límite? ¿Por qué específicamente esta fecha? Es posible que pueda utilizar este evento como un componente de su esquema.

Por ejemplo, si espera que Skynet se vuelva consciente de sí mismo en la fecha en cuestión y desee que el mensaje se descifre solo después de que Skynet se vuelva consciente de sí mismo, entonces la clave de descifrado podría ser 'skynet_became_self_aware'. Es poco probable que sea forzado a la fuerza bruta, especialmente porque contiene una palabra que no está en el diccionario. Sin embargo, es muy probable que se intente con después de que ocurra el evento, especialmente si hay sistemas automatizados que intentan usar la fuerza bruta, lo que agregará la palabra 'skynet' a sus diccionarios en el momento adecuado.

Este esquema no es perfecto, ya que aún existe la posibilidad de que la fuerza forzada bruta de la clave e incluso después de la fecha en la que no haya recursos adecuados en uso para descifrarla. Sin embargo, este esquema tiene el beneficio adicional de que si el evento cuya fecha elige ocurre antes o después de lo esperado , el mensaje no se descifrará demasiado tarde o demasiado pronto.

Si la única parte de confianza es usted mismo y no puede garantizar que esté disponible cuando el contenido del mensaje se haga público, entonces lo que puede hacer en su lugar es construir un dispositivo (físico o virtual) que haga automáticamente la clave pública en el momento requerido, y luego ocultar el dispositivo.

Una forma fácil sería comprar un servidor virtual de Amazon o cualquiera de cientos de otras compañías, tal vez varios servidores en países extranjeros, bajo una identidad diferente, que no sea rastreable a la identidad de la persona que publicó el mensaje. Lo ideal sería comprar este servidor varios años antes de liberar el mensaje. Estos servidores simplemente se sientan y esperan, sin hacer nada (tal vez alojando un correo electrónico o servidor FTP de apariencia inocente), hasta la fecha especificada, y luego publican la clave de descifrado a través de múltiples canales públicos para satisfacer su definición de hacer pública la información. "

Nadie sabría siquiera que estos servidores existen, por lo que nadie los está buscando; y su propósito puede ser lo suficientemente ofuscado como para que nadie que tropiece con ellos se dé cuenta de lo que está haciendo. Hay muchos millones de servidores conectados a Internet, los tuyos simplemente se pierden entre el ruido.

Esto sería suficiente a menos que el público considere que el mensaje es lo suficientemente importante como para que haya un esfuerzo mundial para ubicar la clave, en una escala que inspiraría a los gobiernos a realizar análisis de tráfico sofisticados en todos los servidores virtuales y físicos. que se puso en línea en la última década, y luego examina manualmente todos los archivos y códigos en cada uno de los (millones de) sospechosos, en busca de información oculta.

En ese caso, podría ocultar el dispositivo aún más. Si realmente desea hacer este estilo James Bond, coloque el mensaje en una cinta conectada a un transmisor de radio de onda corta con una batería de reserva en la Antártida (donde podría quedar enterrada en la nieve), o en una remota selva de Brasil (donde podría ser dañada por animales), o en el fondo del océano, con una bolsa de aire inflada químicamente para flotar a la superficie en la fecha y hora especificadas (donde podrían corroerse, ¿es posible que el Lago Superior sea más seguro?), o enterradas a poca profundidad, con una antena similar a un periscopio.

Por supuesto, la dificultad y el costo de cualquiera de estas opciones depende de cuánto tiempo quiera mantener el dispositivo oculto. Si es un siglo, es probable que los protocolos de Internet hayan cambiado y que cualquier cosa más compleja que la radio analógica de onda corta no sea factible. (Y puede ser que nadie escuche onda corta tampoco). Si solo son unos pocos meses, su dispositivo podría ser simplemente un teléfono inteligente prepago conectado a una batería externa y caer en algún lugar moderadamente oscuro. Ya hay muchos sensores remotos basados en células en el mercado, que realizan automáticamente una llamada telefónica o una conexión a Internet cuando se cumplen algunos criterios, por lo que esto sería casi indetectable, se vería para la compañía de teléfonos celulares como otro más. estos dispositivos cada vez más ubicuos.

No estoy completamente seguro de si este documento sobre el cifrado de bloqueo de tiempo se ha inspirado en esta discusión pero sería la solución más formal a la pregunta "¿Cómo construir el cifrado de bloqueo de tiempo?", que es una reformulación de "¿Cómo proteger los datos para que solo puedan ser descifrados después de una fecha específica? "

Pero ahora vamos a entrar en detalles sobre cómo funciona esto.

Uno básicamente construye un reloj de referencia utilizando el cómputo disponible públicamente (como los cómputos de Bitcoin). Por lo tanto, hasta donde entiendo esto, esto depende de la cadena de bloques de Bitcoin para alcanzar un cierto tamaño (crece cada 10 minutos, con relativa precisión). A medida que esto suceda, el "cifrado de testigo" permitirá a todos descifrar los datos (donde el blockchain contiene algún testigo, que solo estará disponible cuando la cadena tenga un tamaño determinado). Como es imposible romper los esquemas de encriptación testigo y ser más rápido que toda la red de bitcoin (con más de 300 PHashes / s a partir de ahora), es poco probable que un atacante pueda obtener los datos desencriptados ( que puede ser una clave) antes de que expire el bloqueo de tiempo.

También se puede notar que este esquema no sufre altos costos (viajes espaciales), no necesita terceros confiables (no necesita confiar en la red Bitcoin) y la parte de encriptación no necesita estar disponible en el momento del descifrado y las partes con recursos computacionales altos tienen pocas posibilidades de conocer el secreto anterior .

Uno también puede querer leer este documento , siguiendo un enfoque similar y reduciendo la seguridad al problema de subconjunto , que se cree que es difícil.

Cifre el archivo con una clave muy larga, divídalo en partes y entregue cada parte a una persona de confianza junto con las instrucciones de no entregar dicha parte hasta la fecha indicada. Puede agregar algo de redundancia entregando cada parte a más personas, en caso de que una de ellas fuera golpeada por un autobús.

Por supuesto, una red de computadoras podría hacer esto al igual que los humanos. De hecho, el algoritmo de reorientación de la dificultad basada en el tiempo de Bitcoin, aunque tiene un propósito diferente, se basa en principios similares. Sin embargo, no sé que exista ningún programa para este propósito.

En el documento citado en la pregunta se da un enfoque hipotético (lo que es muy interesante, a pesar de la gramática torpe ocasional) que consiste en utilizar un software que contiene una carga útil cifrada, lo que desencadena algún valor externo como una noticia. y haga que gente de todo el mundo lo ejecute hasta el momento en que se ejecute la carga útil. Esto no cumple con el requisito de "fecha / hora conocida públicamente", pero la premisa es un buen punto de partida. Un servicio distribuido, al igual que TOR / Bitcoin, podría ejecutarse de manera P2P por muchas personas en todo el mundo con el único propósito de mantener las versiones clave que dependen del tiempo. Esto se conoce como Tolerancia de falla bizantina (también conocido como Problema de los generales bizantinos, vea enlace para una explicación completa) pero en este caso la La "falla" contra la que debe protegerse sería el lanzamiento prematuro de la información, por lo que no es una aplicación directa, sino tangencial que requeriría un nuevo conjunto de técnicas.

Se podría usar una codificación cuidadosa para crear un esquema en el que cada usuario tenga una pequeña parte de la clave, muchos usuarios tengan copias redundantes de piezas individuales, y existe un medio sólido para evitar la "recolección" prematura, incluida la evasión de malware y la multitarea. soporte de plataforma (donde las claves se dividen intencionalmente de manera equitativa entre los usuarios que ejecutan el software en Windows, IOS, Android, OS X, Linux, etc.)

Casi debería funcionar como una inversa de la cadena de bloques de bitcoin, donde en lugar de que cada usuario tenga una copia verificable de lo que ocurrió en el pasado, cada usuario tiene una porción única de lo que ocurrirá en el futuro, y solo a medida que el futuro se dirige al presente, cada bloque se lanza al mundo para su consumo. En este caso, se podría utilizar una técnica de cebolla a la TOR, por lo que cada parte de su clave secreta se envió a un conjunto de usuarios, la transfiguraron y la enviaron para conservar solo una clave de traducción, y eso siguió funcionando para N rondas corriente arriba Cada capa podría tener su propio temporizador aleatorio para luego pasar el material hacia abajo, acercándose al origen donde el último temporizador contaría hacia abajo y provocaría la liberación de las partes clave para unirse en un conjunto de pares acordados y recibir un correo electrónico, o algo.

La única pieza faltante sería cómo evitar la colusión masiva, como una recompensa establecida para atraer a los usuarios suficientes para que renuncien a su material clave a cambio de una parte del bote, ya que no se puede asumir que muchos de ellos considera que su información en custodia tiene un > Valor 0 si se deja sin tocar. Sería deseable una forma de ofuscar completamente el material, de modo que cada usuario tenga una gran cantidad de datos sin saber qué segmentos de eventos estaban a su cuidado. Este es un problema interesante, por cierto.

En última instancia, la segunda ley de la termodinámica se interpone en tu camino. Mira tu texto plano como un sistema cerrado; solo puede aumentar la entropía.

La información de cifrado aumenta su entropía, pero tener la clave lo compensa. La entropía total de clave + texto cifrado es la misma que la entropía del texto simple.

Cuando destruyes la clave, la entropía general del sistema aumenta. Lo que significa que nunca podrá regresar (excepto con una entrada masiva de energía a través del poder de cómputo de fuerza bruta).

Esto significa que debes mantener la clave; no puedes destruirlo temporalmente.

Por supuesto, puede ocultar la clave, cifrarla nuevamente, mantenerla con un tercero de confianza, etc. Pero la clave siempre debe estar en algún lugar .

Cifre con un XOR pad de una sola vez y tenga algún tipo de automatización para enviar el flujo de cifrado a la hora indicada. Una vez, las almohadillas XOR son completamente resistentes a los ataques de patrón porque no hay patrón.

Para que esto tenga éxito, debes

• genere la clave usted mismo y no la comparta con nadie
• construir automatización de entrega temporizada a prueba de manipulaciones
• oculte el verdadero propósito del sistema de entrega cronometrada asegurándose de que hace un buen trabajo al realizar un propósito de infraestructura inmensamente aburrido pero esencial, de modo que nadie intente investigar, desenchufar, modificar o reutilizarlo
• destruye todas las copias de la almohadilla XOR fuera del sistema de entrega temporizada a prueba de manipulaciones

Tenga en cuenta que para estar realmente a prueba de manipulaciones, tiene que responder a la manipulación manipulando muy bien la almohadilla XOR. Afortunadamente, dado que los parches XOR contienen datos aleatorios, no hay forma de saber si se ha autodestruido o no.

Podrías ocultar el pad XOR de forma esteganográfica para evitar que el curioso se pregunte por qué alguien ocultaría una gran cantidad de datos aparentemente aleatorios.

Me doy cuenta de que hay elementos de seguridad por oscuridad en este enfoque. Eso es inevitable; Si supiera de tal sistema y quisiera atacarlo, comenzaría por privarlo de poder y desoldar todo lo que parecía almacenamiento para poder examinar el contenido sin permitir que responda a la manipulación. Incluso entonces podrías insertar un UPS.

El ataque informado depende del conocimiento a priori del sistema, comenzando con su existencia. Si solo el remitente sabe de su existencia, esto puede ser robusto. Una estrategia común es evitar que cualquiera de las partes construya un fragmento lo suficientemente grande como para tener un propósito coherente.

Podría ser posible construir un sistema basado en blockchain que proporcione a cada bloque en la futura carga útil adicional que el minero de ese bloque tenga que resolver.

Cada bloque podría crear una clave privada para una clave pública que se conoce de antemano. Cifra tu mensaje con una clave simétrica y luego cifra esa clave con las claves públicas conocidas de los próximos 10000 bloques que se extraerán.

Si la red reúne más poder de cómputo, puede agregar problemas numéricos adicionales a los bloques que se están extrayendo para mantener el tiempo de generación de bloques en un promedio de 10 minutos.

Si la red pierde poder de procesamiento, sin embargo, tomará más tiempo para que el archivo se pueda cifrar correctamente.

Usando fuentes no completamente confiables, puede enviar la clave de descifrado por correo postal a la parte de confianza. Esto no confía completamente en la parte, ya que no pueden publicar antes, pero no pudieron publicar en absoluto, por lo que, para minimizar el riesgo, se pueden usar múltiples fuentes confiables.

Para aumentar el tiempo de espera, puede usar un servicio en línea para pedirles que envíen la postal desde fuera del país (pero eso lo haría vulnerable a los ataques del hombre en el medio), por ejemplo enlace para los hablantes de holandés, pero estoy seguro de que existen servicios similares en otros lugares.

Esto funciona para activarse en el momento de un evento que causa.

Haga una automatización (vea la respuesta de Peter Wone) que verifique si tiene una página de wikipedia en su nombre. y dispara si lo hace.

Esto obviamente es muy sensible al disparador & Solo funciona si eres desconocido en el momento de la construcción.

Puede resolver ambos problemas incluyendo la condición de que cierta información sobre el evento esté contenida en la entrada de Wikipedia.

Estoy seguro de que al usar Google hay un par de otros desencadenantes interesantes que se encuentran

Como han dicho otros, no se puede proporcionar descifrado en una fecha específica, sino mediante un esfuerzo específico. En cuanto a un solo algoritmo de propósito, el esfuerzo está fuertemente relacionado con el interés de las partes que intentan desbloquearlo antes y, por lo tanto, es bastante desconocido.

Por lo tanto, la mejor solución puede involucrar vincular el rompecabezas a un interés mucho más grande e inerte. Lo más factible que me vino a la mente en estos días es la cadena de bloques de Bitcoin. Como los bitcoins son una realidad desde hace algunos años y su generación involucra grandes cantidades de hardware en la actualidad, tenemos buenas posibilidades de predecir su tasa de generación en un plazo razonable a largo plazo (tal vez semanas o meses).

Me pregunto si esto podría hacerse. Lo que se necesitaría es un enlace entre los bitcoins generados y la clave necesaria. No podemos confiar en que se genere un solo bitcoin, pero tenemos que usar algo así como un pequeño n de una gran cantidad previamente elegida de m de bitcoins posibles proporcionará descifrado. Esto es posible con el 'intercambio secreto' ( enlace ). Como los hash de bitcoin dependen de las transacciones realizadas anteriormente, sería bastante complicado construir m rompecabezas que se resolverían con el hash de bitcoins algún día.

La única forma en que puede hacer esto es asegurarse de que a) usted controla el código que realiza el descifrado, yb) que obtiene la fecha de una fuente inmutable. Por ejemplo, si incluye como parte de su descifrado, una llamada a un servicio web de reloj atómico (idealmente, una segura que no pueda ser falsificada). En ese momento, simplemente verifica la fecha y, si es menor que la fecha deseada, no se molesta en descifrar.