Quelques RFCs
D'autres RFCs
Publicité
RFC 4270 Traduction en francais. |
 |
 |
 |
 |
 |
 |
Cette traduction a été faite par un système automatique. Elle est donc truffée d'erreurs mais vous permettra de saisir le sens du texte.
Si vous êtes l'auteur d'une meilleure traduction, vous pouvez nous l'envoyer.
Si vous êtes l'auteur d'une meilleure traduction, vous pouvez nous l'envoyer.
Network Working Group P. Hoffman
Request for Comments: 4270 VPN Consortium
Catégorie: informationnel B. Schneier
Counterpane Internet Security
Novembre 2005
Les attaques contre les hashs cryptographiques et protocoles Internet
Statut de ce mémo
Cette note fournit des informations pour la communauté Internet. Il ne
Pas spécifier un standard Internet d'aucune sorte. Répartition de cette
Mémo est illimitée.
Avis de droit d'auteur
Copyright (C) L'Internet Society (2005).
Résumé
Les récentes annonces de mieux que prévu au choc des attaques
Algorithmes de hachage populaires ont amené certains à se demander si les gens
Commune de protocoles Internet doivent être changés, et si oui, comment. Cette
Document résume l'utilisation des hashs dans de nombreux protocoles, discute
Comment la collision attentats affectent et n'affectent pas les protocoles,
Montre comment déjouer les attaques connues sur les certificats numériques, et
Discute des orientations futures pour les concepteurs de protocole.
1. Introduction
À l'été 2004, une équipe de chercheurs a montré que des preuves concrètes
L'algorithme de hachage MD5 était susceptible de subir des attaques de collision
[MD5-attaque]. Au début de 2005, la même équipe a fait preuve d'un semblable
Attaque d'une variante de l'algorithme SHA-1 [RFC3174] algorithme de hachage, avec une
Prévision que l'normalement utilisé SHA-1 serait également vulnérable
Avec une grande quantité de travail (mais à un niveau inférieur à ce qui devrait être
Nécessaire si SHA-1) [fonctionné correctement SHA-1-attaque]. Également au début de l'année
2005, researchers showed a specific construction of PKIX certificates
[RFC3280] qui utilisent MD5 pour signer [PKIX-MD5-construction], et
Un autre chercheur a montré une méthode plus rapide pour trouver des collisions MD5
(Huit heures sur un ordinateur de 1,6 GHz) [MD5-plus rapide].
En raison de ces annonces, il ya eu beaucoup de
Discussion en cryptographie experts, le protocole de concepteurs et autres
Les personnes concernées au sujet de ce que, si quoi que ce soit, devrait être basée sur le fait
Hoffman & Schneier Informational [Page 1]
RFC 4270 Attaques sur Hashes Novembre 2005
News. Malheureusement, certains de ces discussions ont été basées sur
Interprétations erronées à la fois de l'actualité et sur la façon dont les algorithmes de hachage
Sont utilisés en commun les protocoles Internet.
Algorithmes de hachage sont utilisées par les cryptographes dans une variété de sécurité
Protocoles, à des fins diverses, à tous les niveaux de l'Internet
Pile de protocoles. Ils sont utilisés, car ils ont deux sécurité
Propriétés: une manière d'être libre et de collision. (Il est plus sur
Ces propriétés dans la section suivante, ils sont plus faciles à expliquer en
De les enfreindre.) Les attaques récentes ont démontré que
L'une de ces propriétés de sécurité n'est pas vrai. S'il est certainement
Possible, et au premier regard, voire probable, que la rupture
La sécurité des biens n'aura pas d'incidence sur la sécurité globale des nombreux
Certains protocoles Internet, l'approche est conservatrice à la sécurité
Modifier les algorithmes de hachage. Le protocole Internet pour les besoins de la collectivité
Migrent de façon ordonnée loin de SHA-1 et MD5 - en particulier
MD5 - et plus sûr vers les algorithmes de hachage.
Ce document résume les connaissances actuelles concernant hachage
Algorithmes et des protocoles de l'Internet qui les utilisent. Elle donne également
Conseils sur la façon d'éviter les problèmes connus actuellement avec MD5 et
SHA-1, et ce pour examiner si les prévisions deviennent de véritables attentats.
Un haut niveau résumé de la situation actuelle est la suivante:
O Les deux MD5 et SHA-1 ont trouvé récemment des attaques contre eux, les
Attaques contre MD5 étant beaucoup plus grave que les attentats
Contre SHA-1.
O Les attaques contre MD5 sont pratiques sur tout ordinateur moderne.
O Les attaques contre SHA-1 ne sont pas réalisables avec les ordinateurs d'aujourd'hui,
Mais sera si les attaques sont améliorés ou Loi de Moore continue
De rendre la puissance de calcul moins coûteux.
O De nombreux protocoles Internet utilisation commune des hashs de façons qui sont
Pas affecté par ces attaques.
O La plupart des protocoles d'utilisation touchés signatures numériques.
O Amélioration des algorithmes de hachage permettra de réduire la vulnérabilité de ces
Attaques à un niveau acceptable pour tous les utilisateurs.
2. Les algorithmes de hachage et des attentats sur Them
Une «parfaite» algorithme de hachage a quelques propriétés fondamentales. L'algorithme
Convertit un segment de données (normalement, un message) de toute taille dans un
Taille fixe résultat. La longueur du fruit est appelé «hash
Hoffman & Schneier Informational [Page 2]
RFC 4270 Attaques sur Hashes Novembre 2005
Longueur "et est souvent désignée comme" L ", le résultat de l'application du hachage
Algorithme sur un segment de données est appelé "valeur de hachage"
Pour que les données. Tout deux différents messages de toute taille devraient avoir un
Extrêmement faible probabilité d'avoir la même valeur de hachage,
Indépendamment de la façon dont l'similaires ou différents messages.
Cette description conduit à deux résultats mathématiques. Trouver une paire
De messages M1 et M2 qui ont la même valeur de hachage prend 2 ^ (L / 2)
Tentatives. Pour toute la durée raisonnable de hachage, il s'agit d'un impossible
Problème à résoudre (collision gratuit). Aussi, compte tenu d'un message M1, trouver
M2 tout autre message qui a la même valeur de hachage comme M1 prend 2 ^ L
Tentatives. Il s'agit là d'un problème encore plus difficile à résoudre (one way).
Notez que ceci est la description d'un algorithme de hachage parfaite, si le
Algorithme est moins que parfaite, un attaquant peut dépenser moins que la
Totalité de l'effort de trouver deux messages ayant la même valeur de hachage.
Il existe deux catégories d'attaques.
Les attaques contre le «libre-collision" propriété:
O une «collision attaque" permet à un attaquant de trouver deux messages M1
Et M2 qui ont la même valeur de hachage à moins de 2 ^ (L / 2)
Tentatives.
Les attaques contre le "sens unique" propriété:
O Un «premier preimage attaque" permet à un attaquant qui sait désiré
Valeur de hachage de trouver un message qui se traduit par moins de valeur que
Que 2 ^ L tentatives.
O Une «deuxième preimage attaque" permet à un attaquant qui a un souhaitée
Message M1 de trouver un autre message M2 qui a la même valeur de hachage
En moins de 2 ^ L tentatives.
Les deux preimage attaques sont très semblables. Dans un premier preimage
Attaque, vous le savez, une valeur de hachage, mais pas le message qui l'a créée,
Et si vous voulez découvrir tout message avec la valeur de hachage connue, et
Preimage la deuxième attaque, vous avez un message et vous souhaitez trouver une
Deuxième message qui a le même hash. Attaques qui peuvent en trouver un
Type de preimage peuvent souvent trouver l'autre aussi.
Lors de l'analyse de l'utilisation des algorithmes de hachage des protocoles, il est
Important de distinguer qui des deux propriétés sont des hashs
Important, surtout maintenant que la collision est exempt de propriété
De plus en plus faible pour les algorithmes de hachage populaires actuellement. Il est
Certes important de déterminer quelles parties sélectionner le matériel
Être haché. En outre, comme le montrent certains des premiers travaux,
Hoffman & Schneier Informational [Page 3]
RFC 4270 Attaques sur Hashes Novembre 2005
En particulier [PKIX-MD5-construction], il est également important de
Examiner quelle est la partie qui peut prédire le document au début de la
Haché objet.
2,1. Actuellement attaques connues
Tous les pratiques actuellement connues ou presque-pratique attaques sur MD5
Et SHA-1 sont des attaques de collision. Cela est heureux: significatif
Première et de deuxième preimage attaques sur un algorithme de hachage serait beaucoup
Plus dévastatrices dans le monde réel que des attaques de collision, comme
Décrites plus loin dans ce document.
Il est également important de noter que les attaques actuelles collision
Exigent au moins un des deux messages d'avoir une bonne quantité de
Dans la structure de bits du message. Cela signifie que de trouver deux
Messages que les deux ont la même valeur de hachage * et * sont utiles dans un
Monde réel attaque est plus difficile que de simplement trouver deux messages
Avec la même valeur de hachage.
3. Comment utiliser les protocoles Internet algorithmes de hachage
Algorithmes de hachage sont utilisées dans de nombreux égards sur l'Internet. La plupart
Protocoles qui utilisent des algorithmes de hachage le faire d'une manière qui les rend
À l'abri de dommages causés par un abordage attaques. Ce n'est pas par hasard: bon
Protocole concepteurs de développer leurs protocoles pour supporter le plus grand nombre
L'évolution future de la cryptographie sous-jacent que possible, y compris
Attaques sur les algorithmes cryptographiques eux-mêmes.
Utilise des algorithmes de hachage sont:
Sur la non-répudiables signatures numériques sur les messages. La non-répudiation est
Un service de sécurité qui assure une protection contre les fausses déni
D'implication dans une communication. S / MIME et OpenPGP permettre mail
Expéditeurs de signer le contenu d'un message, ils créent et les
Destinataire de ce message peut vérifier si oui ou non la signature
Est en fait associé à ce message. Un message est utilisé pour
La non-répudiation si le message est signé et le destinataire du
Message peut être utilisé ultérieurement à la signature de prouver que le signataire
Effectivement créé le message.
O Les signatures numériques dans les certificats de tiers de confiance.
Bien que ce soit le même que pour "les signatures numériques sur les messages",
Certificats sont utilisés dans de nombreux autres protocoles pour
L'authentification et la gestion des clefs.
Challenge-réponse sur les protocoles. Ces protocoles combiner un public
Grand nombre aléatoire d'une valeur pour aider à cacher la valeur lors de son
Envoyé plus de chaînes en clair.
Hoffman & Schneier Informational [Page 4]
RFC 4270 Attaques sur Hashes Novembre 2005
Relative à l'authentification de messages secrets partagés. Elles sont similaires à
Défi-réponse protocoles, sauf qu'au lieu d'utiliser du public
Valeurs, le message est combiné avec un secret partagé avant
Hashing.
Sur la dérivation des fonctions clés. Ces fonctions font un usage répété de
Algorithmes de hachage à mélanger aléatoire des données dans une chaîne pour l'utiliser dans un ou
Plus de clés pour un protocole de chiffrement.
O Mélange fonctions. Ces fonctions font également un usage répété de hachage
Algorithmes de mélanger des données dans des chaînes de caractères aléatoires, pour des usages autres que
Clés cryptographiques.
O Protection de l'intégrité. Il est fréquent de comparer une valeur de hachage qui
Est reçue hors bande pour un fichier avec le résultat du hachage du fichier
Après la réception sur un protocole non sécurisé, tels que FTP.
Des méthodes ci-dessus, seules les deux premières sont affectés par une collision
Attaques, et même alors, seulement dans des circonstances limitées. Jusqu'à présent, il est
Estime que, de manière générale, challenge-response protocoles ne sont pas
Sensible, parce que l'authentification de l'expéditeur est déjà un secret
Stocké par le destinataire. Dans le message d'authentification partagée avec
Secrets, le fait que le secret est connue pour les deux parties est également
Estime raisonnable pour prévenir toute attaque. Toutes les clés de dérivation
Fonctions dans les protocoles IETF prendre aléatoire renseignements fournis par les deux parties, de manière
L'attaquant n'a aucun moyen de structurer le haché message.
4. Hash collision attaques et de la non-répudiation des signatures numériques
L'idée de base de la collision attaque d'un algorithme de hachage utilisée
Dans un protocole de signature numérique n'est que l'attaquant crée deux
Les messages qui ont la même valeur de hachage, les causes l'un d'eux d'être
Signé, et utilise ensuite cette signature sur l'autre message pour certains
Abject fin. Les détails de l'attaque dépendra de la
Protocole utilisé et ce que la victime ne lorsqu'il est présenté avec la
Message signé.
L'exemple canonique est l'endroit où vous créez deux messages, dont l'un
A dit "je vais payer 10 $ pour faire ce travail» et l'autre qui dit
"Je verse 10.000 dollars pour faire ce travail". Vous présenter le premier
Message à la victime, de les amener à signer, faire le travail, substitut
Le deuxième message de l'autorisation signée, la présente modifié
Message signé (dont la signature vérifie toujours), et la demande
Montant plus élevé de l'argent. Si la victime refuse, vous emmener à
Afficher tribunal et le deuxième message signé.
Hoffman & Schneier Informational [Page 5]
RFC 4270 Attaques sur Hashes Novembre 2005
La plupart des attaques non-répudiation de l'homme reposent sur une appréciation de la validité
Présumément du message signé. Dans le cas de la collision de hachage -
Attaque, le message prétendument signé la signature est valable, mais si
Est la signature figurant sur le message original. La victime peut produire la
Message original, montrer qu'il / elle l'a signée, et montrent que les deux
Valeurs de hachage sont identiques. La chance de ce passe-t-il par hasard
Est un en 2 ^ L, ce qui est infiniment petit soit pour ou MD5
SHA-1.
En d'autres termes, de faire échec à une table de hachage de collision dans une attaque non -
Répudiation de l'homme où un protocole est signé au moyen d'un message comme
Autorisation, le signataire doit conserver une copie de l'original
Message qu'il a signé. Les messages qui ont des messages avec les autres
Même hachage doivent être créés par la même personne, et ne se produisent pas par
Accident en aucun cas probable connu. Le fait que le
Deux messages ont la même valeur de hachage devrait provoquer suffisamment de doute dans
L'esprit de la personne juger de la validité de la signature de provoquer
Juridiques attaque à l'échec (et peut-être porter la fraude intentionnelle
Accusations contre l'attaquant).
Hash collision contrecarrer les attaques automatisées dans la non-répudiation
Protocoles est potentiellement plus difficile, car il peut n'y avoir aucune
Homme paie suffisamment d'attention pour être en mesure d'argumenter sur ce qui devrait
Ont eu lieu. Par exemple, dans l'échange de données informatisées (EDI)
Applications, les actions sont généralement prises automatiquement après
L'authentification d'un message signé. Détermination de la pratique
Effets des collisions hash nécessiterait une évaluation détaillée de la
Protocole.
5. Hash collision attaques et des certificats numériques tiers de confiance
Parties
Les certificats numériques sont un cas particulier de la signature numérique. Dans
Général, il n'ya pas de non-répudiation attaque de tiers de confiance
Dû au fait que les certificats ont formatage spécifique. Digital
Certificats sont souvent utilisés dans les protocoles Internet pour la gestion des clés
Et pour authentifier un parti avec lequel vous communiquez,
Éventuellement, avant d'accorder l'accès à des services de réseaux ou de la confiance
Partie privée avec des données telles que les informations de carte de crédit.
Il est donc important que l'octroi des parties peuvent avoir confiance que le
Certificat identifie correctement la personne ou du système identifié par
Le certificat. Si l'attaquant peut obtenir un certificat pour deux
Identités différentes avec une seule clé publique, la victime peut être
Dupe de croire à une seule personne, c'est quelqu'un d'autre.
Hoffman & Schneier Informational [Page 6]
RFC 4270 Attaques sur Hashes Novembre 2005
La collision attaque de certificats PKIX décrites au début de 2005
Reposait sur la capacité de l'attaquant de créer deux publics différents
Touches qui causerait le corps du certificat d'avoir le même
Valeur de hachage. Pour cette attaque fonctionne, l'attaquant doit pouvoir
Pour prédire le contenu et la structure de l'attestation est saisi
Émises, y compris l'identité qui sera utilisé, le numéro de série
Qui seront inclus dans le certificat, et le démarrage et arrêt
Dates de la période de validité du certificat.
Le bon résultat de cette attaque est qu'une personne utilisant un seul
Identité peut obtenir un certificat numérique sur une clé publique, mais être
En mesure de prétendre qu'il est sur une autre clé publique (mais avec la
Même identité, la validité des dates, etc.) Parce que l'identité dans la
Deux certificats est le même, il n'ya probablement pas un monde réel
Exemples où une telle attaque serait tout avantage à l'attaquant.
Au mieux, quelqu'un pourrait prétendre que le tiers de confiance fait une
Erreur par l'émission d'un certificat d'identité et de la même série
Nombre repose sur deux types de clés publiques. Il s'agit en effet
Exagéré.
Il est très important de noter que les attaques de collision seulement une incidence sur le
Parties de certificats qui ne sont pas lisibles par l'homme dans l'information
Entre eux, comme les clés publiques. Une attaque qui implique avoir une
Avec un certificat lisible pour l'homme et l'identité de cette
Certificat utile pour une deuxième identité lisible pour l'homme exigerait
Plus d'effort que d'une simple attaque de collision.
5,1. Réduire le risque de brouillage Basé Attaques sur PKIX Certificats
Si un tiers de confiance qui délivre des certificats PKIX veut éviter
L'attaque décrite ci-dessus, elles peuvent empêcher l'attaque en faisant
Signé d'autres parties du certificat hasard suffit à éliminer tout
Avantage acquis par l'attaque. Idées qui ont été suggérées
Comprennent:
O faisant partie du numéro de série du certificat à l'imprévisible
Attaquant
Concernant l'ajout d'un élément choisi au hasard à l'identité
Sur les dates de validité de l'imprévisible à l'attaquant de fausser
Chacun en avant ou en arrière
N'importe lequel de ces mécanismes devrait accroître la quantité de travail que le
Attaquant doit faire pour tromper l'émetteur du certificat en
Générer un certificat qui est susceptible à l'attaque.
Hoffman & Schneier Informational [Page 7]
RFC 4270 Attaques sur Hashes Novembre 2005
6. De futures attaques et leurs effets
Il ya un désaccord au sein de la communauté de sécurité sur ce qu'il faut faire
Maintenant. Même les deux auteurs de ce document en désaccord sur ce qu'il faut faire
Maintenant.
L'un de nous (Bruce) estime que tout le monde devrait commencer la migration vers
SHA-256 [SHA-256] aujourd'hui, en raison des faiblesses qui ont déjà été
Démontrée à la fois dans MD5 et SHA-1. Il ya un vieux dicton intérieur
La US National Security Agency (NSA): "Les attaques toujours mieux;
Ils n'ont jamais empirer. "Actuellement, les attaques contre les collisions MD5 sont
Fait facilement sur un seul ordinateur; l'abordage des attaques contre SHA-1
Sont à l'extrême pointe de la faisabilité d'aujourd'hui, mais ne fera que s'améliorer avec
Temps. Il est préférable de migrer vers la nouvelle norme avant de hachage
Il ya un mouvement de panique, au lieu d'après. Tout comme nous avons tous émigré de
SHA-0 à SHA-1 basé sur certaines inconnues vulnérabilité découverte à l'intérieur
La NSA, il faut migrer de SHA-1 à SHA-256 sur la base de ces plus
Récentes attaques. SHA-256 a 256-bit hash long. Cette longueur
Nous donnent une bien plus grande marge de sécurité en cas de nouveau
Découvert attaques. Pendant ce temps, d'autres recherches dans le
Cryptographiques de la communauté au cours des prochaines années devrait pointer vers
D'autres améliorations dans la conception algorithme de hachage, et potentiellement un
Encore plus algorithme de hachage sûr.
L'autre d'entre nous (Paul) estime que ce n'est peut-être pas sage pour deux
Raisons. Tout d'abord, le choc des attaques sur les protocoles actuels ne l'ont pas
Été démontré avoir d'effets du monde réel. En outre, il
N'est pas encore clair algorithme de hachage plus forts, qui sera un bon choix
Pour le long terme. Se déplacent d'un algorithme à l'autre conduit à
Inévitable manque d'interopérabilité et de la confusion pour les crypto typique
Utilisateurs. (Bien entendu, si toute pratique attaques sont formulées avant
Il ya un consensus de la communauté des propriétés de l'algorithme de chiffrement à base de
Algorithmes de hachage, Paul allait changer son opinion à «passer à SHA-256
Maintenant ".)
Les deux auteurs conviennent que le travail devrait être fait pour que tous les internautes
Capable d'utiliser des protocoles différents algorithmes de hachage avec plus de hachage
Valeurs. Heureusement, la plupart des protocoles déjà aujourd'hui sont capables de
Ce, ceux qui ne sont pas devrait être fixé prochainement.
Les auteurs de ce document estiment de même pour les nouveaux protocoles en cours
Développé: Bruce croit qu'ils devraient commencer à utiliser SHA-256 de la
Démarrer, et Paul pense qu'ils devraient utiliser SHA-1 tant que le nouveau
Protocoles ne sont pas sensibles à des attaques de collision. Tout nouveau protocole
Doivent avoir la possibilité de changer l'ensemble de ses algorithmes cryptographiques,
Pas seulement de son algorithme de hachage.
Hoffman & Schneier Informational [Page 8]
RFC 4270 Attaques sur Hashes Novembre 2005
7. Security Considerations
Le document traite de la sécurité sur Internet.
La discussion de ce document suppose que les seules attaques de hachage
Algorithmes utilisés dans les protocoles Internet sont des attaques de collision. Certains
Preimaging attaques importantes ont déjà été découverts
[Preimaging-attaque], mais ils ne sont pas toujours pratiques. Si une pratique
Preimaging attaque est décelée, elle avoir une incidence considérable sur de nombreux
Protocoles Internet. Dans ce cas, les «pratiques» signifie qu'il pourrait être
Exécutée par un attaquant dans un laps de temps pour un
Montant significatif d'argent. Preimaging Une attaque qui coûte des milliards
De dollars et prend les décennies à preimage une valeur de hachage ou souhaitée
Un message n'est pas pratique, l'un qui coûte quelques milliers de dollars
Et prend quelques semaines, peut-être très pratique.
8. Renvois
[MD5-attaque] X. Wang, D. Feng, X. Lai, et H. Yu,
"Collisions Fonctions de hachage MD4, MD5,
HAVAL-128 et RIPEMD ", août 2004,
<http://eprint.iacr.org/2004/199>.
[MD5-vite] Vlastimil Klima, "Trouver MD5 Collisions --
Pour un jouet Notebook ", mars 2005,
<Http://cryptography.hyperlink.cz/
Md5/MD5_collisions.pdf>.
[PKIX-MD5-construction] Arjen Lenstra et Benne de Weger, "Sur la
Possibilité de construire significative de hachage
Collisions de clés publiques ", février 2005,
<Bdeweger http://www.win.tue.nl/ ~ /
CollidingCertificates / ddl-final.pdf>.
[Preimaging-attaque] John Kelsey et Bruce Schneier, "Deuxième
Preimages sur n bits Hash Functions pour Much
Moins de 2 ^ n Travaux ", novembre 2004,
<http://eprint.iacr.org/2004/304>.
[RFC3174] Eastlake, D. et P. Jones, «US Secure Hash
Algorithm 1 () 3174,
Septembre 2001.
[RFC3280] Housley, R., Polk, W., Ford, W., et D. Solo,
«Internet X.509 infrastructure à clé publique
Certificat et liste de révocation de certificats
(CRL) Profile ", RFC 3280, avril 2002.
Hoffman & Schneier Informational [Page 9]
RFC 4270 Attaques sur Hashes Novembre 2005
[SHA-1-attaque] Xiaoyun Wang, Yiqun Lisa Yin et Hongbo Yu,
"Collision Recherche Attaques sur SHA1",
Février 2005,
<http://theory.csail.mit.edu/~yiqun/shanote.pdf>.
[SHA-256] NIST, «Federal Information Processing
Standards Publication (FIPS PUB) 180-2,
Secure Hash Standard ", août 2002.
Hoffman & Schneier Informational [page 10]
RFC 4270 Attaques sur Hashes Novembre 2005
Annexe A. Remerciements
Les auteurs tiennent à remercier la communauté IETF, et en particulier
Ceux qui sont actifs sur le SAAG liste de diffusion, pour leur contribution. Nous serions
Aussi remercier Eric Rescorla pour le début de la matière qui est entré dans
La première version, et Arjen Lenstra et Benne de Weger pour
Significative des commentaires sur la première version de ce document.
Authors' Addresses
Paul Hoffman
VPN Consortium
EMail: paul.hoffman @ vpnc.org
Bruce Schneier
Counterpane Internet Security
EMail: schneier@counterpane.com
Hoffman & Schneier Informational [page 11]
RFC 4270 Attaques sur Hashes Novembre 2005
Full Copyright Statement
Copyright (C) L'Internet Society (2005).
Ce document est soumis aux droits, licences et restrictions
Figurant dans le BCP 78, et sauf dans la mesure qui y sont énoncés, les auteurs
Conservent tous leurs droits.
Ce document et les renseignements qu'il contient sont fournis sur une
«En l'état» et LA CONTRIBUTOR, L'ORGANISATION QU'IL / ELLE REPRESENTE
Ou est parrainé par (le cas échéant), la société Internet et de l'internet
Engineering task force déclinons toute garantie, expresse ou implicite,
Y compris, mais non limité à toute garantie que l'utilisation du
Les renseignements présentés ici ne sera pas porté atteinte à aucun des droits ou de toute implicite
Les garanties de qualité marchande ou d'adéquation à un usage particulier.
Propriété intellectuelle
L'IETF ne prend pas position quant à la validité ou la portée de tous
Droits de propriété intellectuelle ou d'autres droits qui peuvent être réclamés à
Ont trait à la mise en œuvre ou l'utilisation de la technologie décrite dans
Ce document ou de la mesure dans laquelle une licence sur ces droits
Peut être ou ne pas être disponibles, ne constitue pas non plus qu'il a
Fait aucun effort indépendant d'identifier d'éventuels droits. Information
Sur les procédures en matière de droits dans les documents RFC peut être
Trouvée dans les BCP 78 et BCP 79.
Des exemplaires de DPI révélations faites à l'IETF Secrétariat et toute
Assurances de licences à être mis à disposition, ou le résultat d'une
Tentative d'obtenir une licence ou une autorisation générale pour l'utilisation de
Tels droits de propriété par les opérateurs ou les utilisateurs de cette
Spécifications peuvent être obtenues auprès de l'IETF en ligne référentiel au DPI
Http://www.ietf.org/ipr.
L'IETF invite toute partie intéressée à porter à son attention toute
Les droits d'auteur, des brevets ou demandes de brevet, ou autres propriétés
Droits qui peuvent s'appliquer à une technologie qui peut être nécessaire pour mettre en œuvre
Cette norme. S’il vous plaît adresse les informations à l'IETF à ietf -
Ipr@ietf.org.
Remerciements
Le financement de la RFC Editor fonction est actuellement assurée par la
Internet Society.
Hoffman & Schneier Informational [page 12]