Coffre-fort temporel

Mars 2023

J'ai sélectionné quelques papiers relatifs au sujet qui nous intéresse, à commencer par ceux des cryptographes réputés.

Time-lock puzzles and timed-release Crypto

Il s'agit de l'article jugé plus ou moins fondateur sur le sujet, évidement fait par des cakes puisqu'il s'agit du R et du S du système de crypto RSA, alors on ne moufte pas s'il vous plait. C'est ça, je vais me gêner.

Ils proposent deux approches :

There are two natural approaches to implementing timed-release crypto :

  1. Use "time-lock puzzles": computational problems that cannot be solved without running a computer continuously for at least a certain amount of time.
  2. Use trusted agents who promise not to reveal certain information until a specified date.

Certes, mais pas que.

Et d'abord, pour commencer, quelle est la définition du temps ? Ah ça, ils se sont bien gardés d'en parler, si jamais ils y ont pensé, ce qui n'est pas évident.

Time-lock puzzles

Les time-lock puzzles sont des problèmes solvables seulement en un certain temps, qu'on espère présentant un minimum, et non parallèlisables (comme l'exemple donné, que j'aime bien : ce n'est pas en ayant deux femmes enceintes en parallèle qu'on aura un bébé en 4 mois et demi).

Les auteurs donnent ensuite un exemple pratique. En 1999, Ron Rivest propose le défi LCS35, qui utilise des élévations au carré en séquence.

LCS35
  • La résolution de ce défi n'est possible qu'en calculant un nombre avec les carrés successifs.
  • Selon la loi de Moore et la puissance de l'époque, Rivest estimait à 35 ans la résolution du défi (2034).
  • Vingt ans plus tard (2019), Bernard Fabrot, un autodidacte belge, a résolu le défi après quatre ans d'efforts.

Eh bien, si même les kadors se font avoir, c'est bien parti.

Tiers de confiance

L'autre solution est le tiers de confiance.

Mais bon, entamer le problème en disant qu'on fait confiance, ça facilite les choses.

Je ne sais pas pourquoi ils s'embarquent immédiatement dans des problèmes de répartition de clés entre plusieurs tiers au lieu de commencer par un truc simple. Le truc facile est proposé à la fin de l'article. Evidement en langage "de cryptographe".

Le premier truc qui me gonfle vraiment dans tous les articles de ce genre, c'est le coup du tiers de confiance. Soit vous faites confiance à un tiers, et le problème est réglé, soit vous ne lui faites pas confiance. Évidemment que le problème de fond de la confiance est crucial, comme d'habitude.

