Calcul de hash sha 256

Soyez le premier à donner votre avis sur cette source.

Vue 13 385 fois - Téléchargée 1 045 fois

Description

Ce code permet de calculer le hash sha 256 d'un tableau de byte. L'exemple donné calcul le hash d'une chaine de caractere.

Source / Exemple :


zip

Conclusion :


Si vous voyez des bugs n'esitez pas à me le dire.

Code compilé sous Eclispe 3.4.1 avec Java 1.5

Codes Sources

A voir également

Ajouter un commentaire

Commentaires

Messages postés
1
Date d'inscription
lundi 22 octobre 2012
Statut
Membre
Dernière intervention
22 octobre 2012

comment appliquer ce code pour hacher une photo???
Messages postés
203
Date d'inscription
vendredi 27 janvier 2006
Statut
Membre
Dernière intervention
29 janvier 2019

A titre de comparaison, voici le code libre que j'avais posté il y a quelques temps ici (je ne vois pas ce qui a pu pousser lkes administrateurs du site ici à le supprimer !), et depuis plus de 8 ans ailleurs sur le Net (ce code est aussi utilisé en production depuis pas loin de 10 ans, et reste plus rapide que toutes les implémentations 100% java actulles sur le marché, et arrive même à battre les autres implémenttions en .Net et en C, il peut seulement être battu avec des optimisations parallèles SSE2 ou en assembleur pur uniquement sur les vieux processseurs Pentium sans SSE/MMX ou 486 et précédents; Java fait nettement mieux en restant avec le même code quasi optimum sur toutes les plateformes, grace à la compilation dynamique au runtime du Bytecode déjà optimisé dans le code ci-dessous sur la plateforme elle-même).

Voir la liste des fichiers sur (aucune pub, juste les fichiers):

http://org.rodage.com/pub/java/security/

(il y a d'autres algos que SHA256, il y a eu de très lègères modifications de performance depuis leur création, mais plus aucun changement depuis 2005). Ce sont toutes des implémentations en 100% pur Java (pas d'utilisation de DLLs natives via JNI), et donc totalement portable sur toutes plateforme compatible Java (des serveurs d'applications aux PCs ou Macs, aux plus simples téléphones mobiles, set-top boxes, consoles de jeux, ou appareils hifi intégrés comme des lecteurs DVD, webradios, lecteurs MP3 mobiles, etc, qui ont un firmware intégrant une VM Java).

Tout est disponible sous licence LGPL (dont une traduction française est disponible dans le même dossier).

Chaque algorithme est implémenté dans une classe implémentant l'interface standard MessageDigestSPI (donc compatible avec toute implémentation d'un JCE et pouvant remplacer les algos fournis par Sun). Le code est compatible avec toutes les versions de Java (il n'y a pas de spécificité demandant Java 5 ou 6).

Chaque algo est fourni avec sa classe de test, contenant les valeurs attendues de la quasi totalité des vecteurs standardisés de test dans les normes américaines FIPS ou européennes. Le code effectue enfin un test de performance et fait la comparaison de performances avec l'algo du JCE de Sun, quand il est présent: cette comparaison n'est pas toujours possible si votre JCE par défaut n'a pas l'algorithme correspondant: la classe de Test est à adapter aux versions de JCE avec lesquelles vous voulez comparer les performances et en vérifier les résultats.

Tous les algos de hachage sécurisés standards des normes FIPS sont présents (MD5, SHA1, SHA224, SHA256, SHA384, SHA512), ainsi que quelques autres (Tiger et Whirlpool).

Il n'y a pas MD2 ni MD4 car ils ne sont pas sécurisés du tout (ils n'ont été recommandés dans aucune norme) et pourtant plus lents que MD5. Mais j'en a des versions de même qualité si vous les voulez.

(Note: les commentaires sont en anglais, mais ils sont mis en forme pour JavaDoc.)
Messages postés
203
Date d'inscription
vendredi 27 janvier 2006
Statut
Membre
Dernière intervention
29 janvier 2019

