Non, il y a plein de connexion directes en opérateurs qui ne sont pas sur écoute de la NSA.
Bof… Les backbones étant sous surveillance, la proba reste très élevée.
Et même les liens internes peuvent être surveillés (cf programme MUSCULAR de la NSA)
Et moi à uniquement mon opérateur téléphonique national.
Et à l'opérateur de ton destinataire.
Oui effectivement, mais 99.99999% du temps ça reste national quand même.
Donc pour toi 200 Millions de SMS intercepté dans le monde ce n est pas de la surveillance de masse
Non. Parce que là maintenant tout de suite, j’ai 100% de malchance d’être sur écoute de la NSA en utilisant un paquet TCP/IP alors que j’en ai certainement moins de 0.0001% via un paquet GSM.
Je suis d accord mais perso pour le moment je préfère confier métas datas à Signal et dans une moindre mesure Google.
Et moi à uniquement mon opérateur téléphonique national.
Aeris ton argumentaire de départ été que tes metadatas passant par SMS reste franco-française. Or ce n est pas vrais via l espionnage de masse organisée par de grande puissance.
J’ai dis que dans leurs conceptions initiales, donc sans espionnage, elles restaient franco-françaises.
S’il y a de l’espionnage étranger dans la ligne, on est d’accord qu’elles finiront à l’étranger, par définition même…
Mais j’ai aussi dit que la surveillance étrangère est BEAUCOUP moins présente sur des communications GSM, où il faut du matériel qui coûte très cher (3500€ le téléphone backdooré, 1 à 10k€ l’IMSI catcher), être relativement proche de sa cible (IMSI-catcher = 100-200m d’interception), alors qu’elle est native (centralisation US, GAFAM…) et peu coûteuse sur Internet.
Si tu sais que tu es une cible suffisamment intéressante pour être placée sous écoute téléphonique et d’autant plus par une puissance étrangère, ce qui suppose sans accord officiel avec ton État et sans coopération volontaires des opérateurs, alors abandonne immédiatement l’usage même du téléphone, tu n’y seras certainement pas à l’abri.
C’est ce que je dis : un attaquant doit avoir des ressources. Même dans cette version low-cost.
Je n’irais certainement pas claquer 1500€ dans du matériel pour faire mumuse dans la galerie marchande du coin ou au dernier salon à la mode. Alors que je m’amuse en permanence avec DroidSheep un peu partout sans débourser un centime. Et ça fonctionne diablement bien !
Bref ta solution outre qu'elle réduit les échanges au niveau texte ne préserve pas tes metas information d une puissance étrangère ni d un attaquant un peu motivé.
Si une puissance étrangère m’en veut au point de vouloir mes données GSM, je ne suis pas sûr qu’il existe de technologies numériques fiables pour me protéger…
Il ne faut pas mélanger la surveillance ciblée, contre laquelle tu ne peux rien ou presque et où toute solution numérique est vouée à l’échec, et la surveillance de masse, qui n’est mise-en-place que parce que chère et massive, et exclu donc de facto la surveillance GSM qui est onéreuse et localisée.
De toute façon les échanges sont chiffré mais pas avec qui, quand et la fréquence que tu communique.
Toutes les solutions « grand public » actuelles leakent ces données.
Pour moi un des projets les plus prometteurs à moyen/long terme reste ring.cx qui est devenu un projet officiel GNU.
Sur téléphone, ça réclame la 3G active. Donc tout ce que j’ai dis précédemment et dans mon article reste valable.
En particulier que même si ring.cx lui-même est sécurisé, c’est tout le reste de ton téléphone qui va leaker ta vie privée à sa place…
Quitte à bien finir dans la paranoïa, dans tous les cas tu auras la puce baseband de ton téléphone qui agira contre toi, quelque soit l’application utilisée.
En bref, tu veux VRAIMENT être à l’abri ? Jette ton téléphone.
Ah ? C'est un truc super vieux, comme du WEP ?
Ça m'a l'air super rare quand même… Enfin, j'espère…
Ah non non, même si c’est du WPA2… Il suffit juste que je sois sur le même réseau que toi. Ce qui est une condition immédiatement remplie sur un réseau public. Je peux aussi simplement créer un réseau avec un ESSID « FreeWifi », tu n’imagines même pas le nombre de téléphones mobiles qui s’y connectent automatiquement !
Des attaques, il y en aura partout. Quelqu’un qui te promettra 100% de sécurité est au mieux un menteur.
Le réseau téléphonique est autrement plus sécurité que le réseau Internet, ne serait-ce que parce qu’il est bien plus compliqué de se brancher dessus.
Je détourne ta connection wifi ou 3G starbuck en 10s avec juste mon téléphone Android. Je vais avoir besoin d’au moins 10 ou 20.000 euro et de matériel tenant difficilement dans une valise pour en faire de même avec ta connexion GSM dans le même restaurant.
TL;DR: c’est beaucoup plus facile de faire de l’interception massive et mondiale sur Internet que d’en faire sur le réseau téléphonique qui restera en plus un espionnage ciblé, local et coûteux.
Et au pire, c’est open-bar pour TON gouvernement, certainement pas pour celui des US ou autres.
Ça existe. C’est libre. C’est basé sur les algos de crypto de Signal.
Ça n’utilise pas Google. Ça ne nécessite aucune infrastructure centralisée pour des millions d’utilisateurs. Ça ne sort pas des limites de ton pays. Ça ne passe pas par Internet. Ça n’utilise que des opérateurs nationaux pour lesquels les 2 correspondants ont des contrats digitaux et peuvent poursuivre devant la justice nationale.
De même, le passage de Windows XP à Windows 10 se fait sans soucis, j'ai une machine qui a subit cela. Et non, tu n'a pas à faire de réinstallation à l'arme atomique. Le tout est de prendre soin de son système (pas installer tout et n'importe quoi), bref comme le fait n'importe linuxien..
« Prendre soin de son système » et « Windows » dans la même phrase me fait bien rire… Windows est l’archetype même de l’OS qui se pourrit lui-même au fur et à mesure que le temps passe.
La plupart des softs installés par un utilisateur lambda ne proviennent pas de Microsoft, voire sont récupérés depuis telecharger.com ou zdnet.com. Utilisateurs qui installent des tas de merdes diverses et variées.
Et ça pose BEAUCOUP de soucis lors des upgrades Windows. Celles-ci ne se passent bien que si tu n’as installé que des logiciels officiellement fournis par Microsoft (Office, Exchange, SQL Server, .Net…). Dès que tu as des outils tiers (au pif, LibreOffice, Firefox, des jeux ou même des drivers NVIDIA/ATI), tu risques de casser ces logiciels lors de l’upgrade Windows.
Wé ’fin en même temps, parler de NVIDIA ou AMD sous GNU, c’est un peu bizarre… Forcément, les fabriquants ne font rien pour supporter ce système !
Ici, on parle de truc prévu pour s’installer nativement sous Windows ou GNU et de manière supportée à la base. Pas de machins qui s’installent par dessus la jambe au chausse-pied.
Euh alors là, j’aurais tendance à dire totalement l’inverse…
Je suis toujours capable d’installer un vim 3.0-3 de Lenny 2009 sur une Debian Stretch actuelle. Et ça fonctionne. Essaie d’installer du vieux soft sur un Windows 8 ou 10, tu vas pleurer.
Et surtout, la compatibilité est dans les 2 sens sous GNU (modulo une recompilation), je peux aussi facilement installer des programmes actuelles sur une Lenny sans soucis. Installe Office 365 sur un Windows XP ou 3.1, on va rigoler.
Et pour les maj qui se passent bien, j’ai la MÊME Debian depuis 2005, je n’ai jamais connu de maj qui se soient (réellement) mal passées. Il y a quelques problèmes de temps en temps (un fichier qui manque, le cas tordu pas traité…), mais je n’ai jamais eu besoin de faire de réinstallation ou de sortir l’arme atomique, et je n’ai jamais eu à virer de logiciels pour faire l’upgrade.
Tente de passer de Windows XP à Windows 10, déjà on va rigoler, et ensuite, tu risques d’avoir à virer des logiciels pour y arriver sans tout péter… Grandes chances que tu aies même à effectuer une réinstallation système intégrale au final…
Quand les maj se passent mal sous GNU, c’est essentiellement parce que les mainteneurs s’y prennent comme des manchots (ah ah) plutôt qu’une tare innée de GNU (Ubuntu, si tu m’écoutes…).
Pas plus que ça.
Il y a du cache un peu partout, et les serveurs racines et de 1er niveau sont assez nombreux et bien répartis sur la planète (via de l’anycast).
Le mieux étant quand même de mettre un unbound unique pour tout ton LAN (sur une pi par exemple), qui servira de cache pour toutes tes machines.
Ça a aussi l’avantage de pouvoir faire du vrai DNSSec, une validation DNSSec en dehors du LAN, ça vaut presque 0 en terme de sécurité (il suffit d’ajouter/virer le bit AD avec du MitM pour activer/désactiver la validité de la réponse).
Depuis quand faut-il accepter les CGU du fournisseur de son interlocuteur ?
Ce que fait Gafam des messages que tu envoies à jean.michu@gafam.example est l’affaire de Gafam et de Jean Michu uniquement.
Non justement. Quand Jean Michu m’écrit, il transmet au Gafam des données que je n’ai pas forcément envie de voir traiter par une entité tierce. Idem quand je lui répond, je vais devoir transmettre des données que je n’ai pas envie de voir traiter non plus (ou alors je ne lui répond juste pas, ce qui est généralement très difficile socialement et « efficacement » parlant).
Du coup, si Jean Michu a décidé que ton message devait être traité par les services de Gafam, d’après moi c’est son droit le plus strict et je ne vois rien d’anormal à ce qu’on ne t’ait pas demandé ton avis.
Si une agence immobilière hébergée chez GMail te transmet tout ton dossier bancaire par mail sans te demander la permission avant (vécu personnellement…), c’est quand même massivement chiant et tu ne peux strictement plus rien faire, tes données sont dorénavant chez Google…
Et si tu veux réellement cet appartement, tu n’auras pas d’autre choix que de continuer à balancer tes données très privées à Google (extrait de compte, contrat de travail, attestation d’asurance, attestation de caution, questionnaire médicale…), sauf à te faire très beaucoup chié à devoir te déplacer physiquement lors des horaires d’ouvertures en espérant que l’agent immobilier n’est pas en cours de visite ou en rendez-vous client ou que les pièces à communiquer sont extrêment urgentes…
Perso, j’ai mis en place un script sieve qui prévient les utilisateurs de solutions privatrices que le fait qu’ils correspondent avec moi peut être génant. Pour eux comme pour moi.
J’ai eu des retours assez positifs de ce système, les personnes recevant ce message s’interrogent et reviennent vers moi pour demander plus d’informations ou des systèmes alternatifs.
Ça s’est révélé bien plus efficace que des années d’advocacy intensif :D
Il faut encore que je l’améliore pour faire de la détection plus fine (par exemple le mail de lemonde.fr est hébergé par Google…).
il est raisonnable d'envoyer les informations S, T, et C que je possède à l'utilisateur authentifié ? Est-ce que j'ai un autre choix ?
S, T et C sont publiables sur un lien non fiable. C’est même tout le but recherché par le chiffrement :D
Par contre si tu fais de la crypto côté client, le mieux serait de ne jamais avoir à envoyer ces données sur le réseau.
Tu calcules et conserves S,T,C uniquement côté client, et tu mets juste en place un moyen de transférer la clef maîtresse sur un autre périphérique (par exemple avec un QR code ou une chaîne mnémotechnique).
Je peux garder soit le mot de passe de l'utilisateur, soit la clé de chiffrement K. Quel est la meilleur solution ?
Les 2 solutions sont équivalentes en terme de sécurité (si tu as le pass, tu as la clef K de toute façon).
J’aurais tendance à conserver la clef en mémoire, ça évite d’avoir à redériver le pass et à déchiffrer la clef à chaque fois qu’on en a besoin.
La clé privée ne chiffre rien du tout : DH et ses variantes sont des protocoles pour se mettre d'accord sur un secret commun. J'ai l'impression que tu mélanges un peu tout.
Pas quand on utilise un algo non PFS.
Dans le cas du non PFS (donc sans DHE ni ECDHE), le client et le serveur s’échange un nounce random, l’un des 2 en déduit une pre-master-key (généralement le client) qui est chiffré avec la clef publique de l’autre et est envoyé sur le réseau.
Le récepteur déchiffre cette pre-master-key avec sa clef privée, et les 2 peuvent alors calculer la master-key de session à partir de cette pre-master-key commune (l’un des côtés l’a calculé, l’autre l’a recu).
Sans PFS
Avec PFS
Ça a été tout le drame de Heartbleed et du key reusage : si la NSA a intercepté et stocké l’intégralité des communications entre X clients et un serveur, l’accès à la clef privée du serveur via Heartbleed leurs permettait alors de déchiffrer toutes les pre-master-key et d’en déduire les clefs de session permettant de déchiffrer tout le reste de toutes les communications.
Ce n’est plus du tout le cas avec PFS puisque cette pre-master-key ne circule pas sur le réseau mais est calculée des 2 côtés via un mécanisme en 0-knowledge (Diffie Hellman en version nombre premier pour DHE ou courbe elliptique pour ECDHE).
Et la NSA doit alors casser chaque clef de session indépendament les unes des autres, il n’y a plus de moyen de les casser toutes en une seul fois.
Cela signifie donc que TLS, IPsec et la plupart des protocoles de sécurité ne sont pas sûr, c'est bien ça ?
Tout à fait. C’est même pour ça qu’on a inventé PFS et qu’on demande de faire TRÈS attention à ses configurations IPSec.
Et encore, même en version de base non PFS de TLS, la clef privée ne sert qu’à s’assurer de l’identité de la machine, une clef de session unique est négociée lors du handshake et est utilisée par la suite lors du chiffrement.
PFS a justement fait en plus en sorte que cette clef de session ne soit pas chiffrée par la clef privée mais par une nouvelle clef de session unique négociée de manière fiable par un protocole à 0 knowledge (DHE ou ECDHE).
Où ai-je dis l'inverse ? Par définition il est publique puisqu'il est nécessaire pour déchiffrer. Il doit donc être transmis sur la ligne avec le message (dans le cas général, ici il n'y a pas de ligne puisque l'on protège des mots de passe).
Pas nécessaire de le transmettre. Il peut être recalculé au déchiffrement, par exemple par une dérivation PBKDF2.
Je vois pas ce que ça change. Dans ton schéma plus haut, si MK tombe tes clés uniques tombent aussi.
Oui, mais à la différence d’une clef réutilisée, elle n’a pas vocation à être transporté sur le réseau, de manière directe ou indirecte (via un chiffré).
Ça la rend beaucoup plus robuste en pratique (des attaques ne sont plus possibles, comme une attaque en known-plain-text ou une par oracle par exemple).
Il y a donc un gros fossé en terme de robustesse entre une clef maîtresse réutilisé (inaccessible sans hack de la bdd) et une clef secondaire réutilisée (accessible au moins indirectement par les chiffrés).
Réutiliser une clé n'est pas une erreur grave, tant que le service est le même (par exemple, une clé utilisée pour chiffrer toutes les autres).
Par contre réutiliser un IV est une erreur grave. Tous les couples (clé,IV) doivent être différents. On peut donc utiliser une IV I une fois avec la clé K1 et une fois avec la clé K2 mais jamais deux fois avec la même clé.
C’est complètement faux. Et c’est même l’inverse.
L’IV peut être une donnée publique (qu’on peut par exemple générer de la même manière qu’un sel) et peut être réutilisée sans problème tant qu’on changera la clef de chiffrement (c’est le couple clef+iv qui doit être unique lors du chiffrement).
C’est juste emmerder encore plus un attaquant que de le générer via un moyen cryptographique sûr et de ne pas le communiquer (clef de 256 bits + iv privé de 256 bits peut donner jusqu’à 512 bits de sécurité totale si ils sont générés de manière indépendante).
La clef de chiffrement, elle, doit bien être unique, d’autant plus que certains algos ne nécessitent pas d’IV (RC4, le mode ECB ou CTR de AES, …).
Ça évite en prime de voir l’intégralité des messages qui tombent en cas de compromission de la clef unique (d’autant plus si l’IV est public).
La règle générale est donc clef à usage unique par défaut.
Et tu ne réutilises jamais une clef, sauf à RÉELLEMENT savoir ce que tu fais (et même dans ce cas, ne la réutilise pas, la probabilité est importante que tu ais raté quelque chose dans ton étude).
Oui, pardon pour l’abus de langage, il faut comprendre clef par « clef + iv » effectivement. Tant que le couple est unique, on est tranquille (en tout cas dans le cas de AES).
En théorie, tu n’as même pas besoin de clef maître, puisque tu pourrais la baser sur le mot de passe via une dérivation de clef.
Tu en as besoin en pratique pour permettre le changement de mot de passe et d’éviter de le stocker au login.
La subtilité est d’arriver à obtenir une clef et un iv (même si c’est moins grave pour le 2nd) unique pour chaque chiffrement à réaliser. Réutiliser une clef de chiffrement est une erreur grave en crypto (on est potentiellement capable de deviner des choses sur les textes en clair à partir des données chiffrées uniquement).
À la création de l’utilisateur :
on génère un sel S de 64 bits via un CSPRNG
on génère une clef maîtresse MK de chiffrement de 256 bits via un CSPRNG
on calcule une clef de chiffrement K et un IV IV via K, IV = PBKDF2(password, S)
on chiffre MK via C, T = AES-256-GCM(MK, K, IV)
on stocket S, T et C en bdd, associé à l’utilisateur
Au login utilisateur :
on calcule K, IV = PBKDF2(password, S)
on déchiffre MK via MK = AES-256-GCM(C, K, IV, T)
Pour chiffrer une donnée :
on génère un salt s de 64 bits via un CSPRNG
on calcule une clef de chiffrement k et un iv de 256 bits à partir de de la master key via k, iv = PBKDF2(MK, s) (en résumé c’est cette étape qui manque chez toi)
on chiffre les données d via c, t = AES-256-GCM(d, k, iv)
on stocke s, t et c en bdd
Pour déchiffrer une donnée :
on lit s, t et c en bdd
on recalcule la clef et l’iv via k, iv = PBKDF2(K, s)
on déchiffre les données d via d = AES-256-GCM(c, k, iv, t)
J’ai regardé rapidement ta crypto, elle n’est pas correcte du tout (key/iv reusage, password as key, no HMAC…) :P
Je vais t’ouvrir tout plein de petits tickets sur Bitbucket du coup.
HPKP et DANE n'entrent pas dans ce processus et c'est normal: pour créer un certificat tu dois juste avoir une paire de clés, un nom de domaine et une autorité reconnue.
HPKP et DANE font parti de la stack X.509 et assimilé. DNSSec devrait être déployé partout (98% de MitM mail si tu es en Turquie à cause de ce manque…)
Une CA doit permettre de les respecter.
Sinon c’est juste une « yet another plain old CA ».
C'est toi qui choisit de lier ces 3 concepts, c'est ton problème.
Euh non, c’est ce qu’on appelle une stack TLS correcte en 2016.
HPKP devient limite critique vu les attaques aujourd’hui, TLSA arrivera derrière.
Quand tu sais que Symantec, root-CA, vient d’acquérir BlueCoat, vendeur de matos DPI, HPKP et TLSA, ce ne sont clairement plus des jouets mais ce qui peut faire la différence entre la vie privée ou pas…
Pour dnnsec, c'est la même remarque: tu as choisit de rendre manuel le changement de ressources DNS, donc c'est ton problème.
Je n’ai pas choisi. C’est l’état de l’art d’un serveur OpenDNSSec d’avoir un shadow master hors DMZ. Et ça casse tout l’intérêt de DNSSec si tes clefs sont dispos sur une machine accessible depuis le net.
[^] # Re: FUD
Posté par Aeris (site web personnel) . En réponse au journal WhatsApp, sa porte discrète du fond et les backdoors de Signal. Évalué à 1.
Bof… Les backbones étant sous surveillance, la proba reste très élevée.
Et même les liens internes peuvent être surveillés (cf programme MUSCULAR de la NSA)
Oui effectivement, mais 99.99999% du temps ça reste national quand même.
[^] # Re: FUD
Posté par Aeris (site web personnel) . En réponse au journal WhatsApp, sa porte discrète du fond et les backdoors de Signal. Évalué à 4.
Non. Parce que là maintenant tout de suite, j’ai 100% de malchance d’être sur écoute de la NSA en utilisant un paquet TCP/IP alors que j’en ai certainement moins de 0.0001% via un paquet GSM.
Et moi à uniquement mon opérateur téléphonique national.
[^] # Re: FUD
Posté par Aeris (site web personnel) . En réponse au journal WhatsApp, sa porte discrète du fond et les backdoors de Signal. Évalué à 4. Dernière modification le 22 janvier 2017 à 13:44.
J’ai dis que dans leurs conceptions initiales, donc sans espionnage, elles restaient franco-françaises.
S’il y a de l’espionnage étranger dans la ligne, on est d’accord qu’elles finiront à l’étranger, par définition même…
Mais j’ai aussi dit que la surveillance étrangère est BEAUCOUP moins présente sur des communications GSM, où il faut du matériel qui coûte très cher (3500€ le téléphone backdooré, 1 à 10k€ l’IMSI catcher), être relativement proche de sa cible (IMSI-catcher = 100-200m d’interception), alors qu’elle est native (centralisation US, GAFAM…) et peu coûteuse sur Internet.
Si tu sais que tu es une cible suffisamment intéressante pour être placée sous écoute téléphonique et d’autant plus par une puissance étrangère, ce qui suppose sans accord officiel avec ton État et sans coopération volontaires des opérateurs, alors abandonne immédiatement l’usage même du téléphone, tu n’y seras certainement pas à l’abri.
C’est ce que je dis : un attaquant doit avoir des ressources. Même dans cette version low-cost.
Je n’irais certainement pas claquer 1500€ dans du matériel pour faire mumuse dans la galerie marchande du coin ou au dernier salon à la mode. Alors que je m’amuse en permanence avec DroidSheep un peu partout sans débourser un centime. Et ça fonctionne diablement bien !
Si une puissance étrangère m’en veut au point de vouloir mes données GSM, je ne suis pas sûr qu’il existe de technologies numériques fiables pour me protéger…
Il ne faut pas mélanger la surveillance ciblée, contre laquelle tu ne peux rien ou presque et où toute solution numérique est vouée à l’échec, et la surveillance de masse, qui n’est mise-en-place que parce que chère et massive, et exclu donc de facto la surveillance GSM qui est onéreuse et localisée.
Toutes les solutions « grand public » actuelles leakent ces données.
Sur téléphone, ça réclame la 3G active. Donc tout ce que j’ai dis précédemment et dans mon article reste valable.
En particulier que même si ring.cx lui-même est sécurisé, c’est tout le reste de ton téléphone qui va leaker ta vie privée à sa place…
Quitte à bien finir dans la paranoïa, dans tous les cas tu auras la puce baseband de ton téléphone qui agira contre toi, quelque soit l’application utilisée.
En bref, tu veux VRAIMENT être à l’abri ? Jette ton téléphone.
[^] # Re: FUD
Posté par Aeris (site web personnel) . En réponse au journal WhatsApp, sa porte discrète du fond et les backdoors de Signal. Évalué à 5.
Ah non non, même si c’est du WPA2… Il suffit juste que je sois sur le même réseau que toi. Ce qui est une condition immédiatement remplie sur un réseau public. Je peux aussi simplement créer un réseau avec un ESSID « FreeWifi », tu n’imagines même pas le nombre de téléphones mobiles qui s’y connectent automatiquement !
https://korben.info/droidsheep-le-vol-de-sessions-non-chiffree-est-desormais-possible-sur-android.html
Qui ne me donnera pas ce matériel :)
Et qui sera assez rapidement grillé dans une grande surface en plus…
[^] # Re: FUD
Posté par Aeris (site web personnel) . En réponse au journal WhatsApp, sa porte discrète du fond et les backdoors de Signal. Évalué à 2. Dernière modification le 21 janvier 2017 à 21:00.
Des attaques, il y en aura partout. Quelqu’un qui te promettra 100% de sécurité est au mieux un menteur.
Le réseau téléphonique est autrement plus sécurité que le réseau Internet, ne serait-ce que parce qu’il est bien plus compliqué de se brancher dessus.
Je détourne ta connection wifi ou 3G starbuck en 10s avec juste mon téléphone Android. Je vais avoir besoin d’au moins 10 ou 20.000 euro et de matériel tenant difficilement dans une valise pour en faire de même avec ta connexion GSM dans le même restaurant.
[^] # Re: FUD
Posté par Aeris (site web personnel) . En réponse au journal WhatsApp, sa porte discrète du fond et les backdoors de Signal. Évalué à 3.
C’est bien moins open bar que la version par Internet.
J’ai déjà fait l’explication par ici.
https://blog.imirhil.fr/2015/11/03/smssecure-textsecure-signal.html
TL;DR: c’est beaucoup plus facile de faire de l’interception massive et mondiale sur Internet que d’en faire sur le réseau téléphonique qui restera en plus un espionnage ciblé, local et coûteux.
Et au pire, c’est open-bar pour TON gouvernement, certainement pas pour celui des US ou autres.
[^] # Re: D'accord
Posté par Aeris (site web personnel) . En réponse au journal WhatsApp, sa porte discrète du fond et les backdoors de Signal. Évalué à 6.
Mais Signal poursuit toute entreprise souhaitant utiliser leur algo.
https://medium.com/@wireapp/axolotl-and-proteus-788519b186a7#.myp5iir6d
Ou refuse toute fédération avec d’autres implémentations.
https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165
[^] # Re: FUD
Posté par Aeris (site web personnel) . En réponse au journal WhatsApp, sa porte discrète du fond et les backdoors de Signal. Évalué à 7.
https://silence.im/
Ça existe. C’est libre. C’est basé sur les algos de crypto de Signal.
Ça n’utilise pas Google. Ça ne nécessite aucune infrastructure centralisée pour des millions d’utilisateurs. Ça ne sort pas des limites de ton pays. Ça ne passe pas par Internet. Ça n’utilise que des opérateurs nationaux pour lesquels les 2 correspondants ont des contrats digitaux et peuvent poursuivre devant la justice nationale.
Mais personne ne s’en sert…
[^] # Re: Il oublie LES 2 raisons principales
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi Windows. Évalué à -3.
« Prendre soin de son système » et « Windows » dans la même phrase me fait bien rire… Windows est l’archetype même de l’OS qui se pourrit lui-même au fur et à mesure que le temps passe.
La plupart des softs installés par un utilisateur lambda ne proviennent pas de Microsoft, voire sont récupérés depuis telecharger.com ou zdnet.com. Utilisateurs qui installent des tas de merdes diverses et variées.
Et ça pose BEAUCOUP de soucis lors des upgrades Windows. Celles-ci ne se passent bien que si tu n’as installé que des logiciels officiellement fournis par Microsoft (Office, Exchange, SQL Server, .Net…). Dès que tu as des outils tiers (au pif, LibreOffice, Firefox, des jeux ou même des drivers NVIDIA/ATI), tu risques de casser ces logiciels lors de l’upgrade Windows.
[^] # Re: Il oublie LES 2 raisons principales
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi Windows. Évalué à -1.
Wé ’fin en même temps, parler de NVIDIA ou AMD sous GNU, c’est un peu bizarre… Forcément, les fabriquants ne font rien pour supporter ce système !
Ici, on parle de truc prévu pour s’installer nativement sous Windows ou GNU et de manière supportée à la base. Pas de machins qui s’installent par dessus la jambe au chausse-pied.
[^] # Re: Il oublie LES 2 raisons principales
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi Windows. Évalué à 7.
Euh alors là, j’aurais tendance à dire totalement l’inverse…
Je suis toujours capable d’installer un vim 3.0-3 de Lenny 2009 sur une Debian Stretch actuelle. Et ça fonctionne. Essaie d’installer du vieux soft sur un Windows 8 ou 10, tu vas pleurer.
Et surtout, la compatibilité est dans les 2 sens sous GNU (modulo une recompilation), je peux aussi facilement installer des programmes actuelles sur une Lenny sans soucis. Installe Office 365 sur un Windows XP ou 3.1, on va rigoler.
Et pour les maj qui se passent bien, j’ai la MÊME Debian depuis 2005, je n’ai jamais connu de maj qui se soient (réellement) mal passées. Il y a quelques problèmes de temps en temps (un fichier qui manque, le cas tordu pas traité…), mais je n’ai jamais eu besoin de faire de réinstallation ou de sortir l’arme atomique, et je n’ai jamais eu à virer de logiciels pour faire l’upgrade.
Tente de passer de Windows XP à Windows 10, déjà on va rigoler, et ensuite, tu risques d’avoir à virer des logiciels pour y arriver sans tout péter… Grandes chances que tu aies même à effectuer une réinstallation système intégrale au final…
Quand les maj se passent mal sous GNU, c’est essentiellement parce que les mainteneurs s’y prennent comme des manchots (ah ah) plutôt qu’une tare innée de GNU (Ubuntu, si tu m’écoutes…).
[^] # Re: unbound
Posté par Aeris (site web personnel) . En réponse au journal DNS anonyme. Évalué à 5. Dernière modification le 05 janvier 2017 à 14:38.
Pas plus que ça.
Il y a du cache un peu partout, et les serveurs racines et de 1er niveau sont assez nombreux et bien répartis sur la planète (via de l’anycast).
Le mieux étant quand même de mettre un unbound unique pour tout ton LAN (sur une pi par exemple), qui servira de cache pour toutes tes machines.
Ça a aussi l’avantage de pouvoir faire du vrai DNSSec, une validation DNSSec en dehors du LAN, ça vaut presque 0 en terme de sécurité (il suffit d’ajouter/virer le bit AD avec du MitM pour activer/désactiver la validité de la réponse).
[^] # Re: Script sieve
Posté par Aeris (site web personnel) . En réponse au journal Chiffrement, chiche ?. Évalué à 2. Dernière modification le 09 décembre 2016 à 00:23.
Effectivement, j’en ai conservé une copie ici :
https://imirhil.fr/et-puis-merde-à-la-vie-privée.html
Ça ressemble d’ailleurs furieusement à ce journal :D
[^] # Re: Script sieve
Posté par Aeris (site web personnel) . En réponse au journal Chiffrement, chiche ?. Évalué à 4.
Non justement. Quand Jean Michu m’écrit, il transmet au Gafam des données que je n’ai pas forcément envie de voir traiter par une entité tierce. Idem quand je lui répond, je vais devoir transmettre des données que je n’ai pas envie de voir traiter non plus (ou alors je ne lui répond juste pas, ce qui est généralement très difficile socialement et « efficacement » parlant).
Si une agence immobilière hébergée chez GMail te transmet tout ton dossier bancaire par mail sans te demander la permission avant (vécu personnellement…), c’est quand même massivement chiant et tu ne peux strictement plus rien faire, tes données sont dorénavant chez Google…
Et si tu veux réellement cet appartement, tu n’auras pas d’autre choix que de continuer à balancer tes données très privées à Google (extrait de compte, contrat de travail, attestation d’asurance, attestation de caution, questionnaire médicale…), sauf à te faire très beaucoup chié à devoir te déplacer physiquement lors des horaires d’ouvertures en espérant que l’agent immobilier n’est pas en cours de visite ou en rendez-vous client ou que les pièces à communiquer sont extrêment urgentes…
# Script sieve
Posté par Aeris (site web personnel) . En réponse au journal Chiffrement, chiche ?. Évalué à 2.
Perso, j’ai mis en place un script sieve qui prévient les utilisateurs de solutions privatrices que le fait qu’ils correspondent avec moi peut être génant. Pour eux comme pour moi.
J’ai eu des retours assez positifs de ce système, les personnes recevant ce message s’interrogent et reviennent vers moi pour demander plus d’informations ou des systèmes alternatifs.
Ça s’est révélé bien plus efficace que des années d’advocacy intensif :D
Il faut encore que je l’améliore pour faire de la détection plus fine (par exemple le mail de lemonde.fr est hébergé par Google…).
[^] # Re: Analyseur logique
Posté par Aeris (site web personnel) . En réponse à la dépêche Les ateliers du labx : 1 - l’oscilloscope numérique. Évalué à 1.
Je veux bien le modèle aussi, parce qu’à moins de 200€, je n’ai jamais rien trouvé /o\
[^] # Re: Crypto pas crypto
Posté par Aeris (site web personnel) . En réponse au journal Passprotect - Gestionnaire de mot de passe. Évalué à 1. Dernière modification le 06 octobre 2016 à 10:20.
S, T et C sont publiables sur un lien non fiable. C’est même tout le but recherché par le chiffrement :D
Par contre si tu fais de la crypto côté client, le mieux serait de ne jamais avoir à envoyer ces données sur le réseau.
Tu calcules et conserves S,T,C uniquement côté client, et tu mets juste en place un moyen de transférer la clef maîtresse sur un autre périphérique (par exemple avec un QR code ou une chaîne mnémotechnique).
Les 2 solutions sont équivalentes en terme de sécurité (si tu as le pass, tu as la clef K de toute façon).
J’aurais tendance à conserver la clef en mémoire, ça évite d’avoir à redériver le pass et à déchiffrer la clef à chaque fois qu’on en a besoin.
[^] # Re: Crypto pas crypto
Posté par Aeris (site web personnel) . En réponse au journal Passprotect - Gestionnaire de mot de passe. Évalué à 0. Dernière modification le 04 octobre 2016 à 00:27.
Pas quand on utilise un algo non PFS.
Dans le cas du non PFS (donc sans DHE ni ECDHE), le client et le serveur s’échange un nounce random, l’un des 2 en déduit une pre-master-key (généralement le client) qui est chiffré avec la clef publique de l’autre et est envoyé sur le réseau.
Le récepteur déchiffre cette pre-master-key avec sa clef privée, et les 2 peuvent alors calculer la master-key de session à partir de cette pre-master-key commune (l’un des côtés l’a calculé, l’autre l’a recu).
Sans PFS
Avec PFS
Ça a été tout le drame de Heartbleed et du key reusage : si la NSA a intercepté et stocké l’intégralité des communications entre X clients et un serveur, l’accès à la clef privée du serveur via Heartbleed leurs permettait alors de déchiffrer toutes les pre-master-key et d’en déduire les clefs de session permettant de déchiffrer tout le reste de toutes les communications.
Ce n’est plus du tout le cas avec PFS puisque cette pre-master-key ne circule pas sur le réseau mais est calculée des 2 côtés via un mécanisme en 0-knowledge (Diffie Hellman en version nombre premier pour DHE ou courbe elliptique pour ECDHE).
Et la NSA doit alors casser chaque clef de session indépendament les unes des autres, il n’y a plus de moyen de les casser toutes en une seul fois.
[^] # Re: Crypto pas crypto
Posté par Aeris (site web personnel) . En réponse au journal Passprotect - Gestionnaire de mot de passe. Évalué à 2. Dernière modification le 03 octobre 2016 à 21:49.
Tout à fait. C’est même pour ça qu’on a inventé PFS et qu’on demande de faire TRÈS attention à ses configurations IPSec.
Et encore, même en version de base non PFS de TLS, la clef privée ne sert qu’à s’assurer de l’identité de la machine, une clef de session unique est négociée lors du handshake et est utilisée par la suite lors du chiffrement.
PFS a justement fait en plus en sorte que cette clef de session ne soit pas chiffrée par la clef privée mais par une nouvelle clef de session unique négociée de manière fiable par un protocole à 0 knowledge (DHE ou ECDHE).
Pas nécessaire de le transmettre. Il peut être recalculé au déchiffrement, par exemple par une dérivation PBKDF2.
[^] # Re: Crypto pas crypto
Posté par Aeris (site web personnel) . En réponse au journal Passprotect - Gestionnaire de mot de passe. Évalué à 2.
Ah oui, j’avais zappé le nounce effectivement /o\
Oui, mais à la différence d’une clef réutilisée, elle n’a pas vocation à être transporté sur le réseau, de manière directe ou indirecte (via un chiffré).
Ça la rend beaucoup plus robuste en pratique (des attaques ne sont plus possibles, comme une attaque en known-plain-text ou une par oracle par exemple).
Il y a donc un gros fossé en terme de robustesse entre une clef maîtresse réutilisé (inaccessible sans hack de la bdd) et une clef secondaire réutilisée (accessible au moins indirectement par les chiffrés).
[^] # Re: Crypto pas crypto
Posté par Aeris (site web personnel) . En réponse au journal Passprotect - Gestionnaire de mot de passe. Évalué à 1. Dernière modification le 03 octobre 2016 à 14:28.
C’est complètement faux. Et c’est même l’inverse.
L’IV peut être une donnée publique (qu’on peut par exemple générer de la même manière qu’un sel) et peut être réutilisée sans problème tant qu’on changera la clef de chiffrement (c’est le couple clef+iv qui doit être unique lors du chiffrement).
C’est juste emmerder encore plus un attaquant que de le générer via un moyen cryptographique sûr et de ne pas le communiquer (clef de 256 bits + iv privé de 256 bits peut donner jusqu’à 512 bits de sécurité totale si ils sont générés de manière indépendante).
La clef de chiffrement, elle, doit bien être unique, d’autant plus que certains algos ne nécessitent pas d’IV (RC4, le mode ECB ou CTR de AES, …).
Ça évite en prime de voir l’intégralité des messages qui tombent en cas de compromission de la clef unique (d’autant plus si l’IV est public).
La règle générale est donc clef à usage unique par défaut.
Et tu ne réutilises jamais une clef, sauf à RÉELLEMENT savoir ce que tu fais (et même dans ce cas, ne la réutilise pas, la probabilité est importante que tu ais raté quelque chose dans ton étude).
[^] # Re: Crypto pas crypto
Posté par Aeris (site web personnel) . En réponse au journal Passprotect - Gestionnaire de mot de passe. Évalué à 2.
Oui, pardon pour l’abus de langage, il faut comprendre clef par « clef + iv » effectivement. Tant que le couple est unique, on est tranquille (en tout cas dans le cas de AES).
[^] # Re: Crypto pas crypto
Posté par Aeris (site web personnel) . En réponse au journal Passprotect - Gestionnaire de mot de passe. Évalué à 4. Dernière modification le 03 octobre 2016 à 13:04.
En théorie, tu n’as même pas besoin de clef maître, puisque tu pourrais la baser sur le mot de passe via une dérivation de clef.
Tu en as besoin en pratique pour permettre le changement de mot de passe et d’éviter de le stocker au login.
La subtilité est d’arriver à obtenir une clef et un iv (même si c’est moins grave pour le 2nd) unique pour chaque chiffrement à réaliser. Réutiliser une clef de chiffrement est une erreur grave en crypto (on est potentiellement capable de deviner des choses sur les textes en clair à partir des données chiffrées uniquement).
À la création de l’utilisateur :
Au login utilisateur :
Pour chiffrer une donnée :
Pour déchiffrer une donnée :
# Crypto pas crypto
Posté par Aeris (site web personnel) . En réponse au journal Passprotect - Gestionnaire de mot de passe. Évalué à 8. Dernière modification le 03 octobre 2016 à 10:41.
Hello !
J’ai regardé rapidement ta crypto, elle n’est pas correcte du tout (key/iv reusage, password as key, no HMAC…) :P
Je vais t’ouvrir tout plein de petits tickets sur Bitbucket du coup.
Cf https://blog.imirhil.fr/2016/03/03/chiffrement-donnees.html
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 0.
HPKP et DANE font parti de la stack X.509 et assimilé. DNSSec devrait être déployé partout (98% de MitM mail si tu es en Turquie à cause de ce manque…)
Une CA doit permettre de les respecter.
Sinon c’est juste une « yet another plain old CA ».
Euh non, c’est ce qu’on appelle une stack TLS correcte en 2016.
HPKP devient limite critique vu les attaques aujourd’hui, TLSA arrivera derrière.
Quand tu sais que Symantec, root-CA, vient d’acquérir BlueCoat, vendeur de matos DPI, HPKP et TLSA, ce ne sont clairement plus des jouets mais ce qui peut faire la différence entre la vie privée ou pas…
Je n’ai pas choisi. C’est l’état de l’art d’un serveur OpenDNSSec d’avoir un shadow master hors DMZ. Et ça casse tout l’intérêt de DNSSec si tes clefs sont dispos sur une machine accessible depuis le net.