Interview d'un des développeurs de TrueCrypt (via http://links.kevinvuilleumier.net/?hbR2Aw)

Est-il possible de distinguer facilement si des données sont compressées ou chiffrées ? Ce hacker a réussit à créer un algo qui différencie les deux avec une exactitude 98%.

Haha... encore une bonne blague sur la vie privée: Apple prétend que iMessage n'est pas écoutable, pas même par Apple, car les messages sont chiffrés de bout en bout.
Apple a légèrement oublié un détail: OUI, les messages sont chiffrés de bout en bout, mais la clé, elle, transite par les serveurs d'Apple... qui pourrait donc sans problème faire de la substitution de clés à la volée. Apple a donc les moyens techniques de déchiffrer tous les messages échangés.

Putain de putain, Google, merde quoi !  Depuis Android 2.3, Google a *baissé* la sécurité de TLS: Au lieu d'utiliser RSA-AES256-SHA, ils sont passés à RC4-MD5. Un truc que plus personne ne devrait utiliser.
Google serait-il noyauté par la NSA ? L'explication semble plus simple: Google a juste collé aux réglages par défaut... de Java 6 (qui d'ailleurs n'est plus supporté par Oracle).
C'est vraiment nul :-(

Steve Gibson propose un système d'authentification pour remplacer login/mot de passe. Son principe est bon, mais il nécessite 1) un smartphone  2) un accès internet sur le smartphone.
L'autre soucis que je vois, c'est que quelqu'un qui vous pique votre téléphone peut se loguer directement sur votre compte.  :-/

(Attention, je vais encore parler crypto).

Contexte: Le NIST standardise des algorithmes cryptographiques, tels que les algorithmes de hashage SHA-1 et SHA-2 (aussi connu sous les noms SHA-256, SHA-512...).
Différents algos étaient en compétition depuis 5 ans pour définir le nouveau standard SHA-3. Après beaucoup d'analyses, c'est l'algo "Keccak" qui a été retenu. Bien.

Pour en faire un standard, le NIST a donc créé une implémentation de référence à partir du whitepaper original. Gros soucis: Ils ont modifié substantiellement l'algo d'origine. Des modifications internes assez peu compréhensibles et qu'ils n'ont pas clairement justifiées. Et ils ont également réduit sa taille (L'algo d'origine produisait 224, 256, 384 et 512 bits. La nouvelle version seulement 128 et 256 bits.). Ce qui en fait un algo qui - au final - n'est pas plus sûr que SHA-2.

L'autre soucis, c'est que les modifications en font un algo très différent du Keccak d'origine, et rend donc caduc toutes les analyses cryptographiques de l'algo d'origine. On ne sait donc rien de la sécurité de ce nouvel algo, alors que sa sélection était le résultat de 5 ans de compétition et d'analyse avec ses concurrents.

Dans le contexte actuel, tout cela semble terriblement louche à la communauté crypto.  On a pas fini d'en entendre parler.

EDIT: Un avis de quelqu'un plus compétent que moi sur le sujet: http://hemltreppler.net/shaarli/?D6LOBA

Bwwwaaaaa.... C'est pire que je pensais.
Ceci est la liste d'entreprises utilisant l'algo foireux recommandé par la NSA (cf. http://sebsauvage.net/links/?1YZ3Nw).
On y retrouve Cisco, Apple, Motorola, Toshiba, McAfee, Juniper, HP-UX, IBM, Oracle, Symantec, SAP, Intel, Microsoft, CheckPoint, Thales, RedHat, R.I.M., ZTE, Avaya, WindRiver... et OpenSSL.
Il y en a dans tous les domaines: des firewalls aux VPN en passant par les systèmes médicaux ou la VOIP.
Ça fait froid dans le dos, et il est difficile d'évaluer la quantité de produits réellement touchés: Ils ne listent ici que les libs propriétaires incluant la techno de RSA en question, non les produits les utilisant, ni si cet algo est actif dans la config par défaut.

EDIT: Article complémentaire: http://sebsauvage.net/links/?ZUgdvA

BOUH QUE C'EST LAID.

Résumons: Régulièrement, le NIST (un organisme de standardisation américain) fait voter des standards de crypto. C'est d'eux que proviennent des standards comme l'AES ou SHA-2 (aka SHA256).
En 2007, différents algos générateurs de nombres pseudo-aléatoires avaient été proposés comme standard, dont l'un (Dual EC DRBG) recommandé par la NSA. A l'époque, Bruce Schneier (une sommité en crypto) avait analysé l'algo et trouvé des faiblesses (un biais de l'algo) qui - je cite - "ne peut être décrit que comme une backdoor". Mais il n'avait rien pour le prouver.

