Le 21/04/2018 à 00h 05

Le brulage des végétaux dans des incinérateurs fermés sera interdit mais pas le brulage en plein air ni les cheminées ?

Que dire alors des barbecues, des cheminées, du chauffage au bois (pourtant vanté comme énergie renouvelable) voilà comment on va passer aux brûleurs au gaz ou au fuel… non renouvelables (ou si peu).

Le problème est pourtant pas tant la fumée, que les particules fines: ces incinérateurs de végétaux n’en produisent pas car leurs fumées sont chargées d’humidité et de goudrons et donc s’agglomèrent et retombent. J’ai du mal à croire que cela contribue à hauteur de 3%, sauf si on ne compte que les grosses particules et qu’on ignore les particules fines des véhicules à moteur.

En revanche ces 3% s’ils existent réellement viennent des incinérateurs à très haute température des déchets ménagers issus de la collecte. si on veut les réduire, il vaut mieux agir sur le recyclage, le tri sélectif et arrêter bon nombre de ces incinérateurs industriels.

Bruler des végétaux verts ne pollue pas l’air en particules fines, et les fumées qui retombent (sur une aire très limitée en surface) ne contaminent pas les sols et les eaux (au contraire des fumées des incinérateurs industriels qui déversent quantités d’oxydes de métaux lourds et des dioxines sur des zones extrêmement étendues).

 Même les odeurs des fumées végétales ne sont pas désagréables et on les sent moins et à plus faible distance, il y a certes certains gaz toxiques (des benzènes) mais ils se dispersent totalement et se dissolvent dans l’eau et sont facilement dégradés  (au contraire des incinérateurs de déchets ménagers qui puent vraiment et dont les particules sont peu condensées et même sont hydrophobes, car chargées facilement par leurs concentration en ions métalliques lourds soumis à la lumière solaire, ils restent très longtemps en suspension dans l’air sans retomber et donc sans être dégradés, et au contraire leur activité chimique n’en devient que plus dangereuse, ces particules fines au lieu de s’agglomérer ont tendance plutôt à se dégrader en particules encore plus fines et plus chargées et encore plus actives, elles atteignent facilement les couches plus hautes de l’atmosphères, modifient la magnétosphère, transforment certains rayonnement solaires ou astronomiques en rayonnement encore plus dangereux qui n’est pas absorbé par l’humidité des couches basses; elles décomposent le CO2 en monoxydes, dénaturent l’oxygène O2 de la biosphère en ozone O3 hyper-oxydant)

Franchement là ils se trompent de combat ! Ce n’est pas les fumées végétales qui polluent, ce sont les particules fines et les fumées d’incinérateurs industriels.

Sinon autant pondre un décret pour interdire toutes les cheminées et le chauffage au bois ou au charbon de bois et imposer le fuel et le gaz fossile.

Regardez un peu les forêts: certaines ont besoin dêtre régulièrement brulées pour réenchir le substrat des sols et renouveler le cheptel génétique, ou simplement pour qu’elles se reproduisent: ces feux de forêts ou de broussailles (à condition de les contrôler) n’ont jamais contaminé les sols et ce sont exactement les mêmes végétaux qu’on brule dans les incinérateurs de jardin.

En revanche il faut interdire le brûlage des plastiques, des pneus, des huiles de moteur, des déchets de chantiers, et des ordures ménagères (qui sont en grande partie des emballages, et des papiers traités et imprimées avec des encres riches en métaux lourds, y compris les journaux, magazines et livres, enveloppes).

On peut aussi imposer aux possesseurs de cheminées ou de brûleurs l’utilisation de capteurs pour mesurer la toxicité des fumées. Le ramonage obligatoire tous les ans (ou deux fois par an dans certaines villes) pourrait aussi imposer un prélèvement des suies pour en mesurer la concentration en toxiques (notamment en métaux lourds), et ensuite taxer cette toxicité: les fournisseurs de fuel et gaz devront adapter leurs tarifs et réduire l’usage des métaux lourds dans leurs procédés de raffinages mais aussi les propriétaires éviteront de bruler n’importe quoi dans leur cheminée: juste du bois mais aucun emballage, très peu de papier et pas de produits pétroliers pour l’allumage.

S’il s’agit de brûleurs à gaz ou au fuel, des essais de mesure directe des fumées devraient être fait pour vérifier la toxicité des rejets, l’absence de production de monoxydes ou d’oxydes d’azote, donc des combustions plus complètes, des filtres à particules efficaces et l’obligation de traiter les filtres usagés (qui seraient numérotés et consignés: la remise des filtres à particules usagés permettrait de renforcer le ramonage obligatoire et contrôler leur efficacité réelle).

