Pourquoi tant de chaînes hachées et cryptées se terminent-elles par un signe égal?

Je travaille en C # et MSSQL et, comme vous vous en doutez, je stocke mes mots de passe salés et hachés.

Lorsque je regarde le hachage stocké dans une colonne nvarchar (par exemple, le fournisseur d’adhésion aspnet à la livraison). J'ai toujours été curieux de savoir pourquoi les valeurs générées de Salt et Hash semblent toujours se terminer par un ou deux signes d'égalité.

J'ai vu des choses similaires en travaillant avec des algorithmes de chiffrement, est-ce une coïncidence ou y a-t-il une raison à cela?

hashing character-encoding

— Liath
source

En passant, si vous stockez des données binaires encodées en Base64 dans un champ NVARCHAR, je pleure vos pertes de stockage 6x! D'une part, Base64 ne peut contenir que 64 caractères dans la moitié inférieure de l'ASCII (vous n'avez donc besoin que de VARCHAR pour enregistrer la moitié). Pour deux, Base64 décompose chaque octet de données en 1-4 caractères. SQL Server a déjà un type VARBINARY qui est tout à fait capable de stocker vos hachages sans vous encombrer d'encodage, et se moque de la collation dans ses comparaisons ... :-)

— jimbobmcgee

@WillieWheeler, le hachage doit être stocké d'une manière ou d'une autre. Base64 n'est peut-être pas le support de stockage idéal, mais il n'y a rien de fondamentalement faux. Si hash("my password")produit le tableau [1,2,3,4,5]et que je dois stocker ces valeurs dans une base de données, il existe des choix pires que de stocker la chaîne AQIDBAU=(Bien sûr, si la fonction de hachage utilisée produit déjà une chaîne, il semble un peu ridicule de l'encoder ensuite en Base64. )

— Brian S

@ WillieWheeler Je pense que vous manquez le point. Relisez ce que Brian S a écrit - il ne parlait pas des propriétés de base64 pour le hachage - ce serait absurde que base64 n’est pas un algorithme de hachage. Il dit qu'il n'y a rien de mal à stocker un hachage (produit par une fonction / un algorithme de hachage) sous la forme base64.

— Andrew Savinykh

Le PO dit qu'il enregistre le hachage et qu'il se termine par des signes d'égalité. Cela suggère qu'il confond avec le codage Base64. Si le fait est que c'est bien de coder un hachage en base64, alors bien sûr, mais qu'est-ce que cela a à voir avec quoi que ce soit?

— Willie Wheeler

Oui, j'ai finalement compris ce qui se passait. J'ai regardé dans mes fichiers de clé publique et privée SSH et j'ai remarqué qu'ils avaient aussi les terminaisons = / ==. Ce sont des encodages en base64 de tableaux d'octets, comme BrianS et zespri. Merci les gars.

— Willie Wheeler

Ces chaînes hachées sont (généralement?) Codées au format Base64 et le signe égal est utilisé pour remplir la chaîne afin de rendre la longueur (nombre d'octets) divisible par trois. Wikipedia l'explique assez bien: http://en.wikipedia.org/wiki/Base64 .

— svenslaggare
source

Pourrait-il s'agir d'un remplissage de codage en base 64?

La séquence '==' indique que le dernier groupe ne contenait qu'un octet, et '=' qu'il contenait deux octets. L'exemple ci-dessous montre comment le fait de tronquer l'entrée de l'ensemble de la citation ci-dessus modifie le remplissage de la sortie:

http://en.wikipedia.org/wiki/Base64#Output_padding

— Jaydee
source