Combien de fois y ai-je pensé ? Une bonne solution serait ainsi de ne pas dépendre d’une seule source.

Ainsi, ne dépendez pas d’une solution externe qui demande ainsi de multiples formes d’authentifications ; utilisez par exemple KeePassXC qui est un gestionnaire hors-ligne, chiffré « simplement » avec une phrase de passe.
Et ensuite, sauvegardez bien votre base de mot de passe régulièrement tout en vous aidant de la stratégie de sauvegarde « 3-2-1 »
https://www.nextinpact.com/article/30278/109000-quest-ce-que-strategie-sauvegarde-3-2-1

Si vous avez un serveur distant, auquel vous pouvez facilement vous connecter par mot de passe uniquement (en cas de nécessité), vous aurez de nouveau accès à vos identifiants.
Une clef USB ou un disque dur externe chez quelqu’un d’autre de votre famille est très facile à mettre en place, mais plus difficile à gérer pour garder à jour votre base KeePass.

Pour résumé en très simple, le fait que Google et d’autres services d’envois de courriels ne publient pas la clef privée pour DKIM (Domain Keys Identified Mail) après chaque changement permet ainsi de continuer de vérifier l’authenticité des courriels bien des années après leurs envois.
Pour rappel, le but d’origine de DKIM est de permettre de vérifier l’authenticité de la source du courriel lors de sa réception, une solution contre le spam.

Sauf que si un courriel peut être authentifié bien des années après, les utilisateurs peuvent être victimes « d’extorsion et de chantage » lorsque leurs courriels auront été volés par n’importe quel moyen.
De plus, il se peut qu’au bout de plusieurs années, même si la clef DKIM a été changée de nombreuses fois, que des personnes malveillantes arrivent à recréer la clef privée utilisée légitiment à un moment donnée. Et ainsi, ils pourront forger de nouveaux courriels postdatés, qui ainsi seront authentiques aux yeux des personnes qui souhaitent vérifier.
Donner ainsi la clef privée permettra de pouvoir nier l’authenticité d’un courriel, ne laissant le rôle de vérification de DKIM qu’au moment de la transmission.

Pour ceux qui souhaitent continuer de garantir l’authenticité de leurs courriels, ils peuvent utiliser des outils dédiés pour, comme GnuPG, de leur plein gré, et non de façon implicite choisie uniquement par leurs hébergeurs ou le service envoyeur.

Du coup, j’ai aussi du boulot à faire de mon côté …

Première collisions SHA-1 détectées, il est temps de considérer cet algorithme comme obsolète, en tout cas pour éviter la mitigation (ne panique pas toutefois, ça ne se trouve pas en un claquement de doigts).

Via SebSauvage : http://sebsauvage.net/links/?UEg0RQ

EDIT 2017-02-24 : en français sur LinuxFR : https://linuxfr.org/users/gouttegd/journaux/et-paf-le-sha-1

Algorithmes de chiffrement pour navigateurs Web.

