Dans le livre pour enfants, La baleine et l'escargote, cette dernière revient chez elle après une aventure inattendue au bout du monde pour entendre tous ses proches déclarer « Comme le temps a passé ! » et « Comme tu as grandi ! ». Quatre ans se sont écoulés depuis la dernière fois où nous avons écrit sur LavaRand et, pendant ce temps, le récit décrivant la manière dont Cloudflare s'appuie sur des sources d'entropie physiques afin de renforcer la sécurité d'Internet a poursuivi son chemin pour devenir une source d'intérêt pour de nombreuses personnes. Ce qui n'était initialement qu'un exemple unique de source d'entropie physique (les lampes à lave) s'est depuis développé et diversifié. Les lignes qui suivent ont pour objectif de vous informer sur l'histoire de LavaRand. Cet article de blog traite des nouvelles sources de « chaos » ajoutées à LavaRand et de la manière dont vous pouvez utiliser ce chaos maîtrisé dans votre prochaine application. Nous aborderons comment l'aléatoire public peut ouvrir de nouveaux scénarios d'aléatoire publiquement digne de confiance (imaginez ne plus avoir à prendre les adeptes du « tirage aléatoire » au mot lorsqu'ils affirment que le résultat n'est manipulé en aucune façon. Enfin, nous discuterons du chiffrement temporisé (timelock), qui constitue un moyen de s'assurer qu'un message ne puisse être déchiffré avant un moment choisi de l'avenir.
Origines de LavaRand
L'entropie issue de notre mur de lampes à lave de San Francisco joue depuis longtemps un rôle dans le caractère aléatoire qui sécurise les connexions établies via Cloudflare.
Les serveurs de Cloudflare traitent collectivement plus de 55 millions de requêtes HTTP par seconde, dont la vaste majorité sont sécurisées à l'aide du protocole TLS afin d'assurer leur authenticité et leur confidentialité. Dans les faits, les protocoles cryptographiques tels que le TLS nécessitent une source sous-jacente d'aléatoire sécurisé, faute de quoi les garanties de sécurité s'effondrent.
L'aléatoire sécurisé utilisé en cryptographie doit être impossible à distinguer, sur le plan informatique, du « véritable » aléatoire. Pour cela, il doit à la fois réussir les tests d'aléatoire statistique et le résultat doit être imprévisible pour tout adversaire limité par le calcul, quelle que soit la quantité de résultats précédents déjà observés par cet adversaire. Le moyen classique d'y parvenir consiste à prendre une « graine » et à l'introduire dans un générateur de nombres pseudo-aléatoires sécurisé de manière cryptographique (Cryptographically Secure Pseudorandom Number Generator, CSPRNG) capable de produire un flux pratiquement infini d'octets imprévisibles sur demande. Les propriétés d'un CSPRNG garantissent que tous les résultats obtenus sont virtuellement impossibles à distinguer des résultats réellement aléatoires pour quiconque ne connaît pas son état interne. Toutefois, l'ensemble du processus dépend de l'existence d'une graine aléatoire sécurisée au départ. N'hésitez pas à vous référer à ce blog pour plus de détails sur l'aléatoire véritable par rapport au pseudo-aléatoire et à ce blog pour découvrir d'excellents exemples de ce qui peut mal tourner avec une graine aléatoire non sécurisée.
Pendant de nombreuses années, les serveurs de Cloudflare se sont appuyés sur des sources locales d'entropie (comme le moment précis de l'arrivée des paquets ou des événements clavier) pour alimenter leurs pools d'entropie. S'il n'y a aucune raison de penser que les sources locales d'entropie sur ces serveurs pourraient ne pas être sûres ou pourraient être facilement compromises, nous souhaitions néanmoins nous prémunir contre cette éventualité. Notre solution consistait à mettre en place un système permettant à nos serveurs de rafraîchir périodiquement leurs pools d'entropie à l'aide d'éléments aléatoires véritables issus d'une source externe.
L'idée nous amène ainsi à LavaRand. Depuis bien longtemps, « LavaRand » est le nom donné aux systèmes utilisés pour la génération d'éléments aléatoires (en premier lieu par Silicon Graphics en 1997). Cloudflare a lancé son instanciation d'un système LavaRand en 2017. Ce système recueille l'entropie issue du mur de lampes à lave situé dans notre bureau de San Francisco et la met à notre disposition via une API interne. Nos serveurs interrogent ensuite périodiquement cette API afin de récupérer des données aléatoires fraîches de LavaRand et de les incorporer à leurs pools d'entropie. Vous pouvez considérer les contributions de LavaRand comme un assaisonnement ajouté au mélange des pools d'entropie ! (Pour plus de détails techniques, consultez notre article de blog précédent).
Ajouter du chaos dans les bureaux
Depuis des années, les lampes à lave de notre bureau de San Francisco fonctionnent sans relâche afin d'assurer une source d'entropie fraîche à nos systèmes, mais elles ont maintenant des frères et sœurs à travers le monde pour les aider dans leur tâche ! La variété des sources d'entropie trouvées dans nos bureaux et issues de ces derniers a suivi Cloudflare dans sa croissance. L'équipe Places de Cloudflare travaille dur pour s'assurer que nos bureaux reflètent les divers aspects de nos valeurs et de notre culture. Plusieurs de nos agences les plus importantes comprennent des installations de systèmes physiques d'entropie et ce sont ces installations que nous nous sommes efforcés d'incorporer à LavaRand au fil du temps. L'attrait tangible et passionnant de ces systèmes réside dans le fait qu'ils reposent sur des mécanismes physiques que nous considérons intuitivement comme aléatoires. Les boules de « lave » flottant au sein des lampes à lave (les amas réchauffés remontent, tandis que les amas plus froids retombent) attirent notre attention, tout comme d'autres systèmes dynamiques imprévisibles (et souvent magnifiques) captent notre intérêt.
Les pendules imprévisibles de Londres
Les visiteurs de notre bureau de Londres peuvent voir un mur de pendules doubles dont les magnifiques oscillations constituent une autre source d'entropie pour LavaRand et pour le pool d'aléatoire dans lequel puisent les serveurs de Cloudflare.
Pour un œil non averti, les ombres des supports du pendule et celles projetées par les bras rotatifs sur le mur du fond peuvent sembler chaotiques. Si c'est bien le cas, cette installation devrait être considérée comme une grande réussite ! Les différentes conditions d'éclairage et ces ombres portées ajoutent au chaos capturé par cette source d'entropie.
En effet, même si ces bras se limitent à un mouvement en deux dimensions, la trajectoire qu'ils dessinent est étonnamment variée et on peut démontrer son caractère mathématiquement chaotique. Même en laissant de côté la résistance de l'air, la température et l'environnement, et en supposant que la mutation est totalement déterministe, le mouvement qui en résulte s'avère difficile à prédire sur le long terme. Le système en lui-même est particulièrement sensible aux conditions initiales. Associé à un comportement déterministe, cet état initial (c.-à-d. la manière dont il est mis en mouvement) produit une trajectoire unique qui se poursuit jusqu'à ce que le pendule s'immobilise et que le système soit à nouveau mis en mouvement par un collaborateur de Cloudflare à Londres.
Les mobiles hypnotiques d'Austin
Les nouveaux bureaux de Cloudflare à Austin, au Texas, ont récemment fêté leur première année d'ouverture. Cette agence apporte sa propre contribution à l'entropie physique : une installation de mobiles arc-en-ciel translucides suspendue au-dessus de l'entrée du bureau de Cloudflare, dans le centre-ville d'Austin. En tournoyant sur eux-mêmes, ces derniers reflètent ainsi l'évolution de la lumière et projettent des motifs colorés sur les murs de l'enceinte. Cette installation mêlant les mobiles suspendus et leurs ombres est très sensible à l'environnement physique, qui comprend l'ouverture et la fermeture des portes, les changements de température liés au chauffage, à la ventilation et à la climatisation, de même que la lumière ambiante. La scène fascinante et changeante produite par ce système chaotique est capturée périodiquement et introduite dans le flux d'éléments aléatoires de LavaRand.
Intégrer de nouvelles sources à LavaRand
Nous avons intégré les nouvelles sources de chaos de nos bureaux au système LavaRand (toujours appelé LavaRand bien qu'il comprenne désormais bien plus que des lampes à lave) de la même manière que les lampes à lave existantes, que nous avons précédemment décrites en détail.
Pour résumer, à intervalles réguliers, une caméra capture une image de l'état actuel de l'installation aléatoire. Le système sous-jacent étant véritablement aléatoire, l'image produite recèle un véritable caractère aléatoire. Même les ombres et les conditions d'éclairage évolutives jouent un rôle dans la production d'un résultat unique et imprévisible ! Nous devons également partager un autre secret : à un niveau fondamental, les capteurs d'images du monde réel constituent souvent une source de bruit suffisante pour que même les images prises sans avoir retiré le bouchon de l'objectif puissent fonctionner comme source d'entropie ! Nous considérons ce bruit comme un ajout fortuit au magnifique mouvement chaotique de ces installations.
Une fois que nous disposons d'une image fixe qui capture l'état de l'installation aléatoire à un moment donné, nous calculons une représentation compacte (un hachage) de l'image afin d'obtenir un résultat de taille fixe d'octets réellement aléatoires.
Les octets aléatoires sont ensuite utilisés comme entrée (avec la graine précédente et des éléments aléatoires issus des sources d'entropie locales du système) au sein d'une fonction de dérivation de clé (Key Derivation Function, KDF) afin de calculer une nouvelle graine aléatoire, introduite ensuite dans un générateur de nombres pseudo-aléatoires sécurisé de manière cryptographique (CSPRNG) capable de produire un flux pratiquement infini d'octets imprévisibles à la demande. Les propriétés d'un CSPRNG garantissent que tous les résultats obtenus sont virtuellement impossibles à distinguer des résultats réellement aléatoires pour quiconque ne connaît pas son état interne. LavaRand expose ensuite ce flux d'éléments aléatoires via une API interne simple au sein de laquelle le client peut demander de nouveaux éléments aléatoires.
seed = KDF(new image || previous seed || system randomness)
rng = CSPRNG(seed)
…
rand1 = rng.random()
rand2 = rng.random()
Comment puis-je utiliser LavaRand ?
Les applications utilisent généralement les éléments aléatoires sécurisés sous l'une des deux variantes suivantes : privée et publique.
L'aléatoire privé est utilisé pour générer des mots de passe, des clés cryptographiques, des identifiants utilisateur et d'autres valeurs destinées à rester secrètes pour toujours. Comme nous l'avons décrit précédemment, nos serveurs demandent périodiquement à LavaRand de nouveaux éléments aléatoires privés afin de mettre à jour leurs pools d'entropie. De ce fait, l'aléatoire de LavaRand est essentiellement accessible au monde extérieur ! Un moyen facile pour les développeurs d'accéder à l'aléatoire privé de LavaRand consiste à utiliser la fonction getRandomValues de l'API Web Crypto depuis un Cloudflare Worker ou d'utiliser un aléatoire déjà préconstruit, comme csprng.xyz (source).
L'aléatoire public se compose de valeurs aléatoires imprévisibles et impartiales, accessibles à tous une fois qu'elles sont publiées. C'est d'ailleurs pour cette raison qu'elles ne doivent pas être utilisées pour générer des clés cryptographiques. Les numéros gagnants de la loterie et le tirage à pile ou face au début d'un événement sportif sont de bons exemples de valeurs aléatoires publiques. L'utilisation d'une pièce à deux faces ne constituerait pas une source d'entropie impartiale et imprévisible, et aurait des répercussions considérables sur le monde des paris sportifs.
En plus d'être imprévisible et impartial, il est également souhaitable que l'aléatoire public soit digne de confiance, de sorte que les consommateurs d'aléatoire soient assurés que les valeurs ont été produites fidèlement. Peu de personnes achèteraient des billets de loterie s'ils pensaient que le billet gagnant allait être choisi de manière injuste ! En effet, il existe des cas connus de délit d'initiés dans lesquels des agents corrompus ont détourné l'aléatoire public à des fins d'enrichissement personnel, comme cet employé d'une loterie d'État qui a coopté le générateur de nombres aléatoires de la loterie afin de permettre à ses amis et à sa famille de gagner des millions de dollars.
L'un des problèmes fondamentaux de l'aléatoire public repose sur la nécessité de faire confiance à l'autorité qui produit les résultats aléatoires. Le fait de faire confiance à une autorité bien connue comme le NIST peut suffire pour de nombreuses applications, mais pourrait s'avérer problématique pour d'autres (en particulier pour les applications dans lesquelles la décentralisation est importante).
drand : aléatoire public distribué et vérifiable
Pour aider à résoudre ce problème de confiance, Cloudflare s'est associée en 2019 à sept autres organisations indépendantes et géographiquement réparties pour former la League of Entropy (la Ligue de l'Entropie) afin de lancer une balise aléatoire publique reposant sur le protocole drand (prononcé di-rand). Chaque organisation apporte sa propre source unique d'aléatoire au pool d'entropie commun utilisé pour ensemencer le réseau drand, Cloudflare apportant l'aléatoire de LavaRand, bien entendu !
Si la League of Entropy a fait ses débuts sous forme de réseau expérimental, conseillée et soutenue dans ses efforts par l'équipe drand de Protocol Labs, elle est depuis devenue un service Internet fondamental fiable et prêt à la production sur lequel s'appuient diverses applications allant du stockage de fichiers distribués aux jeux vidéo en ligne, en passant par les preuves horodatées et le chiffrement temporisé (dont nous discutons plus bas). La League of Entropy s'est également développée et 18 organisations réparties sur quatre continents participent aujourd'hui au réseau drand.
Les balises drand de la League of Entropy (chacune fonctionnant sous des paramètres différents, comme la fréquence de production des valeurs aléatoires et le chaînage ou non des éléments aléatoires — nous y reviendrons plus loin) possèdent deux propriétés importantes qui contribuent à leur fiabilité : elles sont décentralisées et vérifiables. La décentralisation garantit qu'un ou deux acteurs malveillants ne peuvent pas détourner ni biaiser la balise d'aléatoire, tandis que la vérifiabilité permet à quiconque de s'assurer que les valeurs aléatoires sont produites conformément au protocole drand et avec le concours d'un nombre minimal (le seuil) de participants au réseau drand (au moins la moitié, mais généralement plus). Ainsi, la confiance et la fiabilité du réseau drand continuent d'augmenter avec chaque nouveau membre.
Nous vous présentons ci-dessous un bref aperçu de la manière dont drand obtient ces propriétés en s'appuyant sur la génération de clés distribuées et les signatures de seuil. N'hésitez pas à consulter notre article de blog précédent et certains des excellents articles de l'équipe drand si vous souhaitez des informations plus approfondies sur le fonctionnement du réseau.
Génération de clés distribuées et signatures de seuil
Lors de l'installation initiale d'une balise drand, les nœuds du réseau exécutent un protocole de génération de clés distribuées (Distributed Key Generation, DKG) basé sur le schéma d'engagement de Pedersen, dont le résultat est que chaque nœud détient une « part » (une paire de clés) d'une clé de groupe distribuée, qui demeure fixe pendant toute la durée de vie de la balise. Pour que la clé secrète du groupe puisse être utilisée à des fins utiles, comme la signature d'un message, un nombre minimum de nœuds dans le réseau (le seuil, par exemple 7 nœuds sur 9) doit participer à l'élaboration d'une signature de seuil BLS. Vous trouverez ci-dessous les informations relatives au groupe pour la balise quicknet située sur le réseau principal drand de la League of Entropy :
curl -s https://drand.cloudflare.com/52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971/info | jq
{
"public_key": "83cf0f2896adee7eb8b5f01fcad3912212c437e0073e911fb90022d3e760183c8c4b450b6a0a6c3ac6a5776a2d1064510d1fec758c921cc22b0e17e63aaf4bcb5ed66304de9cf809bd274ca73bab4af5a6e9c76a4bc09e76eae8991ef5ece45a",
"period": 3,
"genesis_time": 1692803367,
"hash": "52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971",
"groupHash": "f477d5c89f21a17c863a7f937c6a6d15859414d2be09cd448d4279af331c5d3e",
"schemeID": "bls-unchained-g1-rfc9380",
"metadata": {
"beaconID": "quicknet"
}
}
(La valeur hexadécimale 52db9b… comprise dans l'URL ci-dessus est le hachage de la configuration de la balise. Rendez-vous sur https://drand.cloudflare.com/chains pour une liste de toutes les balises prises en charge par les nœuds de notre réseau principal drand).
Les nœuds du réseau sont configurés pour travailler ensemble de manière périodique (toutes les 3 secondes pour le quicknet) afin de produire une signature sur un message convenu, comme le numéro du tour en cours et la signature du tour précédent (voir ci-dessous). Chaque nœud utilise sa part de la clé de groupe afin de produire une signature partielle du message pour le tour en cours et la diffuse aux autres nœuds du réseau. Lorsqu'un nœud dispose d'un nombre suffisant de signatures partielles, il peut les regrouper pour produire une signature de groupe pour le tour donné.
curl -s https://drand.cloudflare.com/52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971/public/13335 | jq
{
"round": 13335,
"randomness": "f4eb2e59448d155b1bc34337f2a4160ac5005429644ba61134779a8b8c6087b6",
"signature": "a38ab268d58c04ce2d22b8317e4b66ecda5fa8841c7215bf7733af8dbaed6c5e7d8d60b77817294a64b891f719bc1b40"
}
La signature de groupe pour un tour est l'élément aléatoire (dans le résultat ci-dessus, la valeur aléatoire est simplement le hachage sha256 de la signature, pour les applications qui préfèrent un résultat plus court et de taille fixe). La signature est imprévisible à l'avance tant qu'un nombre suffisant (au moins une majorité, mais le nombre peut être configuré pour être plus élevé) de nœuds du réseau drand sont honnêtes et ne jouent pas de connivence. De même, n'importe qui peut valider la signature pour un tour donné en utilisant la clé publique de groupe de la balise. Nous recommandons aux développeurs d'utiliser les bibliothèques client drand ou la CLI pour effectuer une vérification sur chaque valeur obtenue de la balise.
Éléments aléatoires chaînés ou non chaînés
Lorsque la League of Entropy a lancé sa première génération de balises drand en 2019, le message de tour sur lequel la signature du groupe était calculée incluait la signature du tour précédent. Cette opération crée une chaîne de tours aléatoires jusqu'au premier tour de « genèse ». L'aléatoire chaîné offre des propriétés intéressantes pour les balises d'aléatoire à source unique et fait partie des exigences de la spécification du NIST concernant les balises d'aléatoire publiques interopérables.
Toutefois, en 2022, l'équipe drand a introduit la notion d'https://drand.love/blog/2022/02/21/multi-frequency-support-and-timelock-encryption-capabilities/ - unchained-randomness-timed-encryptionaléatoire non chaîné, dans laquelle le message à signer est prévisible et ne dépend d'aucun élément aléatoire des tours précédents. L'équipe a montré que cette approche propose les mêmes garanties de sécurité que l'aléatoire chaîné pour le réseau drand (les deux requièrent un seuil honnête de nœuds). Lorsque l'aléatoire non chaîné est mis en œuvre dans le quicknet, le message à signer ne comporte simplement que le numéro de tour.
# chained randomness
signature = group_sign(round || previous_signature)
# unchained randomness
signature = group_sign(round)
L'aléatoire non chaîné offre de puissantes propriétés et améliorations au niveau de l'ergonomie. En termes de facilité d'utilisation, un consommateur de balise d'aléatoire n'a pas besoin de reconstruire la chaîne complète d'éléments aléatoires jusqu'au tour de genèse pour valider intégralement un tour particulier. Les seules informations nécessaires sont le numéro du tour en cours et la clé publique du groupe. Le client bénéficie ainsi d'une plus grande souplesse, puisqu'il peut choisir la fréquence à laquelle il consomme des tours d'aléatoire sans avoir à suivre en permanence la chaîne d'éléments aléatoires.
Comme les messages à signer sont connus à l'avance (puisqu'ils indiquent simplement le numéro du tour), l'aléatoire non chaîné permet également d'accéder à une nouvelle propriété particulièrement puissante : le chiffrement temporisé (timelock).
Chiffrement temporisé
Le chiffrement temporisé (ou « à déclenchement temporisé ») est une méthode permettant de chiffrer un message de telle sorte qu'il ne puisse être déchiffré qu'après un certain laps de temps. Deux approches de base du chiffrement temporisé ont été décrites par Rivest, Shamir et Wagner.
Le déploiement de la cryptographie à déclenchement temporisé peut s'effectuer selon deux approches naturelles :
- Utiliser des « problèmes temporisés », c'est-à-dire des problèmes de calcul qui ne peuvent être résolus sans faire fonctionner un ordinateur en permanence pendant au moins un certain temps.
- Faire appel à des agents de confiance qui s'engagent à ne pas révéler certaines informations avant une date précise.
L'utilisation d'agents de confiance pose le problème évident de s'assurer que les agents sont bien « dignes de confiance ». Nous pouvons suivre diverses approches relatives au partage des secrets pour atténuer ce problème.
Le réseau drand est un groupe d'agents indépendants utilisant le partage de secrets à des fins de fiabilité. De même le principe d'avoir « certaines informations » qui ne doivent pas être révélées avant une date spécifiée ressemble beaucoup à la génération d'aléatoire par tour ! Dans le paragraphe suivant, nous allons décrire de quelle manière le chiffrement temporisé peut être mis en œuvre sur un réseau drand à l'aide de l'aléatoire non chaîné, avant de terminer par une démonstration pratique. Nous ne nous attarderons pas sur les groupes bilinéaires et la cryptographie basée sur les paires qui rendent le tout possible aussi, si vous êtes intéressés, nous vous encourageons à lire l'article tlock: Practical Timelock chiffrement from Threshold BLS (tlock : le chiffrement temporisé en pratique grâce aux seuils BLS) par Nicolas Gailly, Kelsey Melissaris et Yolan Romailler.
Intégrer un déclenchement temporisé à vos secrets
Commencez par identifier le tour d'aléatoire qui, une fois révélé, permettra de déchiffrer votre message chiffré par timelock. Comme les réseaux drand produisent de l'aléatoire à intervalles fixes, une observation importante consiste à remarquer que chaque tour au sein d'une balise drand est étroitement lié à un horodatage spécifique (modulo de petits délais pour que le réseau produise effectivement la balise). Cet horodatage peut être facilement calculé en prenant l'horodatage de la genèse de la balise et en lui ajoutant ensuite le nombre de tours, multiplié par la période de la balise.
Une fois que vous vous êtes décidé sur le tour, les propriétés des groupes bilinéaires vous permettent de chiffrer votre message à un certain tour à l'aide de la clé publique du groupe de la balise drand.
ciphertext = EncryptToRound(msg, round, beacon_public_key)
Une fois que les nœuds du réseau drand ont travaillé ensemble afin de dériver l'élément aléatoire du tour (en réalité, il s'agit simplement de la signature du numéro de tour utilisant la clé secrète du groupe de la balise), n'importe qui peut déchiffrer le texte (c'est là qu'intervient la magie des groupes bilinéaires).
random = Randomness(round)
message = Decrypt(ciphertext,random)
Concrètement, le message temporisé est en fait la clé secrète d'un système symétrique. Nous chiffrons donc le message à l'aide d'une clé symétrique et chiffrons cette clé à l'aide d'une clé temporelle, afin de permettre le déchiffrage futur du message.
Pour une démonstration pratique du chiffrement temporisé, nous utiliserons un outil que l'un de nos techniciens a développé à partir de Cloudflare Workers. Le code source est accessible au public si vous souhaitez examiner son fonctionnement plus en détail.
# 1. Create a file
echo "A message from the past to the future..." > original.txt
# 2. Get the drand round 1 minute into the future (20 rounds)
BEACON="52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971"
ROUND=$(curl "https://drand.cloudflare.com/$BEACON/public/latest" | jq ".round+20")
# 3. Encrypt and require that round number
curl -X POST --data-binary @original.txt --output encrypted.pem https://tlock-worker.crypto-team.workers.dev/encrypt/$ROUND
# 4. Try to decrypt it (and only succeed 20 rounds x 3s later)
curl -X POST --data-binary @encrypted.pem --fail --show-error https://tlock-worker.crypto-team.workers.dev/decrypt
Et ensuite ?
Nous espérons que vous avez pris autant de plaisir que nous à revisiter l'histoire de LavaRand et que nous vous aurons donné envie de visiter l'un des bureaux de Cloudflare à l'avenir et de contempler nos installations génératrices d'aléatoire de visu. Nous espérons également que nous vous aurons donné envie d'utiliser l'aléatoire public vérifiable et le chiffrement temporisé de drand dans votre prochain projet.
Le chaos est exigé par le chiffrement qui sécurise Internet. Chez Cloudflare, LavaRand continuera à transformer la beauté chaotique de notre monde physique en un flux aléatoire (même après l'ajout de nouvelles sources) afin de nous permettre de lui trouver de nouvelles utilisations que nous, explorateurs (tout comme cette escargote), n'avons pas encore imaginées.
Elle regarda le ciel, la mer, la terre, les vagues, les grottes et le sable doré. Elle regarda encore et encore, émerveillée par l'ensemble du monde, et dit à la baleine : « Je me sens si petite ».
Restez à l'écoute pour plus d'actualités, d'annonces et de discussions stimulantes ! N'hésitez pas à vous rendre sur la page d'accueil de la Security Week.