Le 02/08/2016 à 20h 34

Ben non, l’article va trop vite: cette update n’est pas encore disponible pour la version Pro, juste les versions mobiles et Home. Je n’attendanis psa encore la version Enterprise, mais la version Pro est aussi largement utilisée (et même préinstallée sur plein de nouveaux PC vendus aurpès du grand public, certes pas les premiers prix).
 
J’espère que cette mise à jour ne sera pas aussi pénible que la 1511 (qui a mis chez moi des mois pour passer sans planter en cours d’installation sur “l’écran vert” post boot, un bogue récurrent qui existe même d’avant la sortie commerciale de windows 10, au temps des bêtas avec des bogues signalés et reconnus depuis près de 2 ans, qui obligent à des tas de manipulations ultracompliquées et dangereuses pour résoudre ce bloquage).

Pendant des mois mon PC rebootait tous les jours en essayant d’installer la 1511, plus se bloquait sur l’écran vert, obligeant à un reset et une restauration, puis à nouveau le téléchargement complet (identique) dans la journée (avec en plus le gros bogue toujours pas corrigé de Windows Update qui utilise 100% de la bande passante pendant une heure ou deux car il abuse les règles de bases en ouvrant une centaine de sessions HTTP en parallèle, que ce soit pour le nouveau mode de téléchargement en P2P/WUDO ou avec l’ancien mode avec BITS, car Windows Update ignore même totalement les “group policies” concernant BITS et WUDO si c’est pour charger une image complète du système…)

Méfiance donc: soit ça marche du premier coup soit ça va ENCORE planter tous les jours pendant des semaines ou des mois en recherche de solution (car Windows Update ne fournit absolument aucune aide et ses fichiers logs sont très lourds et pourtant oublient de diagnostiquer correctement les causes si le plantage survient durant la phase “SAFE_OS” c’est à dire l’écran vert après reboot, où des tas de pilotes Microsoft sont désactivés et même certains ne fonctionnent pas correctement en mode WinPE, le mode de fonctionnement de cet écran vert d’installation).

Le 05/07/2016 à 19h 23

Un article Wikipédia à lire sur la question des CSPRNG:

Cryptographically_secure_pseudorandom_number_generator

(sur la wikipédie anglophone).

Le 05/07/2016 à 19h 10

matériel non libre donc possibilité d’intégrer un backdoor: c’est techniquement facile de générer une seconde clé qui marche aussi bien que la clé normale, mais que seul l’OEM constructeur du matériel connait à la fabrication (en théorie) mais que la NSA (ou une agence chinoise… vu que le matériel est fabriqué en Chine) peut aussi obtenir… y compris pour espionner sa population ou ses opposants politiques, ou voler des secrets à l’étranger.