Voici en langage simple une solution évidente :

  1. Je fais confiance au tiers, qui est un site web (par définition, axiome de base)
  2. Le site web possède une horloge atomique (et je lui fais confiance par définition, ce genre d'assertion n'est JAMAIS évoquée dans les papiers)
  3. Le site web va produire à l'avance une liste de clés publiques/clé privées, une pour chaque heure dans le futur, 100 ans à l'avance (cela représente moins d'un million de clés, pas de quoi fouetter un chat).
  4. Les clés privées correspondantes sont stockées dans son coffre (je lui fais confiance)
  5. Les clés publiques sont publiées sur le site
  6. Le site web va publier, à chaque heure, la clé privée correspondant à la clé publique.

Résultat des courses, pour publier un document secret à l'heure dite :

  1. Je chiffre le document avec la clé publique publiée sur le site web de confiance
  2. Je détruis le document original et j'envoie une copie du chiffré "à qui n'en veut" (je le publie sur mon site perso par exemple, n'importe qui peut le prendre)

À l'heure dite :

  1. Le site web publie la clé privée
  2. N'importe qui peut déchiffrer mon document chiffré avec la clé sur son PC perso

Et le tour est joué. Pas besoin d'être grand clerc.

Inutile de faire toutes ces simagrées une fois que vous avez confiance.

On notera que cela pourrait être une offre gouvernementale, utile à tous. Après, pour les vrais paranoïaques comme Rivest, on peut s'arranger pour répartir le secret sur plusieurs sites avec les techniques habituelles où il faudra au moins n tiers pris parmi m pour déchiffrer (donc n gouvernements) : un gouvernement pourrait tomber sans conséquence pratique.

J'ai ensuite découvert que c'était décrit dans l'article suivant, évidemment en plus compliqué.

Time-Lapse Cryptography

Abstract: The notion of "sending a secret message to the future" has been around for over a decade. Despite this, no solution to this problem is in common use, or even attained widespread acceptance as a fundamental cryptographic primitive. We name, construct and specify an implementation for this new cryptographic primitive, "Time-Lapse Cryptography", with which a sender can encrypt a message so that it is guaranteed to be revealed at an exact moment in the future, even if this revelation turns out to be undesirable to the sender. Our solution combines new ideas with Pedersen distributed key generation, Feldman verifiable threshold secret sharing, and El Gamal encryption, all of which rest upon the single, broadly accepted Decisional Diffie-Hellman assumption. We develop a Time-Lapse Cryptography Service ("the Service") based on a network of parties who jointly perform the service. The protocol is practical and secure: at a given time T the Service publishes a public key so that anyone can use it, even anonymously. Senders encrypt their messages with this public key whose private key is not known to anyone - not even a trusted third party - until a predefined and specific future time T + at which point the private key is constructed and published. At or after that time, anyone can decrypt the ciphertext using this private key. The Service is envisioned as a public utility publishing a continuous stream of encryption keys and subsequent corresponding time-lapse decryption keys. We complement our theoretical foundation with descriptions of specific attacks and defenses, and describe important applications of our service in sealed bid auctions, insider stock sales, clinical trials, and electronic voting.

Ce qui me fait rigoler, c'est qu'une fois de plus, le temps n'est pas défini. Et même dans les assumptions, ben ils ne supposent pas que l'horloge fonctionne bien. C'est quand même curieux pour un article qui commence par time, non ?

Timed-Release Encryption Revisited

Abstract. Timed-release encryption (TRE) is a two-factor encryption scheme combining public key encryption and time-dependent encryption- decryption requires a trapdoor which is kept confidential by a timeserver until at an appointed time. This paper revisits two recent results. In ESORICS 2007, Chalkias et al. proposed an efficient anonymous TRE scheme. Unfortunately, we show the security threats of their scheme in the presence of a curious time-server and an impatient recipient. Recently, Chow et al. proposed an encryption scheme in the standard model which can be used as TRE. Nevertheless, only confidentiality is guaranteed. We demonstrate how to support pre-open capability, which is often desirable in applications of TRE. Our extension also enables only the recipient to know the release-time from the ciphertext. This feature is not considered in previous notion of release-time confidentiality.

Ah là là, encore une fois les cryptographes se font plaisir avec des trucs bien compliqués, des syntaxes pénibles et au fond du compte, et bien que dalle sur le temps. Ils font même des simagrées car ils veulent plus ou moins cacher (ou pas) la date à laquelle le secret doit être révélé, et là, c'est space 😀😀, vu qu'on ne voit rien concernant une référence de temps absolue crédible… Je me suis encore fait avoir avec le titre encore parce qu'il y a plein d'autres papiers sans aucune référence au temps.

Time in cryptography

Résumé

Le voyage dans le temps a toujours été un sujet fascinant, que ce soit en littérature ou en physique. De même, en cryptographie, nous nous demandons comment conserver des données confidentielles pendant un certain temps. Dans cette thèse, nous étudions comment faire voyager des informations privées vers le futur. Ce travail est divisé en trois parties :

  1. le chiffrement temporisé (timed-release encryption),
  2. le chiffrement de témoin (witness encryption)
  3. et l'auto-chiffrement (self-encryption).

(et j'ai coupé le résumé, trop long).

Contient un état de l'art récent: on lira le chapitre 3. Mais rien sur l'horloge, comme d'habitude, on suppose qu'elle marche bien, en fait aucune réflexion sur la définition du temps, c'est quand même étonnant concernant une thèse dont le premier mot du titre est time.

Les blockchains

Dézinguons cette histoire de blockchain.

Je n'aime pas les trucs compliqués, et je n'ai jamais vraiment compris pourquoi on devait faire cette histoire de preuve de travail -sauf pour payer ceux qui stockent les blockchains, et encore: si on fait confiance à la blockchain, le problème est clos. Mais bon, passons sur mes états d'âme.

Pour commencer, Liu en 2018 n'est pas le premier à proposer d'utiliser une blockchain :

Ensuite, il faudra faire confiance à une espèce de base de données, répartie, où on veut utiliser la propriété des blocs qui sont enchainés les uns après les autres avec un rythme plus ou moins basé sur un calcul intensif (la fameuse preuve de travail) :

  • On n'est pas à l'abri que plus tard, une amélioration perturbera la vitesse des calculs requis pour la preuve de travail. Alors les 10 minutes entre chaque bloc, on peut raisonnablement se dire que cela pourrait changer, et par conséquent la date de libération n'est pas certaine.
  • Ces chaines de blocs peuvent disparaitre pour une raison ou pour une autre, genre "elle a été hackée", ou "les gens ne lui font plus confiance et en utilise une autre bien mieux", et on se retrouvera le bec dans l'eau.

Et de toutes manières, il existe un problème de fond de définition du temps. C'est étonnant de proposer une solution où il n'y a pas de "vraie horloge" pour un coffre temporel, non ?

Les articles pour ceux qui veulent se faire leur opinion :

How to build time-lock encryption

  • How to build time-lock encryption Jia Liu · Tibor Jager · Saqib A. Kakvi · Bogdan Warinschi Received: 21 February 2017 / Revised: 19 January 2018 / Accepted: 20 January 2018

Abstract: Time-lock encryption is a method to encrypt a message such that it can only be decrypted after a certain deadline has passed. We propose a novel time-lock encryption scheme, whose main advantage over prior constructions is that even receivers with relatively weak computational resources should immediately be able to decrypt after the deadline, without any interaction with the sender, other receivers, or a trusted third party.

We build our time-lock encryption on top of the new concept of computational reference clocks and an extractable witness encryption scheme.

We explain how to construct a computational reference clock based on Bitcoin.

We show how to achieve constant level of multilinearity for witness encryption by using SNARKs.

We propose a new construction of a witness encryption scheme which is of independent interest : our scheme, based on Subset- Sum, achieves extractable security without relying on obfuscation. The scheme employs multilinear maps of arbitrary order and is independent of the implementations of multilinear maps.

Un extrait, le début de la contribution :

We introduce a new primitive called computational reference clocks as an extension of the standard computational model, which provide a novel and very realistic method to "emulate" real-world time in a computational model.

We show that the widely-used cryptocurrency Bitcoin provides a practical example of such a reference clock, which shows that the assumption that these objects exist in practice is reasonable.

"reasonable" et "emulate real world time" : dès le départ, ils se tirent une balle dans le pied. Ah là là.

Practical Time-Release Blockchain

Abstract: Time-release cryptography is a special encryption technique that allows a message to be hidden for some time. The previous schemes have shortcomings in that the encryptor should predict the decryptor's computing power precisely or the trusted agent should be always available. In this paper, we propose a new, practical time-release blockchain, and find the key to decrypt the content after a certain time.

In order to verify the effectiveness of the blockchain system automatically, which uses the proof-of-work (PoW) and the consensus algorithm in the the proposed technique, we have implemented a prototype version of our blockchain system using Python.

The proposed method has the following advantages.

  • First, the decryption time is automatically adjusted, even if the miner's computing power changes over time.
  • Second, unlike previous time-lock puzzle schemes, our algorithm does not require additional computation work for solving the puzzle.
  • Third, our scheme does not need any trusted agents (third parties).
  • Fourth, the proposed method uses standard cryptographic algorithms.

A noter : il existe une notion de temps dans le Bitcoin -à ne pas confondre avec nos histoires :

Je n'insisterai pas sur ces histoires de blockchain. Évidemment que ça ne marchera pas sur le long terme, c'est plombé à la base.

VDF
Verifiable Delay Function

Les VDF : les Verifiable Delay Function. Un truc que j'ai découvert tardivement, et il existe un site consacré aux recherches sur ce thème, ainsi qu'une alliance : VFD research

Il s'agit des fonctions du genre de celles proposées par Rivest :

  • qui prennent un certain temps à calculer,
  • qu'on ne peut pas accélerer par parallélisme,
  • et dont le résultat est aisément vérifiable.

Avec un nom pareil, on pouvait s'en douter.

We study the problem of building a verifiable delay function (VDF). A VDF requires a specified number of sequential steps to evaluate, yet produces a unique output that can be efficiently and publicly verified.

VDFs have many applications in decentralized systems, including public randomness beacons, leader election in consensus protocols, and proofs of replication.

We formalize the requirements for VDFs and present new candidate constructions that are the first to achieve an exponential gap between evaluation and verification time.

This problem is even harder in adversarial systems like blockchain. Nodes in the network can't trust an external source of time or any timestamp that appears in a message. Hashgraph for example, solves this problem with a "median" timestamp.

Each message that is seen by the network is signed and timestamped by a supermajority of the network. The median timestamp for the message is what Hashgraph calls "fair" ordering.

Each message has to travel to the supermajority of the nodes in the system, then after the message collects enough signatures, the entire set needs to be propagated to the entire network. As you can imagine, this is really slow.


Mais bon, il s'agit de fonctions exécutées sur des processeurs, le temps réel (atomique si vous préférez) n'est guère impliqué, c'est juste une conséquence.

Il existe beaucoup plus d'articles que ceux que je cite ici qui concernent la cryptographie et le temps, mais je n'en ai trouvé aucun qui s'intéresse un temps soit peu à la notion du temps. Etonnant.

Il va donc falloir que je comble cette lacune pour proposer quelque chose qui fasse sens.