J'ai besoin de produire une valeur de hachage basée sur une chaîne de longueur variable que je puisse stocker dans un champ n'ayant plus de 16 (en raison des exigences du fournisseur).
Je suis concaténant plusieurs chaînes qui sont passées à travers une transformation de script C # afin de calculer le hachage. Je suis limité par la spécification de fichier du fournisseur en ce que la production du hachage ne peut pas être plus de 16.
Quelqu'un a-t-il des suggestions? Comme exemple, la conversion de chaîne de l'algorith de MD5 a une longueur de 32.
5 Réponses :
Si vous avez 16 octets stocker un numéro 128 bits, ce n'est pas un problème. Stockez la valeur 128 bits sous forme de valeur de 16 bits au lieu d'une chaîne de 32 caractères qui stocké la valeur de 16 octets comme hexagonale.
comme une note que j'ai utilisé des champs GUID / UUID dans des bases de données pour stocker des haubans MD5. Pendant que ce n'est plus la sécurité cryptographiquement, les hachages MD5 de 128 bits sont bien pour les checksums (et c'est bien mieux que 64 bits.) Notez que je ne montre pas le contenu du fichier car est une bonne chance que cela contienne des caractères "non dérivés".
Les fonctions cryptographiques sont conçues de telle sorte que vous puissiez tronquer la sortie à une taille et la fonction de hachage tronquée reste une fonction de hachage cryptographique sécurisée. Par exemple, si vous prenez les 128 premiers bits (16 octets) de la production de SHA-512 appliquée à certaines entrées, les premiers 128 bits sont un hachage cryptographique aussi fort que tout autre hachage cryptographique de 128 bits.
La solution consiste à choisir une fonction de hachage cryptographique - SHA-256, SHA-384 et SHA-512 sont de bons choix - et tronquer la sortie à 128 bits (16 octets).
basé sur le commentaire selon lequel la valeur de hachage doit, lorsqu'elle est codée vers ASCII, conçue dans les 16 caractères ASCI, la solution est
16 octets convertis en hex sont toujours de 32 caractères. Pourriez-vous également fournir un lien avec votre affirmation sur la partie tronquante d'un hachage calculé est sécurisé comme en utilisant la version inférieure du hachage? Cela peut être vrai pour SHA (je ne sais pas de quelque manière que ce soit) mais je ne pense pas que vous puissiez faire une déclaration qui porte véritable sur tous les hatus.
@Matthew Whited: Je pense que l'affirmation de la justice est généralement considérée comme vraie. Il est difficile d'imaginer une attaque qui fonctionne sur le hachage tronqué mais pas sur le hachage complet, autre que la force brute.
Vous dites que vous ne pouvez pas simplement stocker les octets de hachage, comme une séquence d'octets? Que vous deviez encoder des octets, par exemple, codage hexagonal ou codage de base64? Si vous pouvez stocker les octets bruts, vous devez stocker les octets bruts et occuper tous les 16 octets de l'espace.
J'ai ajouté un lien vers une autre question dont le titre est "Est-il normal de tronquer un hachage SHA256 à 128 bits?"
Les exigences pour le fichier que je dois produire sont un fichier plat ASCII d'onglets ASCII et, étant donné que je ne connais pas trop les ramifications de la sortie de la séquence d'octets à un fichier texte, j'ai extrêmement intéressé par ces types de suggestions.
Édité. La solution est une combinaison de choix d'un hachage cryptographique fort, de tronquer la sortie à 12 octets, puis de la base64-codant sur le résultat à 16 octets d'ASCII.
J'utilise le SHA256Managé pour créer le hachage, mais j'étais curieux de savoir ce que les implications sont de sous-chaîne de la chaîne codée de base64 à 16 par rapport à 12 octets avant le codage. Est-ce principalement une question de performance ou existe également un risque de sécurité?
De manière générale, il est toujours instructif de penser à des valeurs de hachage sous forme de séquences de bit ou d'octets-séquences, avec les différents systèmes de codage de texte (hex, base64) utilisées uniquement comme dernière étape. Dans ce cas, l'un ou l'autre ordre fonctionnera à la même chose (tronquant à 12 octets, puis codant de base64, ou codage de base64, puis tronquant à 16 octets). Notez que le codage-tronquable-tronquable nécessitera de coder la valeur de hachage entière, alors que la tronçante-coding ne sera pas.
Merci Justice, j'apprécie l'explication.
Les hachages tronqués sont nettement plus faibles que les originaux. Vous pouvez plus facilement briser le hachage tronqué, sans avoir d'attaque sur le hachage complet: csrc.nist.gov/groups/st/hash/documents/kelsey_truncation.pdf
Vous pouvez facilement utiliser un hachage MD5 pour cela, mais vous devrez modifier la manière dont elle est stockée. Un MD5 est de 128 bits, qui est généralement affiché sous forme de valeurs 32 4 bits (hexadécimales). Un caractère standard est de 8 bits, cependant, de 16 caractères suffisent exactement pour stocker la valeur d'un hachage MD5.
Pour le convertir, essayez ce qui suit: P>
String hash32 = "d41d8cd98f00b204e9800998ecf8427e"
String hash16 = ""
for(int i = 0; i < 32; i+=2)
{
uint high = Convert.ToUInt32(hash32[i], 16);
uint low = Convert.ToUInt32(hash32[i+1], 16);
char c = (char) ((high << 4) | low);
hash16 += c;
}
Utiliser ou, XOR ou toute autre fonction binaire augmentera les chances de collision. Si vous utilisez simplement cela pour une somme de chèque, cela peut fonctionner, mais vous seriez probablement plus en sécurité avec XOR. Sinon, vous pourriez aussi bien utiliser un chèque de parité.
Si vous remarquez, je transfère un numéro qui sera toujours 4 octets ou moins à gauche 4 octets, de sorte que les bits faibles et élevés ne seront jamais entrés en collision.
Des commentaires sur ce code? Semble bien fonctionner ...
J'ai remarqué que cette question est relativement ancienne, mais je suis sûr que quelqu'un trouvera cette réponse à son précieux.
Ma suggestion serait d'utiliser Blake2B qui a la capacité d'utiliser 8 bits à 512 bits. Si aucune taille de clé n'est utilisée, la valeur par défaut est utilisée "512" dans ce cas. Blake2S Valeur par défaut 256 bits. espère que cela aide!
16 quoi? Est-ce binaire ou texte?
Idéalement, ce serait un texte car il sera écrit dans un fichier plat.
Les fichiers plats ne doivent pas nécessairement être du texte.
Les exigences pour le fichier que je dois produire sont un fichier plat ASCII délimité.