Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

CoqBlog

.NET is good :-)
{ Blog de coq }

Actualités

Il y a Base64 et Base64...

Vous connaissez tous ce fameux encodage dit "Base64", consistant à représenter des données binaires en utilisant un jeu de 64 caractères, en général définis comme étant composé de :

  • la plage de 'A' à 'Z' (26 caractères)
  • la plage de 'a' à 'z' (26 caractères)
  • la plage de '0' à '9' (10 caractères)
  • les symboles '+' et '/'

Un 65ème caractère, ne représentant pas une donnée, sert au padding en fin de chaîne : '='.

Les développeurs .NET l'utilisent souvent au travers de la méthode Convert.ToBase64String.

Du coup comme à chaque fois que des symboles sont utilisés en supplément de traditionnels caractères alphanumériques, c'est à dire des caractères susceptibles d'être interdit dans un système de fichier etc, une question se pose : tout le monde est censé utiliser ce jeu de caractères et seulement celui-là ?

Dans le cas de Base64 la réponse est non.
Il existe de manière "officielle" au moins 2 alphabets :

Base32 n'est guère mieux : Base 32 Encoding with Extended Hex Alphabet.

 

Pour les cas où la donnée d'origine doit être retrouvée ou ceux où la même chaîne doit être générée pour une entrée donnée, ça peut être problématique.
On peut citer comme exemple la synchronisation interprocessus de l'accès à une ressource (du genre système de fichier) au moyen d'un mutex : nous sommes limités en longueur de nom (MAX_PATH, voir CreateMutex) donc hors de question d'utiliser le chemin d'accès (un bon vieux hash SHA-2 du chemin fera donc l'affaire) et nous aurons besoin d'être certains que les 2 processus génèreront exactement la même chaîne pour un chemin d'accès donné.

Si nous choisissons Base64 pour encoder le hash nous aurons donc au minimum besoin de nous assurer que le même alphabet soit utilisé des 2 côtés, et ce de manière durable.
Peu de risque que l'implémentation de Convert.ToBase64String change mais je n'ai pas vu de garantie non plus.

Sinon, vu que dans le cas du mutex le besoin de compacter au maximum la longueur n'est pas forcément nécessaire (tant que nous ne dépassons pas les 260 caractères au total), un bon vieux Base16 (hex) ira très bien : SHA-512 = 64 bytes = 128 caractères (au lieu des 88 caractères obtenus avec Base64).

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Posted: dimanche 25 octobre 2009 16:12 par coq
Classé sous : ,

Commentaires

Pas de commentaires

Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01