Nous sommes en 2013, et nous y somme: Cet algo semble en effet posséder des failles volontaires permettant à la NSA de déchiffrer les protocoles utilisant cet algo. En fait, comme beaucoup d'algo, il contient des constantes. Schneier soupçonne ces constantes d'avoir été calculée à dessein, et de faire partie d'une formule (un peu comme les paires clés privées/clés publiques).
La personne possédant le nombre secret correspondant pourrait déchiffrer un trafic TLS/SSL utilisant cet algo en observant seulement 32 octets échangés.  Et il n'y a pas que TLS qui utilise Dual EC DRBG. Il y a tout un tas de produits, à commencer par ceux de la célèbre société RSA qui - du coup - recommande à ses clients d'éviter cet algo comme la peste.
Le NIST lui-même déconseille désormais Dual EC DRBG et ré-ouvrira des discussions sur les générateurs de nombres pseudo-aléatoires.

La question posée par l'auteur de l'article est pertinente: Pourquoi la société américaine RSA a choisi cet algo comme algo par défaut dans la majorité de ses produits, alors qu'il savaient dès le départ que c'était le bébé de la NSA ?

EDIT: Une liste d'entreprises utilisant cet algo: http://sebsauvage.net/links/?FZvDyA
EDIT: Article complémentaire: http://sebsauvage.net/links/?ZUgdvA

« Ces collaborations lui auraient permis d'insérer « secrètement » des vulnérabilités dans les systèmes de chiffrement des données mis au point par les firmes. »
Du lard ou du cochon ? Si c'est vrai, ça va être un foutu pavé dans la marre des éditeurs de logiciels de sécurité et chiffrement. Effet de bord possible: Ça pourrait donner un bon coup de pouce aux logiciels libres.
EDIT: Chez Numérama: http://www.numerama.com/magazine/26916-comment-la-nsa-peut-contrecarrer-le-chiffrement-des-communications.html

Nous voici encore avec un exemple d'un mauvais générateur de nombres aléatoires qui plombe la sécurité d'une application.

Les progrès en mathématiques appliqués dans la factorisation des grands nombre pourraient voir le glas de l'algorithme RSA. Oh on y est pas encore, mais c'est une éventualité dans les années à venir.
Ils recommandent de passer progressivement aux ECC (courbes elliptiques).

Curiosité cryptographique:

D'abord, l'explication du bloom filter: https://fr.wikipedia.org/wiki/Filtre_de_Bloom
En gros, c'est un test qui permet de vérifier si un élément appartient à un ensemble.
EDIT: Voir aussi : http://billmill.org/bloomfilter-tutorial/

