Et surtout, on ne sait pas quel microcode la NSA à intégré au puces CISC, ou quel cablage au RISC. Qui va vérifier ce que fait l'unité de chiffrement et ce que fait la carte réseau Intel, avant de le passer au switch linksys au routeur CISCO (tous backdoorés par la NSA ? Quand certains leurs montrent les backdoor, plutôt que de les corriger, ils ont tendance à mettre un masque devant, laissant penser, qu'on va pas s'en sortir avec eux. Sans parler des scanneurs d'écran (à distance) et clavier qui sont répandus depuis au moins 20 ans.
Ils parlent de El Gamal, mais d'après wikipedia : son algo (qui est peut-être bien indépendamment de ses implémentations) « est la base du système DSA standardisé par le NIST ». donc même problème qu'avec RSA, c'est bien de faire des algos efficaces, mais quand on a des services secret qui implémente des versions avec porte dérobée pour les standards, ça sert plus à rien.
Donc, de toute façon, c'est un système avec backdoor pas la peine de décodeurs matériels, il suffit de connaître la backdoor (aller la chopper à la NSA ?). NIST & RSA (la société, pas le trio de l'algo et l'algo) sont obligés de demander gentiment à la NSA avant de normaliser l'implémentation d'un algo de crypto. Et comme le rappelle DJ. Bernstein (l'auteur de qmail & co), ils nous filent même pas certains infos à propos de la création de leurs courbes elliptiques (laissant supposé qu'elles sont toutes trouées, pas uniquement celles ou c'est déjà démontrées). Du coup, il a fait crée un nouvel algo ed25519, qui a en plus l'avantage d'être plus efficace (donc de consommer moins de ressources).
Sous OpenSSH, Utiliser ed25519 plutôt que RSA/DSA/ECDSA (pas confondre avec edDSA), il est déjà implémenté, une inclusion dans un RFC est en cours dans deux brouillons de l'IETF (réellement international et indépendant) pour pouvoir enregistré des empreintes de la clé publique du serveur SSH dans les DNS (via une extension de SSHFP), et ainsi de vérifier l'authenticité de la clé avant de l'accepté lors du premier accès (nécessite l'utilisation de DNSSEC pour être efficace).
Et il y a déjà un autre brouillon de RFC est en cours pour l'accepter dans TLS (utilisé par HTTPS par exemple), en attendant il faut faire avec les passoires...
Pour rappel, DJ. Bernstein à passé 2 concours pour voir ses algos retenus aux niveaux nationaux. Un refusé aux US, un accepté en Europe (ecrypt.eu.org). Bon, il semble un peu remonté contre son gouvernement, notamment sur le fait d'avoir le droit à un peu de vie privée, ce qui doit les fâcher.
[^] # Re: Suggestion de correction
Posté par tao popus . En réponse au journal La crypto ça sert plus à rien de toute façon. Évalué à 10.
Et surtout, on ne sait pas quel microcode la NSA à intégré au puces CISC, ou quel cablage au RISC. Qui va vérifier ce que fait l'unité de chiffrement et ce que fait la carte réseau Intel, avant de le passer au switch linksys au routeur CISCO (tous backdoorés par la NSA ? Quand certains leurs montrent les backdoor, plutôt que de les corriger, ils ont tendance à mettre un masque devant, laissant penser, qu'on va pas s'en sortir avec eux. Sans parler des scanneurs d'écran (à distance) et clavier qui sont répandus depuis au moins 20 ans.
Ils parlent de El Gamal, mais d'après wikipedia : son algo (qui est peut-être bien indépendamment de ses implémentations) « est la base du système DSA standardisé par le NIST ». donc même problème qu'avec RSA, c'est bien de faire des algos efficaces, mais quand on a des services secret qui implémente des versions avec porte dérobée pour les standards, ça sert plus à rien.
Donc, de toute façon, c'est un système avec backdoor pas la peine de décodeurs matériels, il suffit de connaître la backdoor (aller la chopper à la NSA ?). NIST & RSA (la société, pas le trio de l'algo et l'algo) sont obligés de demander gentiment à la NSA avant de normaliser l'implémentation d'un algo de crypto. Et comme le rappelle DJ. Bernstein (l'auteur de qmail & co), ils nous filent même pas certains infos à propos de la création de leurs courbes elliptiques (laissant supposé qu'elles sont toutes trouées, pas uniquement celles ou c'est déjà démontrées). Du coup, il a fait crée un nouvel algo ed25519, qui a en plus l'avantage d'être plus efficace (donc de consommer moins de ressources).
Sous OpenSSH, Utiliser ed25519 plutôt que RSA/DSA/ECDSA (pas confondre avec edDSA), il est déjà implémenté, une inclusion dans un RFC est en cours dans deux brouillons de l'IETF (réellement international et indépendant) pour pouvoir enregistré des empreintes de la clé publique du serveur SSH dans les DNS (via une extension de SSHFP), et ainsi de vérifier l'authenticité de la clé avant de l'accepté lors du premier accès (nécessite l'utilisation de DNSSEC pour être efficace).
Using ED25519 in SSHFP Resource Records
http://tools.ietf.org/html/draft-moonesamy-sshfp-ed25519
Et il y a déjà un autre brouillon de RFC est en cours pour l'accepter dans TLS (utilisé par HTTPS par exemple), en attendant il faut faire avec les passoires...
Curve25519 for ephemeral key exchange in Transport Layer Security (TLS)
http://tools.ietf.org/html/draft-josefsson-tls-curve25519
Pour rappel, DJ. Bernstein à passé 2 concours pour voir ses algos retenus aux niveaux nationaux. Un refusé aux US, un accepté en Europe (ecrypt.eu.org). Bon, il semble un peu remonté contre son gouvernement, notamment sur le fait d'avoir le droit à un peu de vie privée, ce qui doit les fâcher.