Article intéressant de Jef Mathiot (https://nonblocking.info/) concernant le problème rencontré sur la méthode d'échange de clefs Diffie-Hellman (DH), à cause de partie secrète "par défaut" partagée par de nombreux serveurs.

Voir aussi http://blog.cryptographyengineering.com/2015/05/attack-of-week-logjam.html

Pour ceux qui souhaitent signer leur commit, ce n'est pas l'extension "gpg" qu'il faut utiliser, car cette extension permet de signer le répertoire à un moment donné, et donc de rajouter un commit de plus.

Pour pouvoir signer les commits, il faut pour celà utiliser l'extension "commitsigns", à télécharger actuellement sur cette page https://bitbucket.org/aragost/commitsigs/src/.

Suivez la configuration, et c'est tout, la demande de la signature se fera à chaque commande "commit", pas besoin de faire une quelconque autre action.

Un site qui regroupe une liste de configurations concernant le chiffrement (SSL/TLS) pour différents services.

Oh ! Un TRNG (True Random Numbers Generator) libre, sous forme de clef USB, pour 25$ (soient 22,15€).
Ce périphérique est libre, dans le sens où les pilotes sont aussi libres, et les plans pour monter son propre périphérique aussi. Il fonctionne à base d'un « générateur de sons ».

@TODO

Quelques infos pour comparer à NextCoin et BitCoin et d'autres.

Encore une nouvelle faille découverte dans le monde de la cryptographie et des communications, qui touche SSLv3, un protocole de chiffrement de communications, en principe obsolète mais encore utilisé lors des échanges avec HTTPS avec d'anciens navigateurs ou serveurs web.

Cette faille, nommée POODLE ("Padding Oracle On Downgraded Legacy Encryption") ne touche pas une implémentation, mais le protocole SSLv3 lui-même, protocole créé en 1996, et rendu obsolète par TLS en 1999.
Cette faille est dû au fait que certaines informations lors des échanges ne sont pas définies, permettant à des personnes malveillantes de manipuler et de décrypter les données (« décrypter » = « déchiffrer sans la clef de déchiffrage »).

Alors, pas trop de soucis à ce faire, il existe le protocole TLS, qui le remplace et le surpasse même, et ce depuis sa création en 1999. Alors, pourquoi avons-nous encore SSLv3 ? En parti pour le support de Internet Explorer 6, qui ne supporte pas au dessus de SSLv3.

En prime, glaner dans les docs de Mozilla, voici comment faire pour forcer le support TLS dans le navigateur web Mozilla Firefox :

• tapez dans votre barre d'adresse "about:config",
• cliquez sur "promis, je ferai attention",
• cherchez l'entrée "security.tls.version.min",
• modifiez sa valeur (double-clic, ou clique-droit), et remplacez la valeur par défaut "0" par "1",
• voilà, les modifications sont enregistrées, vous pouvez donc vérifiez en testant sur l'adresse https://www.poodletest.com/

D'autres sources, en français :
https://www.nextinpact.com/news/90427-la-faille-poodle-sslv3-permet-decrypter-donnees-sur-connexion.htm
https://www.numerama.com/magazine/30934-poodle-google-devoile-une-faille-critique-dans-ssl-30.html

Voilà, je me suis lancé dans l'aventure NXT, et pour aider les nouveaux, je suis prêt (dans la limite du raisonnable) à envoyer 1 NXT, actuellement de la valeur de la "taxe" (fee), pour vous permettre de faire une transaction sortante et ainsi valider votre clef publique.

Pour cela, envoyez-moi simplement un courriel, avec votre "account ID" de la forme NXT-????-????-????-?????, ainsi que votre clef publique (car tant que le compte n'a rien envoyé, il n'existe pas sur le réseau et l'identifiant "NXT-..." ne sera pas trouvé).

Pour plus d'infos, en attendant que je détaille de mon côté, commencez par le wiki officiel https://wiki.nxtcrypto.org/

Voilà ce que j'ai à peu près répondu à Sebsauvage à ce sujet, avec des articles de wikipedia.

(lien de Sebsauvage : https://simhacks.github.io/defcon-21/)

--- début ---
Je viens de voir passer un de tes "liens" sur ton Shaarli, au sujet que
les cartes à puce ont un CPU et de la RAM, et exécute du code.
http://sebsauvage.net/links/?hjazZQ

C'est pourtant le cas, et ça n'a rien de secret :
https://en.wikipedia.org/wiki/Subscriber_identity_module#Design
https://en.wikipedia.org/wiki/Javacard

C'est un domaine qui m'intéresse énormément, mais je n'ai toujours pas
trouvé de postes ni de "formations" pour débuter dans ce domaine (même
l'ANSSI qui propose des offres de stage pour étudiants de troisième
année ignore mes courriels...).

Bon, il n'y a pas de quoi s'inquiéter, du peu que j'ai lu et compris.
Mais ça, c'était avant de découvrir l'article, je vais prendre le temps
de bien écouter et lire.
--- FIN ---

Info : ce tuto est fini à 98%, j'ai encore quelques retouches ou remarques à écrire, mais de l'ordre du détail, donc j'ai publié (je vais rajouter le support pour RAID).

Comme tout bon geek qui écrit sur le web, il commence par faire des tutoriels ...

Là, c'est direct du haut niveau, vous allez apprendre à chiffrer votre système d'exploitation Linux ! (basé sur Gentoo)

Bonne lecture.

Pour infos, j'avais commencé à écrire ce tutoriel il y a plus d'un an, mais je n'avais pas l'expérience, et puis j'avais mis de côté ma première distribution chiffrée. Maintenant, avec ce tuto, ça fonctionne aussi bien pour machine desktop que pour serveur.

(en version texte https://thican.net/~thican/installation_systeme_chiffrement-tuto.txt)

@TODO

Des défis, en cryptographie, certains ont l'air sympas ; et pour moi, ça me donnera une occasion de coder plus activement et plus rigoureusement.

Quelques instructions à garder, lorsque l'on veut éviter de voir certaines données stockées en mémoire vive se retrouver sur la swap.

Ce tutoriel permet de connaître et de mettre en place d'autres moyens pour déployer sa clef publique, en plus des traditionnelles méthodes avec les serveurs de clefs, ou le fichier sur votre serveur HTTP.

Ainsi, j'ai pu mettre en place ce système, en utilisant la méthode de téléchargement par URL.
Il suffit donc de rajouter l'option "auto-key-locate pka" dans votre fichier de configuration (~/.gnupg/gpg.conf), et ainsi, en m'écrivant un courriel (si votre client courriels le permet), ma clef publique sera téléchargée.

Pour un peu plus de détails, voici un petit résumé, basé sur mes connaissances et sur l'ensemble des sources que j'ai lues :

« Heartbleed » est une faille concernant un module d'OpenSSL nommé « HeartBeat », découverte ce lundi 7 avril 2014 ; elle touche certaines versions d'OpenSSL, la branche 1.0.1a à 1.0.1f ainsi que la béta 1.0.2 (1.0.1g corrige cette faille, ainsi que la prochaine monture de la béta).
Toutefois, OpenSSL n'est pas concerné pour les versions en 0.9 ou en 1.0.0, ni les systèmes qui n'ont pas ce module de compilé (sous Gentoo, le module HeartBeat est désactivable).

Cette faille s'inscrit au niveau de TLS (“Transport Layer Security” https://en.wikipedia.org/wiki/Transport_Layer_Security), car le rôle de HeartBeat est de maintenir un “keepalive” au niveau de la session TLS ; ce keepalive permet en autre d'éviter de devoir refaire une renégociation avec une « poignée de mains » (“handshake”), qui est peut être assez lourd en terme de quantité de données échangées et aussi en calculs cryptographiques.
Cette faille permet donc de récupérer une petite quantité d'informations, jusqu'à 64ko de mémoire avec une simple requête, ce qui permet donc théoriquement de récupérer les clefs privées stockées en mémoire et ainsi déchiffrer les communications. D'autres informations peuvent fuiter, comme directement des mots de passe, ou des messages, c'est bien pour ces raisons qu'il est conseillé de mettre à jour vos mots de passe, et pour les administrateurs des services, de générer de nouvelles clefs de chiffrement.

Or, pourquoi autant de serveurs fonctionnent-elles avec ces versions 1.0.1 de OpenSSL ? Car ces versions ont d'implémentée la version 1.2 de TLS. Et vu qu'OpenSSL est très répandu dans le monde du logiciel libre et des serveurs, la faille est ainsi très répandue – on parlerait de deux tiers des services web.

Mais qu'en est-ils des autres services ?
Oui, d'autres services se basant sur l'implémentation de TLS d'OpenSSL, comme emails, XMPP, etc. font du TLS. Cependant, OpenSSH n'utilise pas le protocole TLS pour échanger des données, mais son propre protocole ; OpenSSH se base sur OpenSSL, pas pour le TLS, mais pour les algorithmes de chiffrement.

Comme le dit Bruce Schneier : “"Catastrophic" is the right word. On the scale of 1 to 10, this is an 11.”
https://www.schneier.com/blog/archives/2014/04/heartbleed.html

Pour plus de lectures, quelques infos sur la normalisation de l'extension HeartBeat dans la RFC 6520 https://www.bortzmeyer.org/6520.html, des infos techniques sur la faille http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html, une critique de Theo de Raadt sur OpenSSL http://thread.gmane.org/gmane.os.openbsd.misc/211952/focus=211963, encore là sur Numérama http://www.numerama.com/magazine/29026-heartbleed-que-faut-il-craindre-de-cette-faille-openssl.html et sur PCINpact http://www.pcinpact.com/news/86941-heartbleed-openssl-et-question-securite-expliques-simplement.htm et enfin l'info depuis le ministère de la défense. http://cert.ssi.gouv.fr/site/CERTFR-2014-AVI-156/

Au courant depuis lundi soir, Heartbleed est vraiment une faille d'une importance catastrophique.

Plus d'infos https://links.thican.net/?k_fRjw