Celui-là est cryptographiquement sûr:  Cela permet à autrui de tester si un élément appartient à un ensemble sans posséder cet ensemble (et avec, je présume, un coût prohibitif de calcul pour obtenir l'ensemble complet.). Vous pouvez donc transmettre une structure de données qui permet à chacun de vérifier localement (et sans connexion) si un élément fait partie de l'ensemble, mais sans qu'ils possèdent eux-même l'ensemble de données.
L'avantage du bloom-filter cryptographique est qu'il est nettement plus compacte qu'une simple liste de hashs.

Je rappelle juste que ce chiffrement est un énorme LOL et n'assure absolument pas que vous seul pouvez voir les fichiers, puisqu'il est réalisé COTÉ SERVEUR.  Doh.
Source: http://news.cnet.com/8301-13578_3-57594171-38/google-tests-encryption-to-protect-users-drive-files-against-government-demands/

Encore un excellent article chez Naked Security qui essaie de montrer graphiquement le problème de sécurité de CryptoCat lié à son mauvais générateur de nombres pseudo-aléatoires.
(Les générateurs de nombres pseudo-aléatoire (PRNG) sont critiques pour la sécurité informatique, et pas toujours facile à faire correctement. J'en avais déjà parlé là: http://sebsauvage.net/rhaa/index.php?2011/08/25/07/32/33-le-hasard-est-une-chose-difficile-pour-un-ordinateur)

L'article explique l'attaque d'extension de hash:
Si vous utilisez hash(secret+donnée) pour signer une donnée (pour l'authentifier), un pirate est capable d'ajouter des données et d'obtenir une signature valide même sans connaître le secret. Dit autrement: hash(secret+donnée+ajouté) sera accepté par votre serveur, même si le pirate ne connaît pas le secret.
Voilà pourquoi, pour signer des données, il ne faut pas bricoler ça vous-même: Utilisez HMAC.

Les sources de son attaque sont sur GitHub: https://github.com/iagox86/hash_extender

Et encore un autre extension navigateur pour faire de l'OpenPGP dans le navigateur.

Ah ! Bruce Schneier rejoint le conseil d'administration de l'EFF. C'est une bonne chose.
L'EFF est une association qui lutte pour défendre nos droits et notre vie privée, une sorte de Quadrature Du Net américaine. Bruce Schneier est une sommité de la cryptographie, auteur de plusieurs algorithmes et auteur du livre "Cryptographie appliquée" (une référence dans le domaine).

Et merde... Opera s'est fait pirater et voler un certificat qui sert à signer ses exécutables. On verra donc apparaître des malwares avec des signatures valides et acceptés par Windows. (Jusqu'à ce qu'Opera révoque son certificat, en espérant que tout le monde vérifiera cette révocation. Je doute que Windows vérifie systématiquement la révocation des certificats, d'ailleurs. Ça arrivera sans doute avec une mise à jour WindowsUpdate, c'est à dire bien trop tard.)

"Perfect Foward Secrecy", la petite option de HTTPS que presque personne n'utilise, et qui empêche le déchiffrement futur des données échangées par HTTPS et capturées. Plus de sites devraient l'utiliser.
Remarquez, cela ne lève en rien le problème de confiance implicite abusive dans les autorités de certifications (à l'image du certificat du D.O.D. inclu dans les produits Apple).

Tapez votre message et entrez l'adresse email du destinataire: Il recevra un email contenant un lien vers le message stocké dans un ZeroBin.
Pratique pour envoyer un message anonyme (ou non) et dont le texte ne sera pas lisible par l'hébergeur mail et ne pourra pas y rester stocké ad vitam eternam (puisqu'on peut faire expirer le texte).
Et comme ZeroBin supporte les discussions, cela vous permet de poursuivre la discussions dans ZeroBin sans laisser de trace dans vos boites email respectives. En prime, cela vous permet également de discuter avec un anonyme.

Tiens, voilà une excellente question: Dans la crypto asymétrique (à clés publiques), pourquoi n'utilisons-nous pas plus les courbes ellitptiques (ECC) au lieu de RSA ?
La réponse dans l'article. (TL;DR: En gros, c'est le syndrome MP3: RSA était là le premier.)

mmm... intéressant. Une réimplémentation d'OpenPGP en Javascript.
(via http://bajazet.fr/shaarli/?nEPV8Q)

TL;DR Un protocole au même niveau que TCP mais permettant une authentification client/serveur, un chiffrement complet (même des entêtes) ne nécessitant pas un handshake compliqué (comme TLS), et fournissant une protection contre le DDOS.
(via https://news.ycombinator.com/item?id=5755539)

EDIT: L'avis de Stéphane Bortzmeyer: http://www.bortzmeyer.org/minimalt.html

L'une des énigmes de BitCoin, c'est qu'on ne sait pas qui l'a inventé. Ou plutôt on ne connaît que son pseudonyme. Quelqu'un prétend avoir démasqué sa véritable identité.
Juste une note: Les BitCoins deviennent avec le temps de plus en plus couteux (longs) à calculer. Les tout premiers BitCoins ont pu être calculés rapidement. La conséquence ? L'auteur de BitCoin est probablement riche à millions. On comprend mieux son désire de rester anonyme.

(Lien direct: https://aresu.dsi.cnrs.fr/IMG/pdf/manuel.pdf)