Concernant la sécurité, la réduction de longueur d'une clé de hachage sécurisée doit se faire par une méthode préservant la distribution des bits. Si on suppose que SHA256 a une distribution plate (ce qui devrait être le cas pour tout algorithme éprouvé) et en reconnaissant que SHA256 est reconnu comme bien plus résistant que MD5 ou SHA1 par le fait qu'il utilise un nombre d'états internes (ou degréds de libertés) bien plus élevé, indépendamment de la longueur de clé finale), il suffit simplement de tronquer la clé à la longueur voulue: c'est ce qui est fait par exemple dans SHA384 qui consiste simpelment à tronquer la clé de hachage en prenant les 384 premiers bits de la clé de hachage SHA512 (cela n'augmente ni ne diminue pas le nombre d'états internes dans le calcul).

Il n'y a aucune préférence de choix dans les bits de la clé obtenue à préserver: si une telle préférence existait et avait été démontrée, les algorithmes n'auraient pas été aprouvés avec la longueur de clé indiquée.

En terme de résistance aux collisions, évidemment, si on tronque trop, on augmente statistiquement le risque de collision (le passage de 256 bits à 64 bits mulitpliera ce risque par 2^(256-64) ce qui est évidemment énorme, et permet d'envisager à un coût faible la recherche de collision (qui surviendra sur ces 64 seuls bits, même si la clé originale sur 256 bits ne provoquait pas de collision).

Peut importe la méthode de réduction des clés utilisée, il n'y a aucun moyen de préserver la sécurité contre les collisions si on réduit le nombre de bits. Donc il est parfaitement inutile de chercher des méthodes compliquées (comme prendre un bit sur 4, ou compresser les 256 bits en les coupant en 4 paquaets combinés ensemble par un XOR): la sécurité obtenue sera la même.

Le seule problème avec une méthode avec troncature de clé plus longue, c'est que le calcul intermédiaire de clés plus longues nécessite plus de calcul, alors que cet excès n'apporte aucune sécurité supplémentaire significative par rapport à un autre algorithme "sécurisé" calculant directement une clé plus courte. Donc c'est vrai qu'on peut finalement se contenter d'utiliser SHA1 et non SHA256 comme algorithme de base.

D'une açon générale, pour une longueur de clé voulue donnée, on doit prendre un algorithme sécurisé ne calculant pas plus du double de cette longueur. Au delà c'est du travail inutile pour rien puisque le supplément d'effort est perdu.

Si le but n'est pas la sécurité mais simpement avoir des clés courtes suffisantes pour faire une table d'index par hachage résident en mémoire, SHA256 est certainement peu adapté et réduira les performances de votre application. Autant se contenter dans ce genre d'application de clé de hachage non sécurisées mais donnant une distribution suffisamment "plate" des bits afin que les "slots" dans la table de hachage soient équitablement utilisés. En général les tables de hachage en mémoire ont un nombre de slots relativement faible (guère plus de 65000) car on y stocke en fait un nombre limité d'objets (aussi car si on ugmente trop la tailel de la table de hachage, on va se retruver avec plein de slots vides qui occupent inutilement de la mémoire).

Pour cette raison, les table de hachage se contentent d'algorithmes plus simples basés sur une réduction par multiplication et addition dans un espace de Galois de longueur égale à la taille de la table de hachage. On choisit normalement une tailel qui sit un nombre premier pour les tailles faibles inférieures à 12 bits, et au delà on utilise une taille qui est une puissance de 2 dans le corps de Galois binaire, et cela suffit: le multiplicateur utilisé est en général dans ce cas un nombre proche du tiers de la taille totale N et qui soit premier avec cette taille, en fait le nombre premier le plus proche de N/e.

Par exemple pour une taille de table de hachage voisine de 1024, on choisit la taille première proche 1031, et le multiplicateur est alors le nombre premier le plus proche de 1031/e=379,28... qui est donc ici 379; la constante additive devrait être proche de la moitié de cette valeur, et également première, ici 379/2=189,5, on peut choisir 187; le calcul de hachage pour chaque octet à hacher est alors: nouvelleclé=(ancienneclé*379+187+octet) modulo 1031.

Pour indexer en revanche un nombre très élevé de fichiers par la valeur exacte de leur contenu (avec une clé si possible distincte pour la moindre modification de ce contenu) c'est là qu'on a besoin d'un algo sécurisé. Mais il ne faut pas se leurrer: il n'y a pratiquement aucun moyen d'assurer l'unicité et le risque de collision avec une clé de 64 bits seulement (quel que soit l'algo employé!). En revacnhe on peut estimer le nombre total de fichiers existants à tout instant ou le temps qui serait nécessaire pour atteindre un nombre donné, puis ensuite le nombre de fichiers auxquels il est possible d'accéder en un temps donné: s'il faut plus d'une vie à attendre même en employant tous les ordinateurs du monde pour en générer assez, il est pratiquement impossible d'obtenir une collision. On estimait il y a encore 5 ans qu'une longueur raisonnable actuelle est celle de la clé SHA1 (et pas moins), mais aujourd'hui la longueur minimale suggérée est de 128 bits (et par sécurité on choisit plutôt 192 bits).

En revanche contre le risque de production de collisions volontaires (dans le but de modifier des fichiers existants sans que cette modification soit détectable par la clé de hachage, il est hautement recommandé de ne plus descendre sous les 256 bits: c'est pour ça qu'on a l'algo SHA256, et déjà l'algo SHA512 pour le futur ou les plus paranoïaques (ainsi que SHA384 qui en est une version mineure obtenue par simple troncature de SHA512).

L'ennui des clés obtenues avec 256 bits ou moins est que le calcul se fait avec des entiers 32 bits: en augmentant le nombre de bits dans la clé, on a augmenté énormément le nombre d'opérations pour l'utilisation normale (ce qui pourrait rendre l'utilisation de ces algorithmes prohibitive pour la sécurisation tout en conservant les performances). De plus, en accroissant le nombre de variables internes, cela fait déborder les tailles de cache des processeurs, et les performances s'effondrent.

C'est pour ça que SHA512 (ou SHA384, mais aussi l'algo Tiger qui calcule des clé sur 192 bits d'une façon complètement différente des algos linéaires utilisés dans les algos MD ou SHA) utilise pour son calcul interne des entiers sur 64 bits et non 32 bits, des tailles maintenant supportées nativement par les processeurs, et qui diminuent le nombre d'opérations nécessaires sans réduire le nombre d'états internes et de degrés de libertés "cachés" dans la clé obtenue: cela a permi de continuer à augmenter la sécurité sans réduire significativement les performances (c'est vrai que le calcul sera plus long, mais ce n'est rien en fonction de la "loi de Moore" concernant l'évolution des performances des processeurs, ordinateurs, et systèmes en réseau, c'est à dire la capacité totale de calcul disponible en moyenne par poste utilisateur).

Bref, pour conclure: pas besoin de se compliquer avec les algos sécurisés connus si vos voulez des clés plus courtes: il suffit de les tronquer.

En revanche l'utilisation de deux clés obtenus par des algos distincts ne donne pour obtenir une clé composite ne donne PAS une sécurité équivalente à l'utilisation d'un algo sécurisé unique de longueur supérieure (la sécurité sera bien moindre).

Par exemple: SHA512 tronqué à 256 bits a une sécurité très légèrement supérieure à SHA256 (mais ce supplément est négligeable). Mais si on combine la clé SHA512 tronquée à 256 bits, avec la clé SHA256, on obtient une clé composite de 512 bits, mais qui sera de sécurité TRES NETTEMENT INFERIEURE à l'utilisation d'une clé unique SHA512 non tronquée !!!)

Ceci est une règle générale: les clés ne se combinent pas de façon additive mais sont seulement légèrement supérieures à la sécurité de la plus forte d'entre elles. La combinaison de deux clés d'algorithmes distincts ne peut servir qu'au cas où un algorithme réputé sécurisé voit sa sécurité brutalement diminuée: la seconde clé permet de conserver une sécurité minimale quand la securité de l'autre est compromise.

C'est pour ça que les certificats de sécurité des PKI comportent généralement une double signature (avec des clés de longueurs similaires, mais avec deux algorithmes), car il faudrait alors réussir simultanément à casser les deux algorithmes pour casser les deux certificats (le reste de l'effort de calcul pour réussir à produire une collision simultanée dans les deux algorithmes est alors négligeable par rapport à l'effort qui était initialement nécessaire pour casser chaque algorithme): la sécurité du certificat est alors effectivement celle de celui des deux algorithmes qui est le plus sécurisé.

En revanche une double clé ne sert à rien s'il s'agit de vérifier l'intégrité d'un fichier unique. La bonne méthode est plutôt d'utiliser un découpage du fichier en morceaux de taille inférieur à une limite maximale et de hacher chaque fragment: la sécurité de l'algorithme augmente mathématiquement quand la taille des fichiers est bornée (par exemple des fragments de 4Ko comportent 32768 bits, et il suffit d'avoir pour chacun d'eux une clé sur 128 bits, ce qui apporte une compression limitée à 1 bit sur 256 entre la oangueur de clé et celle du fichier:

ce taux de compression est correct et pas excessif par rapport à la longueur de clé (car on estime que que sur une clé sécurisée de taille N, au moins N/2 bits sont significatifs, mais souvent beaucoup plus et pratiquement jusqu'à N-k avec k très petit: ici une clé 128 bits d'un algo sécurisé approuvé donne au minimum 64 bits significatifs et peut-être jusqu'à 120 avec les méthodes connues de cryptanalyse actuelle.

Le risque de collision ne peut commencer à devenir un peu signiticatif sur 1 seul bit qu'à partir de longueur de fichiers dépassant le carré de cette longueur de résistance (120²=14400 bits, soit 1,8 Kio). Avec des fragments de 4Ko, on n'aura une résistance jusqu'à 2,2 bits, mais c'est insuffisant par rapport à la longueur significative de clé pour obtenir une collision véritable (ici 120 pour l'algo de clé sur 128 bits).

En fait on peut aller à des tailles de fragments en bits allant jusqu'au cube du nombre strictement minimum de bits significatifs dans la clé sécurisée: avec une clé de 128 bits, on a au strict minimum 64 bits significatifs et les fragments peuvent aller jusqu'à un strict maximum de 64^3=262144 bits (soit 32 Kio) (la clé 128 bits elle-même apportant une compression d'un tel bloc de 32 Kio d'un ratio de 1:256, ce qui est insigifiant par rapport à la taille de bloc à sécuriser ou authentifier)

Mais en revanche, pour des tailles de fichiers supérieures, il faut davantage de clés, une par bloc, et/ou des clés plus longues (mais c'est au prix des performances car des clés longues sur des fichiers longs représentent une masse de calcul non négligeable).

A vous de voir selon vos besoins s'il vous faut (et quand?) utiliser SHA256 (ou passer directement à SHA512 sur une plateforme 64-bits comme Intel IA64 ou AMD64/x64, puisque SHA512 est en fait maintenant légèrement plus rapide que SHA256 sur les plateformes 64-bits actuelles, avec du code spécialement optimisé pour chaque plateforme en prenant en compte les tailles de caches, et surtout les états d'attente ou de parallélisme possible des pipelines, le nombre de registres rapides et d'ALU indépendantes). Tout dépend largement de la taille des fichiers à hacher, de leur fréquence et de l'estimation de leur nombre total rencontré dans vos applications (ou parmi tous les utilisateurs de votre application si celle-ci est en réseau et notamment sur Internet), et du compromis fait entre performance et dégré (ou durée) de résistance aux attaques (éventuellement massives et coordonnées).

Et n'oubliez pas non plus de définir la valeur des données à protéger (et la durée de validité de cette valeur, puisqu'en général la valeur de toute information diminue avec le temps au contraire du coût nécessaire pour une tentative de violation de l'intégrité de cette information sur cette même période): il peut être plus rentable de ne pas utiliser inutilement les algos les plus sécurisés si au bout du temps nécessaire pour les casser cela a coûté plus cher que la valeur des données elle-mêmes.
Messages postés
589
Date d'inscription
lundi 25 août 2003
Statut
Membre
Dernière intervention
18 juillet 2010

Je ne vois pas non plus comment tu pourrais faire, prendre 1 chiffre sur 4 te donnerai 64 bits mais bon la il n'y aurais plus vraiment de sécurité... La compression ne devrait suffir non plus par conséquent il faut modifier ton systeme pour prendre du 256 bits, sinon tu peux aussi te baser sur md5 qui fait un condensé plus cours, mais toujours pas du 64bits.
Messages postés
2
Date d'inscription
jeudi 25 janvier 2007
Statut
Membre
Dernière intervention
27 mars 2009

rebonjour,
pour le problème du binaire c'est bien résolu.
mais je ne voix pas comment je vais compresser et passer de 250 a 64 bit
si tu peux m'aider stp.
merci beaucoup.
Afficher les 23 commentaires

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.