Jericho Chat est un programme de communication chiffrée utilisant un vrai générateur de nombres aléatoires (TRNG: True Random Number Generator) et des masques jetables. L'objectif est d'offrir un programme libre, open source, dont les communications sont chiffrées, pour les journalistes, les avocats, les militants et les citoyens du monde qui ont besoin d'une réelle assurance que leurs communications ne soient pas censurées, contrôlées, ni surveillés par des gouvernements de régimes totalitaires ni par les agences de renseignement les plus puissantes.
Pour vaincre les meilleures agences de renseignement du monde, vous devez élever votre jeu à leur niveau. Cela signifie l'utilisation de chiffrement qu'ils ne pourront jamais, jamais rompre, indépendamment des progrès en mathématiques, physique quantique, cryptanalyse ou technologique (NdM : la méthode de masque jetable utilisée est théoriquement/mathématiquement impossible à casser, bien qu'en pratique elle reste vulnérable car nécessitant d'échanger des clés et de les conserver secrètes).
En 2ème partie, un résumé très succinct des possibilité du programme. Je ne peux que vous conseiller de lire la page d'accueil et les pages d'information technique du site qui sont en anglais.
La nouvelle version de Jericho Chat 1.3 vient d'être publiée le 3 août 2014. Elle apporte la possibilité de chatter en groupe de 2 à 7 utilisateurs, un nouveau protocole d'authentification API côté serveur et un nouveau vrai générateur de nombres aléatoires.
L'installation nécessite la mise en place d'un serveur web.
Le programme rend le processus très simple pour générer de vrai nombres aléatoires, la gestion des clés et de chatter en toute sécurité. Après qu'un message soit envoyé, le masque jetable utilisé est automatiquement supprimé de l'ordinateur. Une fois reçu, il est également supprimé du serveur. Cela empêche que le message soit déchiffré dans le futur si l'un des ordinateurs est compromis. Si un utilisateur pense que leur ordinateur est sur le point d'être compromis il peut également activer la fonction "Auto Nuke" qui permet de supprimer les masques jetables de la base de données et du serveur. Plus d'informations à propos de la conception et la mise en œuvre technique sont disponibles sur le site. Le code source complet est disponible sur la page de téléchargement ou sur Github.
La raison principale pour laquelle les masques jetables sont rarement utilisés en dehors des réseaux gouvernementaux et militaires, c'est que vous avez besoin de données vraiment aléatoires, la clé doit être au moins aussi longue que le message et les masques jetables doivent être envoyés à travers un canal sécurisé remis en personne. Cela les rend peu pratiques à utiliser, mais ce ne sont pas des problèmes insurmontables. Ce logiciel a pour but de résoudre la plupart des problèmes qui rendent l'utilisation de masques jetables difficile. La seule petite question serait comment livrer les masques jetables à l'autre utilisateur, mais il y a des façons de le faire assez facilement. Dans le monde d'aujourd'hui complètement surveillé, il est effectivement nécessaire pour une rencontre physique d'avoir une assurance complète que vous communiquez réellement avec la bonne personne et non un attaquant. Évidemment, ce logiciel n'est pas une solution à tous les problèmes de cryptographie. Il ne résout toutefois qu'un problème spécifique et vous permet de communiquer en toute sécurité avec votre famille, vos amis, collègues ou associés à l'avenir si vous les avez rencontrés au moins une fois et échangé des masques jetables avec eux.
Aller plus loin
- Site officiel (1062 clics)
- Projet Github (327 clics)
# un vrai générateur de nombres aléatoires
Posté par haleth . Évalué à 4.
Un vrai générateur de nombres aléatoire .. ça existe en userspace ?
Une âme charitable a pris le temps de comprendre comme le truc fonctionne ?
[^] # Re: un vrai générateur de nombres aléatoires
Posté par feth . Évalué à 2.
À auditer pour déterminer si c'est bien un vrai générateur de hasard
[^] # Re: un vrai générateur de nombres aléatoires
Posté par Plume . Évalué à 1.
Au niveau hardware, on peut utiliser des expériences quantiques.
Je suis sûr qu'un interféromètre doit être bien réductible. (À la va-vite je dirait qu'il faudrait un laser, de la fibre optique, deux surfaces photosensibles et l'électronique pour contrôler le tout)
Après, on se retrouve avec le problème que du hardware est plus difficile à vérifier que du soft. (Surtout: En général, c'est impossible de produire son propre matos alors que compiler le code source soit même est quand même plutôt facile)
[^] # Re: un vrai générateur de nombres aléatoires
Posté par Tonton Th (Mastodon) . Évalué à 6.
Mais qui a compilé ton compilateur ?
[^] # Re: un vrai générateur de nombres aléatoires
Posté par reynum (site web personnel) . Évalué à 4.
Un humain ? La machine la plus difficile à prouver du monde.
kentoc'h mervel eget bezan saotred
[^] # Re: un vrai générateur de nombres aléatoires
Posté par romu . Évalué à 2. Dernière modification le 05 août 2014 à 08:48.
Bonjour,
Du temps où je bossais dans la SSI chez Thalès (fin des années 90), les générateurs d'aléas étaient des cartes ISA, l'aléa était généré à partir du bruit thermique d'une résistance. J'avoue ne pas avoir plus creusé la question.
[^] # Re: un vrai générateur de nombres aléatoires
Posté par reynum (site web personnel) . Évalué à 3. Dernière modification le 05 août 2014 à 12:04.
En effet l'analogique est souvent prise pour créer les graines des générateur d'aléatoire.
J'avais lu quelque part (je ne trouve plus la source) que le site pokerstar utilisait les mouvements de sourie des joueurs ainsi que des micros installés dans leur datacenter pour initialiser les graines de leurs générateur.
Je ne sais pas si c'est toujours le cas mais ils ont reçus une certification de fiabilité.
Un peut plus d'info sur cet article
kentoc'h mervel eget bezan saotred
[^] # Re: un vrai générateur de nombres aléatoires
Posté par Aissen . Évalué à 2. Dernière modification le 06 août 2014 à 01:56.
À partir d’Ivy Bridge(Core 3ème génération), les processeurs Intel incluent l’instruction RDRAND. Elle est incroyablement performante (500Mo/s), dans la mesure où elle peut s’exécuter en assez peu de cycles. Elle est utilisable en userspace. Elle repose sur un transistor mit dans un état "metastable", qui dérive à chaque coup de clock aléatoirement vers un 1 ou un 0. Ça seed ensuite un PRNG basé sur un hash/CBC. Je te laisse lire les différents papiers (d’Intel et d’universitaires) et brevets sur le sujet:
https://sites.google.com/site/intelrdrand/references
Si tu lis le lien wikipedia plus haut, tu verras aussi qu’il est possible que le générateur d’Intel soit backdooré par la NSA (ou pas), mais c’est impossible à prouver. Des scientifiques on même prouvé qu’on pouvait truquer un générateur aléatoire hardware "propre" de manière à résister à une analyse de die, mais j’ai plus la référence.
[^] # Re: un vrai générateur de nombres aléatoires
Posté par Aissen . Évalué à 3.
Le papier en question "Stealthy Dopant-Level Hardware Trojans" :
https://web.archive.org/web/20140531085714/http://people.umass.edu/gbecker/BeckerChes13.pdf (il est sur ACM apparemment sinon)
La présentation de conférence: http://www.chesworkshop.org/ches2013/presentations/CHES2013_Session4_3.pdf
[^] # Re: un vrai générateur de nombres aléatoires
Posté par khivapia . Évalué à 5.
Elle repose sur un transistor mit dans un état "metastable",
Comme tu dis, ça pourrait être backdooré. En pratique, qui peut vérifier si ça repose vraiment sur un transistor à état métastable, ou simplement sur un chiffrement de flot avec clef connue seulement d'Intel et de ses affidés ?
[^] # Re: un vrai générateur de nombres aléatoires
Posté par Aissen . Évalué à 2.
C’est justement le sujet du papier pointé par mon deuxième commentaire, qui montre comment implémenter ça de manière à résister à des analyses statistiques et de manière invisible sur les photos du die.
[^] # Re: un vrai générateur de nombres aléatoires
Posté par snurpsss . Évalué à -4.
Je n'y connais rien, mais si en demandé 2 fois un nombre aléatoire (disons de 1500 character), j'ai 2 fois la même chose c'est backdoré. Si pour générer un nombre aléatoire, je prend en saisis 25 caractères pour en obtenir 250 aléatoires, et qu'en fournissant 2 fois de suite les même 25 caractères, j'ai les mêmes 250 carac. qui reviennent, il y a cailloux sous baleine…
(comme dis plus haut je n'y connais rien, mais je ne vois pas comment on peux mettre un backdoor sur ce genre de chose sans que cela se vois…)
[^] # Re: un vrai générateur de nombres aléatoires
Posté par jben . Évalué à 5.
Sans vouloir être violent, je pense qu'il serait bénéfique que tu fasse un peu plus attention à ton écriture. J'ai relu une dizaine de fois ton premier paragraphe, même si je comprends l'idée générale, je ne comprends pas ce que tu veux dire.
Pour le deuxième point, je t'invite à lire les descriptifs des analyses effectués sur générateurs aléatoire mauvais (à dessein ou non), tu comprendras qu'une backdoor n'est pas forcement triviale.
[^] # Re: un vrai générateur de nombres aléatoires
Posté par khivapia . Évalué à 7.
comme dis plus haut je n'y connais rien, mais je ne vois pas comment on peux mettre un backdoor sur ce genre de chose sans que cela se vois…
Dans tes exemples, la backdoor se voit immédiatement : le biais sur l'aléa généré est absolument énorme (deux fois de suite la même séquence, surtout aussi longue ! ).
Pour backdoorer un générateur de nombres aléatoires, il "suffit" par exemple (selon les applications visées) que le biais soit extrèmement faible. Par exemple, si le biais est visible non pas avec 2 séquences de 1500 octets mais avec 232 séquences de 1500 octets. Pour la NSA, qui dispose de beaucoup de temps de calcul
à perdre, il lui suffira peut-être d'un biais qui commence à se voir sur une séquence de longueur 240 voire 264…De plus il y a d'autres façons de le backdoorer : si le générateur d'aléa provient non pas d'un processus physique mais simplement de la sortie d'un AES (il nous sort AES(0) puis AES(1) puis AES(2) puis…) avec une clef hardcodée connue seulement
de la NSAd'Intel, alors il n'y aura aucun biais détectable (sinon c'est une attaque sur l'AES !), en revanche l'attaquant qui connaît la clef connaîtra tout l'aléa utilisé !# Pas convaincu
Posté par Artefact2 (site web personnel) . Évalué à 3.
Justement non, il n'y a pas de moyen magique pour transmettre un masque jetable. C'est pourquoi d'ailleurs ils ne sont jamais utilisés, s'il faut transmettre un masque jetable de façon sûre, autant transmettre directement le message !
On se rapproche donc d'un modèle PGP. Autant utiliser PGP/GnuPG alors!
[^] # Re: Pas convaincu
Posté par Diagonale de Cantor (site web personnel) . Évalué à 6.
Pas forcément. Il suffit de se partager physiquement deux disques d’un Téra chacun avec un contenu aléatoire et tu peux ensuite cette base pour utiliser des masques jetables. Si chaque message fait en moyenne 1 MG tu peux envoyer 1024*1024 messages. Tu peux même multiplier ce nombre par 10 sans trop de crainte (utiliser 10 fois un masque jetable ne le fragilise pas tant que ça, au delà tu peux imaginer des attaques statistique).
Donc c’est une bonne solution si tu es amené à échanger beaucoup avec le même interlocuteur. Par exemple un journaliste qui part en mission ou un ambassadeur, voir même deux copains. Par contre ça passe mal à l’échelle avec des personnes qui ne se connaissent pas. C’est pas pour rien que la crypto asymétrique a été inventée…
[^] # Re: Pas convaincu
Posté par rewind (Mastodon) . Évalué à 2.
Je répond aussi au message grand-parent.
Historiquement, il a été utilisé pour le téléphone rouge. Et dans quelques autres cas très spécifique.
La sécurité prouvée du masque jetable repose sur le fait qu'on jette la clef, parce que jeter la clef ne fait apparaître aucune redondance dans le message chiffré. Si tu réutilises la clef, tu as perdu, ça revient à faire du chiffrement XOR.
[^] # Re: Pas convaincu
Posté par Artefact2 (site web personnel) . Évalué à -3.
Tu viens de réinventer PGP, sauf qu'au lieu d'échanger des disques d'1 To, c'est une clé de quelques Ko.
Je pense que justifier l'échange d'1 To pour la meilleure sécurité, c'est se fourvoyer. Surtout que générer 1 To de bits parfaitement aléatoires, ça risque de prendre un sacré bout de temps. Si tu utilises un générateur pseudo-aléatoire (même de bonne qualité), tu fous en l'air la sécurité, et autant échanger une clé PGP.
[^] # Re: Pas convaincu
Posté par Diagonale de Cantor (site web personnel) . Évalué à 2.
Ce qui prouve surtout que tu n’as absolument rien compris à l’intérêt des masques jetables !
La crypto asymétrique de type PGP sont triviaux à casser… en supposant que tu sois patient :) La sécurité ne repose que sur le fait qu’en pratique il est très long de casser une clé.
Cette sécurité repose sur l’hypothèse P≠NP. Cela pose deux problèmes.
avec 
tout petit ce qui fait que la taille des clés actuelles ne serait pas suffisante.
1. Peut-être qu’un jour on montrera P=NP
2. Même si P≠NP cela n’empêche pas l’existence en pratique d’un algorithme efficace (algo probabiliste, algo exponentielle de la forme
Les algo de chiffrement symétriques ne sont pas parfait non plus. En fait à partir du moment où la clé est plus petite que le messages il y a potentiellement des attaques. Tous ce qu’on peut dire aujourd’hui, c’est que l’on a trouvé aucune attaque pour les algos utilisés.
Le seul protocole mathématiquement sûr c’est le masque jetable dans lequel on ajoute un bruit aléatoire au message ce qui permet d’obtenir un message aléatoire. Le message qui circule sur le net ne porte absolument aucune information. Ce n’est que du bruit.
Aujourd’hui le masque jetable est peut être ridiculeusement lourd par rapport au algos asymétriques, mais il n’est pas stupide de s’y intéresser. Par exemple pour communiquer avec ta banque, elle te donne une clé de 16G. C’est pas absurde.
[^] # Re: Pas convaincu
Posté par rewind (Mastodon) . Évalué à 2.
Depuis quand la factorisation est-elle dans NP ?
[^] # Re: Pas convaincu
Posté par khivapia . Évalué à 3. Dernière modification le 05 août 2014 à 14:40.
C'est vérifiable en temps polynômial et les données sont linéaires, non ? Bref c'est dans NP, par contre c'est peut-être aussi dans P.
[^] # Re: Pas convaincu
Posté par Diagonale de Cantor (site web personnel) . Évalué à 6.
Depuis la définition de NP :)
NP pour faire simple signifie que le calcul peut être fait en temps polynomial par une machine non deterministe. Concrètement cela signifie que si on peut vérifier la réponse à une problème rapidement alors ce problème est dans NP.
Exemple, vérifier que 15 = 3 * 5 est trivial (une multiplication), par contre l’opération de factorisation est plus difficile.
Il ne faut pas confondre NP et NP-complet. Les problèmes NP-complet sont les problèmes les plus difficile de la classe NP. Si P≠NP alors ces problèmes seront officielement difficile. Mais si P=NP cela signifie qu’à partir du moment on l’on peut vérifier la réponse rapidement, alors le problème est rapide à résoudre, dans tous les cas.
Aujourd’hui on sait si P≠NP alors la factorisation n’est pas dans NP (il y a des problèmes plus dur à résoudre et si on trouve un algo rapide de factorisation cela ne mettra pas en danger la crypto asymétrique dans son ensemble), mais pour autant comme pour les autres problème de la classe NP, on ne connait pas d’algo polynomial.
En espérant avoir été clair.
[^] # Re: Pas convaincu
Posté par Zylabon . Évalué à 3.
J'ajouterais juste que le problème de la factorisation est dans P… Si on lui donne en entrée un nombre avec une représentation unaire ^
Le codage des données est super important.
Please do not feed the trolls
[^] # Re: Pas convaincu
Posté par Thomas Douillard . Évalué à 2.
Héhé, c'est pour ça que dans les définitions classique il y a "avec un bon codage des données" pour définir les classes de problèmes :)
[^] # Re: Pas convaincu
Posté par khivapia . Évalué à 1.
Par exemple pour communiquer avec ta banque, elle te donne une clé de 16G. C’est pas absurde.
Admettons que je communique avec ma banque avec masque jetable, j'envoie donc une demande de virement de mon compte numéro XYZ123 vers le compte d'un ami 321CBA, d'un montant de 10€ (remboursement d'un restau). Au final l'ordre de virement est formaté comme suit : XYZ123321CBA000010.00
Qui me garantit que mon "ami", qui intercepterait le message chiffré envoyé à la banque, ne flippe un bit au beau milieu de la demande de virement, la transformant en XYZ123321CBA080010.00 soit un peu plus que ce que je lui devais ?
Ou alors, qu'est-ce qui garantit qu'un petit malin qui connaît le numéro de compte de mon ami (donnée relativement privée mais très peu protégée, mettons que le pirate bosse chez EDF au service prélèvement automatique) ne flippe les bits de mon message chiffré à la banque sur les positions du numéro de compte du destinataire ? Il lui suffit de XORer le message chiffré par le xor bit à bit de son numéro de compte et de celui du destinataire initial de sorte à être destinataire du virement. Il peut également modifier le montant.
Bref, le masque jetable c'est bien, mais ça ne remplace pas le besoin d'un message d'authentification. Aucun connu n'est "sûr" comme le masque jetable et pourtant la sécurité repose dessus. Pourquoi s'embêter avec le masque jetable plutôt que d'utiliser la cryptographie symétrique classique ?
[^] # Re: Pas convaincu
Posté par Diagonale de Cantor (site web personnel) . Évalué à 1.
En fait il y a deux problèmes distincts.
Les problèmes de chiffrements d’un côté (où le masque jetable est le meilleur) et les protocole cryptographique dont le but est d’éviter les attaques de type man in the middle.
Réfléchir à des protocoles basé sur le masque jetable n’est pas forcément stupide et inintéressant. Si un jour on trouve un protocol facile à mettre un place (à partir du moment où on échange des clés de 16GB) alors la question sera plutôt pourquoi continuer à utiliser la cryptographie symétrique classique ?
S’authentifier avec un masque jetable est assez trivial. Le premier envoie un nombre aléatoire choisie localement et le correspondant réponds en envoyant ce nombre auquel il a ajouter un.
Pour être sûr que les message ne soit pas altéré, il suffit de rajouter un hash à la fin de chaque message.
[^] # Re: Pas convaincu
Posté par khivapia . Évalué à 1. Dernière modification le 05 août 2014 à 15:00.
En fait il y a deux problèmes distincts.
Non, il y a un seul problème : assurer la sécurité des échanges.
Le problème est surtout que la confidentialité sans authentification n'apporte pas de sécurité.
Le premier envoie un nombre aléatoire choisie localement et le correspondant réponds en envoyant ce nombre auquel il a ajouter un.
Et pour les échanges suivants, c'est-à-dire un vrai échange avec une information utile ?
Ce protocole est connu (http://fr.wikipedia.org/wiki/Identification_friend_or_foe ) mais ne sert que quand on sait avec quel appareil on parle et qu'on maîtrise donc le canal, mais pas sur un réseau et en particulier pas sur internet. Bref c'est une identification, pas une authentification, et de toutes façons ça n'authentifie pas les échanges suivants.
Pour être sûr que les message ne soit pas altéré, il suffit de rajouter un hash à la fin de chaque message.
Ben tiens :) Pour te paraphraser avec un brin de taquinerie, "Ceci prouve surtout que tu n'as absolument rien compris à l'intégrité en cryptographie !"
Dans l'attaque précédente, qu'est-ce qui empêche l'attaquant de calculer le hash du message qu'il modifie et de le modifier, tout pareil ? Si c'est mon ami, le message chiffré initial est XYZ123321CBA000010.00HASH, ça donnerait XYZ123321CBA080010.00SHHA avec le hash du message modifié, et il est tout aussi trivial de modifier un bit que de modifier toute la partie hachée.
[^] # Re: Pas convaincu
Posté par Diagonale de Cantor (site web personnel) . Évalué à 0.
Problème qu’on peut découper en deux !
Tu fais ça pour chaque message :
N
N+1 Message M hash1
M+1 Message L hash2
etc.
C’est peut être pas parfait mais l’homme du milieu est incapable de déchiffer ou de modifier des messages (il peut par contre les supprimer).
L’attaquant ne connais pas la valeur de N donc comment veux tu qu’il calcul le hash ?
[^] # Re: Pas convaincu
Posté par khivapia . Évalué à 5.
Il reste des problèmes (cf ci-dessous, mon commentaire et celui de jben), mais ma remarque au fond est surtout la suivante : à partir du moment où il y a besoin d'utiliser une fonction de hachage, pourquoi ne pas se permettre l'utilisation d'un chiffrement de bloc, qui repose sur les mêmes principes ?
[^] # Re: Pas convaincu
Posté par Diagonale de Cantor (site web personnel) . Évalué à 2.
L’objectif est de mettre en place un système mathématiquement 100% sûr. Pour l’instant ça me semble plus théorique qu’utilisable, mais ça vaut le coup d’y réfléchir.
Refuser toutes réfléxions parce qu’on a déjà des algos qui en pratique font le boulot c’est un peu triste…
Tes attaques reposent sur le fait que tu connais déjà le message que tu cherches à décoder (c’est comme ça qu’enigma a été cassé durant la seconde guerre mondiale) et dans ce cas modifier avec des xor est assez simples. Effectivement.
Il suffit de vérifier que le message n’a pas été altéré. On peut s’en sortir en permutant aléatoirement les bits du message et préciser la fonction de permutation en début de messages. La taille du message explose. Si tu notes
ta permutation tu envoies le message.
Pour modifier le message il faut modifier les trois parties du message de manière cohérente. Hors sans accès à
tu ne peux pas le faire. Par contre 
doit être très lourds à coder (au pifomètre 90% du message).
[^] # Re: Pas convaincu
Posté par jben . Évalué à 2.
(Juste pour la considération théorique. Je n'ai pas d'avis sur cette proposition)
Disons que ça dépends de la taille de ton message (on va dire n bits). Si σ est choisi aléatoirement dans l'ensemble des permutations (de taille n!), et que tu utilise un codage optimal dans cet ensemble des permutations, alors il te faudra log(n!)/log(2) bits.
Avec la formule de Stirling, ça fait un truc du genre (½⋅log(2⋅π⋅n)+n⋅log(n/e))/log(2)
Quelques valeurs.
[^] # Re: Pas convaincu
Posté par khivapia . Évalué à 1.
L’objectif est de mettre en place un système mathématiquement 100% sûr.
Oui mais pour cela, tu as besoin d'utiliser des briques qui ne le sont pas (mécanismes d'intégrité). Du coup cette annonce fait un peu l'effet de "je veux utiliser du masque jetable" plutôt que "je veux implémenter quelque chose de sûr". Il serait sans doute bon de partir de quelque chose qui existe et qui est raisonnablement sûr (modes d'intégrité, etc. connus et éprouvés), et éventuellement remplacer un chiffrement de blocs en mode compteur ou un chiffrement de flot par du masque jetable (ce qui est assez facile), tout en conservant les modes d'intégrité qui sont nécessaires à la sécurité.
que tu connais déjà le message que tu cherches à décoder
Une partie seulement, mais c'est un modèle tout à fait plausible. D'une part, si on s'interdit de supposer que l'attaquant le connaît, c'est inutile de le protéger n'est-ce pas :-p Surtout, tout ce qui a un format avec des valeurs plus ou moins imposées (aka à peu près tout ce qui circule sur internet) tombe dessus.
Il suffit de vérifier que le message n’a pas été altéré.
Oui, c'est-à-dire ajouter un code d'authentification de message (MAC), et il y en a qui sont bien connus du monde de la cryptologie. L'essentiel est surtout d'utiliser un mécanisme qui dispose d'une preuve de sécurité, ça évite les attaques triviales ou non sur la façon d'utiliser les briques de base (chiffrement, hachage, clefs).
[^] # Re: Pas convaincu
Posté par jben . Évalué à 5. Dernière modification le 05 août 2014 à 15:02.
Attends, tu es en train de dire qu'il suffit d'envoyer un message (le nombre aléatoire), combiné avec un secret partagé (le masque jetable), le tout suivi du hash de ce qui précède. Un peu plus (car c'est pas encore bien au point, il y a encore des faiblesse dans ta méthode) tu nous réinvente HMAC.
[^] # Re: Pas convaincu
Posté par khivapia . Évalué à 2.
S’authentifier avec un masque jetable est assez trivial. Le premier envoie un nombre aléatoire choisie localement et le correspondant réponds en envoyant ce nombre auquel il a ajouter un.
Je repense à ça : si c'est un ennemi qui le demande, il peut ainsi récupérer le XOR d'une bonne partie des deux masques jetables utilisés et s'en servir pour tenter de récupérer des informations en communiquant avec ton ami (il envoie 0, l'interlocuteur pense qu'il s'agit d'un nombre a masqué par un masque m, il renvoie a+1 masqué par m', l'attaquant connaît ainsi a XOR m (= 0) et (a+1) XOR m'. À partir du bit où la retenue n'est plus propagée (bit 0 avec proba 1/2, bit 1 avec proba 3/4, etc.) il connaît m XOR m' !
Dans tous les cas, il peut faire un déni de service en demandant l'identification : ainsi, la personne à qui il la demande consomme son masque et se désynchronise.
[^] # Re: Pas convaincu
Posté par Diagonale de Cantor (site web personnel) . Évalué à 3.
Le masque change pour absolument chaque message ! Si tu échange 10M d’information tu consomme 10M de masque. Si tu déchiffre un bit tu ne peux rien faire de cet information.
Déjà faut voir comment utiliser cette information et ensuite puisque m et m' ne seront plus utilisé il ne te servent à rien ! En effet même en réussissant à t‘autentifier avec, tu ne pourras pas rédiger le reste du message.
Effectivement. Le masque jetable est très lourds à utiliser et c’est son défaut principale. Il survit mal au DDOS. D’un côté le bon point c’est que si on cherche à t’attaquer tu le vois de suite !
[^] # Re: Pas convaincu
Posté par khivapia . Évalué à 0. Dernière modification le 05 août 2014 à 16:36.
et ensuite puisque m et m' ne seront plus utilisé il ne te servent à rien !
Ils ne seront plus utilisés par le type avec qui l'attaquant a demandé une identification (Alice), mais ça n'empêche pas l'attaquant de causer (ou d'écouter) l'autre interlocuteur (Bob) qui, lui, voudra utiliser ces masques là !
Déjà faut voir comment utiliser cette information
Il récupérera le XOR de deux clairs quand l'autre interlocuteur (désynchronisé) enverra des messages. C'est très grave.
[^] # Re: Pas convaincu
Posté par jben . Évalué à 5.
Oui, quand tu regarde la robustesse théorique de la méthode.
En pratique, pour faire mieux que la crypto assymetrique actuelle au niveau sécurité il faut aussi prendre en compte l'implémentation.
Pour le point 1, c'est une vaste blague, j'en ai parlé sur un autre thread. Sur le point 2, le problème est mis sous le tapis, alors que c'est l'essentiel de la sécurité de ce protocole. Pour le point 3, c'est du HTML5+javascript (heuresement servi localement quand même), executé par un navigateur, qui n'a aucune des garanties de vérouillage de la mémoire etc. qu'ont les implémentations pratiques des méthodes de crypto assymetrique actuelles, et du code en HTML5+javascript executé par un navigateur me laisse à penser que les side channel attacks doivent pulluler.
On le sait, les maillons faibles c'est souvent la sécurité des terminaux et la manière d'échanger les clefs. Hors la solution proposée ici semble présenter des lacunes sur le premier point, et ne propose rien quand au deuxième point.
J'aurai été probablement moins acide si c'était vendu comme une implémentation permettant d'ouvrir la reflexion sur les protocoles de crypto, et j'aurai même été plutôt positif dans mes commentaires. Mais c'est vendu comme étant la solution ultime, c'est sûr qu'en ayant mis tous les problèmes sous le tapis, c'est la solution ultime.
[^] # Re: Pas convaincu
Posté par Diagonale de Cantor (site web personnel) . Évalué à 5.
Il y a deux choses.
Critiquer le côté amateur de cet outil et critiquer le principe des masques jetables.
Dire que les masques jetable c’est stupide parce qu’on a PGP c’est passé à côté de l’intérêt de l’approche.
Que tu défonce l’auteur de ce journal pour son côté amateur, fais toi plaisir (moi je ne juge pas). Mais il est absurde de critiquer les masques jetables (il n’a jamais été aussi simple d’échanger des clés : je te passe une clé de 16G, on peut s’envoyer des mails pendant 5ans).
Il est important de considérer que même avec un protocole sûr à 100% il y aura toujours le facteur humain qui sera le plus gros angle d’attaque (Tiens, elle est où ma clé ?)
[^] # Re: Pas convaincu
Posté par jben . Évalué à 5. Dernière modification le 05 août 2014 à 15:16.
Tu remarqueras que je ne me suis jamais attaqué au principe des masques jetables. Je dis juste que c'est très compliqué à utiliser en pratique, et que pour que au niveau robustesse cela soit supérieur à la crypto assymétrique telle qu'on l'utilise actuellement, il y a de nombreuses précautions (pratiques, pas théoriques) à prendre.
À propos de la génération de nombres aléatoires, tu dis que c'est le même problème que toutes les méthodes de crypto. Justement ! On a vu que le choix d'un RNG ne se faisait pas au doigt mouillé. C'est justement parce que c'est le même problème que toutes les autre méthodes, et c'est justement parce que il y a beaucoup de travaux faits sur ce sujet, qu'arriver avec un algo ultime bien en dessous de l'état de l'art est ridicule.
Pour l'échange de masque, je suis d'accord, mais justement, c'est quand même pourquoi même si le masque jetable est mieux nous utilisons en pratique de la crypto assymétrique. Dire « il suffit de » me parrait donc assez léger.
Et enfin quand je parle de l'implémentation, ce n'est pas l'implémentation du XOR, c'est tout le reste. La gestion des masque, la gestion en mémoire des masques pour pas qu'ils soient lu par des tiers, la non-réutilisation d'un même masque, et donc l'identification dans le message d'un numéro de masque utilisé. Bref, et théorie c'est simple, mais si on a l'ambition de faire mieux que la crypto symmetrique, l'implémentation doit être effectuée (et auditée) avec soin.
Édit: Et j'ajoute sur la compléxité des implémentations de RSA, c'est justement le point. En effet implémenter RSA est très simple. Implémenter RSA en étant résistant à toutes les side channel attacks est très compliquer et ça devient dur à comprendre. On voit ici l'interêt de travailler l'implémentation.
[^] # Re: Pas convaincu
Posté par gouttegd . Évalué à 4.
Tu proposes de générer 16 Go de masque jetable pour chacun de mes correspondants ? Qu’il faudra conserver aussi longtemps que nécessaire ? Qu’il faudra donc aussi sauvegarder ? Et il faudra s’assurer que ces N × 16 Go (où N est le nombre de correspondants) restent à l’abri des regards indiscrets pour toute la durée d’utilisation prévue ?
C’est peut-être « un milliard de fois plus simple que RSA et PGP », mais c’est un milliard de fois moins pratique à manipuler qu’une paire de clef RSA.
[^] # Re: Pas convaincu
Posté par Diagonale de Cantor (site web personnel) . Évalué à 4.
Ouais enfin là tu enfonces des portes ouvertes ! C’est le gros problème de la méthode et on en est tous conscient.
Où ai-je dis que cette solution pouvait passer à l’échelle. Les exemples que j’ai cité, un employé avec sa boite, un client avec sa banque font que de toute façons tu ne termineras jamais avec plus de 5 clés.
Cette solution pourrait être intéressante pour des cas particuliers.
[^] # Re: Pas convaincu
Posté par jben . Évalué à 10.
Je ne parle pas de l'implémentation présentée dans la dépèche, qui semble souffrir de nombreuse zone d'ombre (génération des masques, qualité du RNG, transmission…), mais de manière générale :
En fait si tu as le message au moment où tu fais l'échange de masque jetables, alors tu as raison. L'intérêt c'est justement de pouvoir séparer les deux. Au moment où tu échanges les masques, tu n'as pas forcément encore le message, et tu prévoie de le transmettre plus tard. En gros la technique du masque jetable avec un échange physique du masque, permet de transmettre le message avec la même sécurité que l'échange physique préalablement effectué. Il y a plein de cas où ça peut avoir un interêt, par exemple, en supposant que l'acquisition du message t'expose à une surveillance accrue, il peut être une bonne idée d'échanger des masques avec un tiers avant d'être mis sous surveillance, puis d'acquérir le message, d'être placé sous surveillance à partir de ce moment, et de transmettre le message.
Bref c'est une technique qui a un grand intérêt, contrairement à ce que tu laisse entendre, mais la mise en œuvre de cette technique est loin d'être simple. Quand je vois à quel point il est déjà très compliqué de faire en sorte que les gens utilisent la cryptographie asymétrique, technique théoriquement moins robuste que les masques jetables mais beaucoup plus simple à mettre en œuvre, alors je pense que la mise en œuvre des masques jetables dans ce contexte est soit impossible, soit complètement non sécurisée.
[^] # Re: Pas convaincu
Posté par Artefact2 (site web personnel) . Évalué à -2.
Dans ce cas, il me semble que le chiffrement asymétrique est plus adapté, surtout car il est plus facile de générer une clé sûre.
[^] # Re: Pas convaincu
Posté par Zylabon . Évalué à 0. Dernière modification le 06 août 2014 à 19:03.
chiffrement asymétrique : cassable avec assez de puissance et/ou connaissance
masque jetable : incassable, quelque soit la puissance, et le niveau de ceux qui s'y emploie.
J'ai un peu l'impression de lire ça :
− Tu veux un super coffre fort en adamantium avec toutes les sécurités dernier cri ?
− Non c'est bon, j'en ai un en bois, il a un super gros cadenas, c'est mieux
Absurde… Certes le coffre en adamantium est plus lourd, mais il est imperçable.
Please do not feed the trolls
[^] # Re: Pas convaincu
Posté par Aris Adamantiadis (site web personnel) . Évalué à 3.
Une bonne comparaison c'est une caisse en carton dans un coffre à la banque (solution clef privée) vs caisse en adamantium assemblée avec des morceaux de papier collant et déposée au milieu d'une place de village.
Absolument rien dans ce projet ne me fait confiance. Le problème de la cryptographie, c'est la distribution des clefs et la sécurité des implémentations. Plusieurs personnes ici ont montré que #1 est pas résolu (en fait rendu encore plus difficile) et #2 est totalement discutable (RNG fabriqué par quelqu'un qui ne devrait pas faire de cryptographie avant d'avoir lu deux ou trois livres sur le sujet).
[^] # Re: Pas convaincu
Posté par khivapia . Évalué à 2.
masque jetable : incassable, quelque soit la puissance, et le niveau de ceux qui s'y emploie.
Seulement face à un adversaire passif, qui ne modifie pas les messages, n'intercepte pas la communication pour la rejouer avec l'interlocuteur putatif plus tard… Bref c'est la crypto d'arrière-grand-papa, parce que même grand-papa, pendant la deuxième guerre mondiale, il voyait faire ce genre de choses.
[^] # Re: Pas convaincu
Posté par Zylabon . Évalué à 2.
Non… Il est impossible de modifier un message sans la clé. Et retarder, ou bloquer un message est toujours possible, mais c'est pas un problème de crypto.
Please do not feed the trolls
[^] # Re: Pas convaincu
Posté par khivapia . Évalué à 5.
Ben si le format du message est connu (ce qui est le cas avec tout ce qui est informatique), c'est tout à fait possible (permuter un bit de chiffré permute un bit de clair).
C'est vraiment le truc important des chiffrements de type flot (chiffrement à flot, bloc en mode compteur etc.) dont fait partie le one-time pad.
[^] # Re: Pas convaincu
Posté par Zylabon . Évalué à 2.
Il suffit une somme de contrôle ou un padding aléatoire pour rendre cette attaque impossible. Mais tu as raison la méthode en elle même ne garanti effectivement pas l'intégrité en cas de clair connu.
Cette méthode offre des garanties très fortes ! La crypto asymétrique c'est très bien, ça marche, mais rien ne dit que des messages qui sont interceptés aujourd'hui ne seront pas stockés pour être déchiffré dans quelques années. Avec le masque jetable on a la garantie que jamais un message ne sera déchiffré sans la clé, jamais. Ça ne repose pas sur l'hypothèse qu'un adversaire n'a pas le temps, la technologie ou la connaissance pour le déchiffrer.
De nos jour échanger quelques mégas ou gigas données en main propre c'est pas très différent d'échanger une paire de clé publique, ou une clé secrète. Donc cette vielle méthode reposant sur une construction mathématique à la portée d'un gosse de 4 ans est tout a fait pertinente.
Please do not feed the trolls
[^] # Re: Pas convaincu
Posté par khivapia . Évalué à 6. Dernière modification le 07 août 2014 à 16:32.
Il suffit une somme de contrôle ou un padding aléatoire pour rendre cette attaque impossible.
Non, c'est plus compliqué que ça : il faut de l'intégrité face à un attaquant actif, pas simplement une corruption liée au réseau ou autre. Cf http://en.wikipedia.org/wiki/Message_authentication_code par exemple.
Par contre c'est vrai que le one time pad offre de meilleures garanties qu'un chiffrement classique, au sens où la sécurité n'est pas calculatoire (en 2128 on retrouve une clef de 128 bits) mais vraie au sens théorie de l'information (pour un bloc classique : 128 bits de clair + 128 bits du chiffré correspondant = toute l'info nécessaire pour retrouver la clef et déchiffrer le bloc suivant ; OTP : 128 bits de clair + 128 bits de chiffré = aucune information sur les 128 bits de clairs suivants). Toutefois est-ce bien utile compte tenu de la pérennité des informations à protéger ?
Rares sont les faiblesses catastrophiques dans les algorithmes de cryptographie symétrique récents : certes DES a eu plusieurs attaques, mais aucune n'est significativement meilleure que la recherche exhaustive. Idem avec AES depuis 15 ans. Si on est parano au point d'utiliser le OTP, il est vraisemblablement bien plus efficace de prendre l'AES-256 et d'en augmenter, simplement, le nombre de tours pour se protéger plusieurs dizaines d'années supplémentaires.
En outre, le One Time Pad, sans compter les problèmes "pratiques" de distribution des clefs, ça ne fait que du chiffrement de flot et c'est problématique pour la sécurité (pas d'intégrité).
À partir du moment où pour l'intégrité il faut une fonction de la crypto classique (type AES), de toutes façons on n'aura pas mieux que la sécurité calculatoire (2128 ) face à un attaquant actif, qui est un modèle tout à fait pertinent.
# Les bras m'en tombent...
Posté par Burps . Évalué à 10.
Proposer "One Time Pad" comme un moyen pratique de faire du chiffrement symétrique et éluder le problème d'échange de clé par une phrase sibylline du style "La seule petite question serait comment livrer les masques jetables à l'autre utilisateur, mais il y a des façons de le faire assez facilement" me paraît un peu rapide. Généralement, la rencontre physique est un peu compliquée quand on a besoin de telles garanties.
Sinon:
- Je n'ai pas compris comment il propose le déni plausible autrement que par "mais oui, monsieur, j'ai des fichiers totalement random et quand vous faites un xor, c'est du français, mais vraiment un truc de ouf, je m'en vais jouer ma grille de loto".
- Confidentialité persistante (Forward secrecy) ? On passera… c'est pourtant quelque chose qu'on voudrait.
- Ensuite, OTP est incassable… mathématiquement (comme dit dans l'article). Pourquoi leur implémentation ne fait apparaître aucun canal caché ? Rien n'est dit.
- Et le PRNG qui est un RNG ? Pourquoi ? Rien n'est dit. Ce n'est pas parce que il y a des cables que c'est un RNG. (Comme ce n'est pas parce que l'algorithme de PRGN a été généré aléatoirement que c'est un bon PRGN).
On a besoin d'implémentation sure (et prouvée) de protocoles cryptographiques. Et il faut expliquer pourquoi son implémentation est sure. Là, sur le site, je vois une bonne explication du problème (en effet, je ne fais pas confiance aux standards gouvernementaux), puis ensuite une rangée de trompettes sonnant triomphalement sous la bannière rutilante d'OTP, mais pas la queue d'une explication.
[^] # Re: Les bras m'en tombent...
Posté par DerekSagan . Évalué à 2.
En plus du +1 sur le fond, je plussoie aussi l'excellent jeu de mot sur le nom du soft avec les trompettes sonnant triomphalement… :-)
# Le TRNG, moi aussi les bras m'en tombent
Posté par jben . Évalué à 10.
Je viens de lire l'algo qu'ils nomment TRNG. J'ai peur.
Je vous le résume.
Voilà.
Il semble possible de construire donc un modèle statistique de dépendance de la source aléatoire, en utilisant les proprietés statistiques du messages (ou pas d'ailleurs), ça fout en l'air toute la sécurité.
Non mais vraiment, il faut laisser la cryptographie à ceux qui savent ce qu'ils font. (Moi j'ai juste le niveau pour savoir ce qu'il ne faut pas faire, je n'ai pas le niveau pour savoir ce qu'il faut faire.)
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par jben . Évalué à 10.
Je complète ce que j'ai écrit.
En lisant leur descriptifs, et leurs test, il est clair que le flux de bits après la deuxième étape est d'une qualité insuffisante (le nombre de fails sur un test permissif en témoigne). Au final tout le boulot est fait par le Von Neumann, un algo simple qui permet de propager une connaissance à l'entrée à une connaissance à la sortie.
Il existerai pourtant des moyens de faire mieux, beaucoup mieux. Une des proprieté des condensats cryptographiques, et qu'il est très difficile (en pratique souvent impossible) de propager une connaissance statistique sur l'entrée à une connaissance statistique sur la sortie. L'utilisation à la troisième étape d'un algo de calcul de condensat me semblerait beaucoup plus approprié.
À moi, cet algo me semble suspect et bancal. Et quand on voit la capacité des cryptanalystes à obtenir des informations sur les méthodes de générations de nombres aléatoires, qui me semblent propres, je jette cet algo sans même réflechir une minute. Si il existe des audits sur les RNG, généralement c'est qu'il y a une raison.
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par keyser.dyson . Évalué à 2.
Je n'y connais rien en cryptographie mais à chaque fois je me demande pourquoi on ne peut pas utiliser le microphone, la webcam ou même les capteurs de température internes comme générateur de nombres aléatoires ?
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par jben . Évalué à 7.
Pour le microphone, il y a des projets qui construisent des nombre aléatoires à partir de cela. Disons que pour un microphone, même s'il peut s'agir a priori d'une bonne idée, il faut pouvoir bien connaitre le DSP de ta carte son. Le traitement que fait ta carte son sur le signal pourrait éventuellement permettre d'avoir de propriété sur ton signal qui pourrait permettre de déduire des propriétés sur ta séquence aléatoire.
Après la grande subtilité, c'est le choix des traitements que tu appliques. Si tu choisi bien les traitements que tu applique, le fait de connaître des propriétés statistiques sur ton signal d'entrée ne te permettra que très difficilement d'en déduire des propriétés sur le signal de sortie. C'est la même logique que dans les PRNG où tu réutilise des informations du passé de la séquence que tu traite pour obtenir la suite de la séquence. L'important est le choix du traitement que tu effectue.
Ici le traitement effectué, le Von Newmann, me laisse dubitatif.
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par barmic . Évalué à 7.
Il y a des programmes qui demandent de générer de l'entropie en déplaçant sa sourie.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
L'idée c'est d'avoir une mesure physique bruité comme une webcam ou un son et de récupérer les bits de bruits. On peut prendre tout, mais cela n'ajoute pas grand chose en sécurité. On peut même compresser le tout pour augmenter l'entropie des bits, et casser des répartitions statistiques. Et on peut passer le tout à travers un sha1 ou sha512 pour casser toute dépendance.
"La première sécurité est la liberté"
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par pasBill pasGates . Évalué à 3.
Windows et Linux ont deja un generateur aleatoire (Mac OS X je sais pas mais j'imagine qu'eux aussi), partant de la, cette 'feature' est un gag enorme.
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par oinkoink_daotter . Évalué à 6.
Sous linux, le /dev/random (le vrai aléas crypto) est trop lent pour ce genre d'opérations (yaka voir à quelle vitesse bloque un
cat /dev/random). Celui de Windows, on sait surtout qu'il ne faut pas l'utiliser, agence améwicaine en 3 lettres, DUAL EC machin toussa.[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par khivapia . Évalué à 2.
Pour accélérer /dev/random, on peut ajouter des démons qui récupèrent de l'entropie de ci de là, comme haveged et randomsound.
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par pasBill pasGates . Évalué à 1.
LOL.
Allez, on va assumer qu'il ne faut pas l'utiliser, j'ai pas le temps pour un troll trop long(surtout quand tu mentionnes dual_ec_drbg , sachant que ce sont 2 des developpeurs de la stack crypto de Windows qui ont donne l'alerte sur les trous la dedans).
Il faudrait etre absolument STUPIDE pour faire tourner un soft sensible (comme ce soft pense l'etre) sur une plateforme en laquelle on n'a pas confiance. Soit ils estiment que Windows est digne de confiance est alors ils utilisent son generateur aleatoire, soit ils evitent la plateforme car elle est 'pas sure'. Un truc au milieu est une aberration d'un point de vue securite.
Quand au /dev/random , ben ouais, ca prend un peu de temps de generer qqe chose de propre…
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par oinkoink_daotter . Évalué à 3.
Je dois bien concéder que je me suis fait plaisir sur ce coup là. Je suis parfaitement au courant de ce que tu écris, mais que veux-tu sur ce sujet la en particulier, tu marches aussi bien qu'albert< quand il voit le mot Microsoft dans un post.
Je sais bien (quoique c'est un peu plus compliqué que ça). C'est vaguement mon métier :)
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par khivapia . Évalué à 1.
ce sont 2 des developpeurs de la stack crypto de Windows qui ont donne l'alerte sur les trous la dedans
Enfin surtout ce sont deux chercheurs qui ont publié le truc, comme tout chercheur en cryptologie ayant trouvé le problème l'aurait fait.
Le problème est surtout que Microsoft a choisi d'utiliser ce standard, qui est inefficace (crypto asymétrique alors qu'il y a des retraitements à base de hachage bien plus efficace) et qui s'est avéré troué. Ça jette une suspicion forte : spontanément, aucun ingénieur sain d'esprit n'aurait utilisé ce standard là, ça vient donc soit d'une large incompétence (que je soupçonne difficilement chez Microsoft), soit ça a été imposé par un chef quelconque suite à quelques pressions/suggestions externes. Dans tous les cas, la seule entité à qui ça a profité est la NSA.
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par pasBill pasGates . Évalué à -1.
MS n'utilise ce standard nulle part. Il est offert dans une librairie au cas ou un soft voudrait l'utiliser, mais Windows lui-meme ne l'utilise absolument nulle part.
Il n'a ete mis dedans que parce qu'il faisait partie d'un standard et rien ne l'utilisera sans que ce soit fait consciemment par le developpeur du soft.
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par oinkoink_daotter . Évalué à 3.
MS devrait implémenter le standard international bien connu ROT13 pour voir si ça gueule ou pas :-)
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par Aris Adamantiadis (site web personnel) . Évalué à 2.
On pourrait commencer à discuter si ROT13 était un standard publié par le NIST et suffisant pour obtenir une certification FIPS.
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par oinkoink_daotter . Évalué à 2.
Wai, ok.
Mets DES alors, c'est à peu près aussi fiable.
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par pasBill pasGates . Évalué à 0.
DES est supporte, mais comme il est considere dangereux, il est off par defaut, tout comme dual_ec_drbg
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par ariasuni . Évalué à 2.
Désolé, ça piquait vraiment trop les yeux.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
La source d'entropie de linux et de windows est bien trop faible, surtout au lancement d'une installation (générateur hardware Intel, d'on peut douter de l'intégrité, et activité sur la machine bien trop faible pour avoir assez d’entropie, cf le message sur les pb de clefs pour les redhat toute fraiche)
"La première sécurité est la liberté"
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par pasBill pasGates . Évalué à -2.
A l'installation oui, mais l'installation du systeme c'est pas le moment ou ce soft va tourner…
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Non, mais le principe reste valable : rajouter de l'entropie avec un phénomène physique aléatoire, avec un fonction de hash pour casser tout biais statistique.
"La première sécurité est la liberté"
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par pasBill pasGates . Évalué à 5.
Moi ce qui me fait le plus rire, c'est qu'ils croient qu'ils feront mieux que le generateur aleatoire du systeme.
C'est un peu comme les fans de foot qui croient qu'ils feraient mieux que le coach, c'est toujours amusant a voir.
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Quelle source non pseudo aléatoire dispose le générateur interne ? Le truc d'intel ? L'activité du système ? ( qui est hautement prédictif lors d'une installation)
"La première sécurité est la liberté"
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par pasBill pasGates . Évalué à -2.
cf. https://pthree.org/2014/07/21/the-linux-random-number-generator/ par exemple pour une explication du RNG de Linux : interruptions, I/O disque, souris/clavier notamment. Ils utilisent aussi RdRand en plus.
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je sais pour Linux, je parlais de windows.
"La première sécurité est la liberté"
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par pasBill pasGates . Évalué à -1.
Oh, ben c'est decrit la : http://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"AES counter-mode based PRNG specified in NIST Special Publication 800-90"
"Recommendation for Random Number Generation Using Deterministic Random Bit Generators"
La doc que tu pointes indiquent la méthode utilisée pour générer un nombre aléatoire, mais pas comment l'entropie est trouvé par windows.
"La première sécurité est la liberté"
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par pasBill pasGates . Évalué à -2.
C'est la phrase d'avant…
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par Sébastien Koechlin . Évalué à 4.
Sans avoir d'expérience particulière en crypto, le matériel n'est pas parfait et on a rarement accès aux données brutes.
L'ordinateur ou le matériel se contente d'échantillonner périodiquement une valeur analogique pour en faire une valeur numérique. Et on retrouve dans ses données finales pas mal de choses:
Dans le temps, le bruit généré par le secteur (à 50Hz) est tout à fait prévisible. Le bruit généré par tout autre équipement utilisant un signal périodique doit s'y retrouver: écran, bus de l'ordi, GSM, alimentation à découpage, disque dur… Dans le cas du son, on peut avoir une musique qui microscopiquement donne un signal très périodique et très prévisible.
Dans l'espace, la qualité du signal initial est souvent déformé; le micro n'a pas la même capacité à capter toute la gamme de fréquences, la webcam donne une qualité d'image souvent exécrable parce que la plage de mesure est très réduite.
Ensuite le matériel fait souvent une normalisation. Si toutes les mesures de signal se font entre 0% et 5% des valeurs possibles; pour avoir quelque chose d'intéressant, on va multiplier tout par 20, ce qui donnera des valeurs entre 0 et 100%. Parfois cette normalisation se fait partiellement ou totalement en analogique (et de façon plus ou moins réactive), ce qui revient à modifier la sensibilité; parfois elle est bêtement faite en numérique, ça coûte nettement moins cher; et au final on a une large plage de valeurs, mais en n'utilisant qu'une fraction des valeurs possibles. Le cas inverse existe également, on mesure le signal sur 10 ou 12 bits, et on réduit à 8 en sortie. Cette normalisation va faire disparaitre les petits signaux comme un petit bruit à coté d'un bruit fort.
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Pour ton premier problème, il faut s'assurer que la source est réellement dans le bon état : un photo toutes blanches (saturé) n'est pas un bon candidat, idem avec une source audio en "mute". Il te faut une métrique pour s'assurer de la qualité (test de focus par somme des différences, pour tester la présence suffisante de haute fréquence).
Ensuite, pour la normalisation, il ne faut pas avoir un bit de donné pour un bit de masque. On peut avoir 1 bits de donné aléatoire par pixel. Le mélange doit se faire avec un hash de crypto.
L'utilisation d'une fonction de compression avant le hash, permet d'avoir une meilleur répartition statistique des bits.
"La première sécurité est la liberté"
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par wluce0 . Évalué à 2.
Tu peux utiliser ta clé RTL (une clé TNT qui permet de faire de la radio logicielle) :
http://www.rtl-sdr.com/true-random-numbers-rtl-entropy/
# Le projet est libre, vous pouvez participer
Posté par J'informatique (site web personnel) . Évalué à 8.
Merci pour vos commentaires concernant la dépêche. Je comprend que l'algo du TRNG utilisé peut être sujet à polémique, mais rien ne vous empêche d'ouvrir un ticket sur github et d'en discuter avec l'auteur du projet Joshua M. David pour lui proposer mieux. Si vous ne le faites pas, personne ne le fera à votre place car moi non plus je ne suis pas expert en crypto.
https://github.com/joshua-m-david/jerichoencryption/issues
Dans les versions précédentes, le TRNG utilisé était de bouger la souris et d'entrer des touches sur le clavier, pour l'avoir testé cela prenait du temps pour générer un grand nombre de données aléatoires, maintenant il l'a remplacé par une extraction de pixels à partir de photos. Qui sait si dans la prochaine version cela ne sera pas remplacé par une meilleure source de données aléatoires. Encore une fois chacun à l'opportunité de participer puisque le code est libre et l'auteur ouvert à toute aide.
Je souhaitais faire mieux connaître ce programme, d'où la dépêche un peu courte sur linuxfr.
[^] # Re: Le projet est libre, vous pouvez participer
Posté par rewind (Mastodon) . Évalué à 10.
Le problème, ce n'est pas que le projet ne soit pas libre, mais que visiblement, l'auteur du projet n'a aucune foutue idée de ce qu'il fait et que, au mieux, on va appeler ça du bricolage, mais certainement pas de la cryptographie. Et il suffit d'avoir suivi un cours de sécurité à l'université pour le comprendre.
Donc, je suis désolé de le dire, mais il n'aura certainement aucune contribution, ou en tout cas aucune contribution sérieuse, parce que son projet n'est pas très sérieux à la base donc ne donne absolument pas envie de contribuer. Il aura sans doute des contributions de gens qui se laissent facilement impressionner par des termes techniques sans consistance.
La morale de ce projet (et de tant d'autres), c'est qu'il vaut mieux laisser la cryptographie à des gens qui savent s'en servir et dont c'est le métier. Ou alors, il faut apprendre.
[^] # Re: Le projet est libre, vous pouvez participer
Posté par Thomas Douillard . Évalué à 7.
Bof, parfois une base même mal fichue est un point de départ qui pourrait motiver quelqu'un qui sait ce qu'il fait à améliorer, en comparaison de reprendre tout à zéro.
[^] # Re: Le projet est libre, vous pouvez participer
Posté par Emmanuel C . Évalué à 1.
Des gens comme Debian et OpenSSL ? Ce genre de propos ne fait que maintenir la sécurité informatique dans une bulle d'expertise inaccessible au commun des mortels. Et cela participe de fait à voir toute notion de sécurité informatique comme étant quelque chose de rebutant, et finalement d’inintéressant. L'idée principale qui sous-tend le logiciel libre, c'est tout de même le partage, pas des remarques toutes faites comme "quand on sait pas, on fait pas" qui n'ont rien de constructive.
[^] # Re: Le projet est libre, vous pouvez participer
Posté par khivapia . Évalué à 7.
"quand on sait pas, on fait pas"
Quand on ne maîtrise pas le sujet, on n'affirme pas que le logiciel répond à un besoin. En particulier avec la sécurité informatique qui est bien plus remplie de chausse-trappe et plus difficilement vérifiable sur sa fonctionnalité principale (la sécurité) que bien d'autres logiciel.
[^] # Re: Le projet est libre, vous pouvez participer
Posté par Thomas Douillard . Évalué à 2.
Encore faut-il savoir qu'on ne sait pas.
[^] # Re: Le projet est libre, vous pouvez participer
Posté par keyser.dyson . Évalué à 1.
Si on n'est pas dans le déni …
[^] # Re: Le projet est libre, vous pouvez participer
Posté par rewind (Mastodon) . Évalué à 7.
La cryptographie (qui est le sous-ensemble de la sécurité informatique qui nous intéresse ici) est bien un domaine d'experts. Elle n'est pas inaccessible au commun des mortels, comme le disait quelqu'un plus haut, comprendre ce qui ne marche pas (comme le cas présenté) requiert assez peu de connaissance. Après, concevoir des algorithmes de sécurité, ça demande d'avoir étudié des maths et de l'informatique pendant un certain nombre d'années. Ça ne s'improvise pas.
Il y a des tonnes de bouquins sur la sécurité, ça n'a rien à voir avec logiciel libre ou pas logiciel libre. Quand on prétend s'attaquer à un domaine, on se renseigne un minimum sur le domaine en question. Mais la sécurité en informatique échappe étrangement à cette règle.
[^] # Re: Le projet est libre, vous pouvez participer
Posté par keyser.dyson . Évalué à 3.
Est-ce qu'il n'existe pas d'approche triviale (ou même simpliste) qui donnent des résultats acceptables ?
[^] # Re: Le projet est libre, vous pouvez participer
Posté par khivapia . Évalué à 3.
Historiquement, non : les méthodes les plus simples se sont fait péter la gueule. Maintenant, on n'en est pas à l'abri, mais il est largement préférable d'utiliser des mécanismes prouvés reposant sur des briques de base (AES par exemple) éprouvées.
[^] # Re: Le projet est libre, vous pouvez participer
Posté par rewind (Mastodon) . Évalué à 3.
Une approche triviale ou simpliste, ça sera trivialement ou simplement cassable. Prend Vigénère par exemple (qui est trivial et simpliste), ça va résister à ta petite sœur, mais ça ne résistera pas à un étudiant en informatique, et encore moins à une agence gouvernementale américaine.
# Ce ne sont pas les algos de cryuptographie le problème....
Posté par khivapia . Évalué à 4.
D'après Snowden, la cryptographie est sûre (au point qu'il a utilité GPG pour transmettre ses secrets). La sécurité des informations qui transitent sur internet actuellement ne repose donc pas tant sur la sécurité des algorithmes de cryptographie (que remplacerait le chiffrement de Vernam) que sur leur implémentation.
Inutile donc de réimplémenter de nouveaux algorithmes !
De plus, le gros problème avec Vernam est l'authentification (les fameux MAC, message authentication code). Si un adversaire passif ne peut pas modifier les messages, ce n'est pas le cas de la NSA qui peut les modifier à la volée (Snowden précise qu'elle fait du man in the middle sur des échanges Diffie-Hellman en temps réel sur internet !). Il est donc essentiel d'avoir un mécanisme d'authentification, problème que ne résout pas le masque jetable (confidentialité sans intégrité = sécurité à chier, même si c'est un peu moins un problème avec des chats qu'avec une information capitale style Snowden ou un virement bancaire où il suffit de modifier 1 bit pour augmenter la somme et quelques-uns pour que ça tombe sur un autre compte).
[^] # Re: Ce ne sont pas les algos de cryuptographie le problème....
Posté par elionne . Évalué à 4.
Diffie-Hellman est vulnérable aux attaques man in the middle, c’est une faiblesse connue de cet algorithme, donc je me demande bien qui utilise DH sans une surcouche de signature des échanges (e.g. HTTPS).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.