Les algos à clé publique, même avec beaucup de bits (et surtout ces clés là, supposées fortes) peuvent très bien utiliser 3 clés différentes et pas seulement deux; avec l’algo RSA, les deux clés normales sont deux nombres: la clé publique est le produit des deux, une clé est détenue par le propriétaire qui peut décrypter le message encodé par la clé publique; mais avec 3 nombres ça marche aussi (tout dépend de la façon dont on crée la fonction “produit”: la clé privée peut être en fait le produit de deux nombres, dont un est détenu par le fabriquant… résultat un backdoor.

Il y a d’autres techniques encore dans la génération des clés privées qui ne sont pas si aléatoires qu’on le voudrait. L’algo RSA d’ailleurs (dans sa forme publiée) ne cherche même pas à assurer que les deux nombres sont premiers, juste qu’ils ont une FORTE probabilité de l’être. Produire une paire de nombres premiers très longs est très couteux en calcul et factoriser la clé privée l’est tout autant: les clés privées de 1024 bits ne sont pas réellement aléatoires et ce ne sont pas les matériels qui les génère directement: ils créent eux aussi des clés dérivées.

Apple ne veut pas le dire mais son algo doit certainement ne pas utiliser les clés au hasard (et Apple s’en sert pour arriver à bloquer des iPhones volés même quand ils ont été “complètement” effacés logiciellement).

Les appareils militaires en revanche utilisent leurs propres générateurs de clés aléatoire avec des matériels bien plus sophistiqués (au résultat réellement imprédictibles) tels que des mesures d’effets quantiques. On n’a pas ça dans nos matériels grand public, même si on en a des versions limitées tels que les capteurs de température ou de bruit électronique (mais à la résolution très limitée). Pour faire des clés privées avec nos matériels ils faut combiner un très grand nombre de sources matérielles aléatoire, un nombre tellement grand que cela demanderait un temps énorme à les obtenir en nombre suffisant, peut-être même plsu que la dure de vie du matériel.

On attend encore sur le marché une puce de génération de nombres quantiques permettant d’alimenter le fameux “/dev/random” ou similaire utilisé dans les OS et les bibliothèques de sécurité pour générer les clés à la demande en un temps raisonnable. Mais nos générateurs de clés sont très rapides, trop rapides (donc pas fiables: ils se contentent que d’un nombre limité de mesures, pas réellement totalement indépendantes entre elles). Il n’y a pas d’appareil grand public disposant de réels générateurs aléatoires forts: on fait tous confiance aux constructeurs et éditeurs de logiciels, même quand on utilise un noyau Linux libre.

Si on voulait sécuriser les OS libres, ce serait bien de développer une petite puce de mesure de bruit quantique (avec une grande précision des mesures), et pas seulement mesurer des varaibles faibles comme la rotation d’un disque, le nombre de “memory page faults” dans un kernel, les mouvements d’une souris, la vitesse de frappe ou même un périphérique de capture audio (bruit de fond, vent), ou le bruit électrique de charge ou de décharge d’une batterie (les capteurs de batterie ont une fréquence de capture et une résolution très faible: Un noyau Linux peut mettre des années avant que le contenu de ses variables d’état pour /dev/random soit réellement aléatoire et il n’est pas dit qu’il ne produit pas des “boucles” d’états identiques.

 De plus on sollicite beaucoup trop souvent ce générateur “faible”: les clés successives obtenues sont trop liées entre elles: si on arrive à obtenir une clé générée peut de temps après celle qu’on cherche à casser, on peut déduire de cette clé des propriétés que la clé recherchée peut vérifier, en nombre suffisant pour que l’attaque en force brute soit techniquement facile à peu de frais (sans solliciter votre appareil: la clé sera cassée à distance sur une autre machine, il n’y aura pas d’activité suspecte que celle de demander à votre appareil quelques clés aléatoires “nouvelles”: c’est facile à faire avec une application commune qui utilise un protocole SSL: il suffit que cette application se connecte assez souvent: genre appli Facebook, ou Google ou un jeu en ligne: ces nombres pseuo-aléatoires peuvent être diffusés en grand nombre par votre appareil, assez pour permettre de casser une autre clé privé qui aurait été générée longtemps avant et que votre appareil n’a pas révélée et qu’un craqueur n’a meêm pas tenté de demander ou d’utiliser indirectement).

Bref un truc à développer: une petite clé USB ou une puce MicroSD qui génère de vrais nombres aléatoires pour alimenter le jeu de données du générateur aléatoire du système, et aussi souvent que les applications demandent de nouvelles clés aléatoires via une API de l’OS. Là nos systèmes auront une vraie sécurité nous mettant à l’abri des intrusions par les constructeurs (et indirectement via eux, par les agences d’espionnage américaines ou chinoises). Mais est-ce que ce type de matériel sera autorisé à l’exportation par les agences de sécurité nationales, qui les réserve pour leur usage militaire?

En attendant il doit y avoir moyen de bricoler ça avec des appareils de mesure à haute fréquence (genre oscilloscope), et un peu de matériel générateur de bruit quantique mesurable (par exemple certains transistors en limite de stabilité sur leur jonction, ou une zimple diode zéner, ou même la cellule CCD d’une caméra). Un bon bricoleur pourrait installer ça dans une alim et sortir le résultat sur une prise USB et un minicontroleur avec un tout petit peu de mémoire pour stocker des mesures inutilisées ou les raffraichir en quantité suffisante pour l’usage par un OS, et un tout petit pilote pour lire les données de ce port USB et raffraichir le générateur aléatoire de l’OS, puis quelques tweaks poru que ce générateur demande des mesures plus souvent à ce petit appareil.

Autre paliatif en attendant: quand on ne prend pas de photo sur un smartphone, régler l’appareil photo  à la limtie de la saturation pour lui faire observer les zones “noires” avec une forte amplification. Le résultat c’est du bruit comparable à ce qu’on voit dans les trames d’une photo numérique non traitée (on en voit moins dans les photos JPEG, là on parle de photos en mode “RAW”). Idem en utilisant le micro en suramplification (ça marchera dans une atmospère sonore pas trop bruyante), ou en mettant le micro devant un ventilo de refroidissement sur les PC de bureau et notebooks.

Mais sans ça nos PC et smartphones ont des générateurs aléatoires très faibles. Générer des clés RSA sur ces appareils produit des clés cassables si on dispose d’autres clés générées de la même façon (et faciles à obtenir par des tiers pas tellement de confiance).

Toute la sécurité des algos à clé publiques (SSL, HTTPS…) tient à la qualité du générateur aléatoire de votre machine. Mais elle est très médiocre.