De C# à Go : atteindre la compatibilité des codages AES et Base64

Il y a quelques semaines, j'ai été confronté à un problème intéressant : j'ai dû migrer un algorithme de chiffrement AES de C# vers Go. Dans l'implémentation Go, nous avions déjà un algorithme de chiffrement AES, mais il n'était pas compatible avec l'implémentation C#, et plusieurs tests ont échoué car les résultats ne correspondaient pas, principalement dans le dernier caractère.

Le problème était que je n'avais pas le code source de l'implémentation C#, seulement le binaire, une DLL qui était utilisée dans le projet .NET.

J'ai essayé d'obtenir le code source de l'implémentation C#, mais sans succès. S'agissant d'un ancien projet, aucune documentation n'était disponible. Heureusement, c'est mon patron qui a développé cette implémentation, mais je ne me souvenais pas des détails exacts. Cependant, je savais qu'à la fin du processus de cryptage AES, une fonction d'encodage base64 était utilisée.

Avec cet indice, j'ai ouvert le projet en .NET et installé l'extension JetBrains pour décompiler le code source, et j'ai obtenu le code de la bibliothèque qui a été utilisé pour crypter les informations.

Finalement, j'ai découvert que le problème ne venait pas de l'algorithme de cryptage AES, mais de l'encodage base64.

Dans le code C#, à la fin du processus de chiffrement AES, la fonction suivante a été utilisée pour l'encodage base64 : HttpServerUtility.UrlTokenEncode.

La fonction UrlTokenEncode est une fonction .NET qui encode un tableau d'octets dans une chaîne de texte base64 pour la transmission dans une URL. Cette fonction effectue trois actions clés qui expliquent la différence de résultats :

1. Codage Base64 sécurisé pour les URL : utilise une variante de Base64 adaptée aux URL, en remplaçant les caractères par - et / par _.

2. Suppression des caractères de remplissage : La fonction supprime les caractères padding = qui sont généralement utilisés dans l'encodage Base64 standard.

3. Ajout d'un nombre à la fin : La fonction ajoute un nombre à la fin de la chaîne pour indiquer combien de caractères de remplissage ont été supprimés.

J'ai découvert tout cela grâce à ChatGPT, pas parce que je suis un expert en base64. Grâce à ces informations, j'ai pu modifier l'implémentation en Go pour être compatible avec celle de C#.

Dans Go, après avoir chiffré les informations avec AES, l'encodage en base64 se fait comme suit :

encode := base64.RawURLEncoding.EncodeToString(paddedBytes)

Et enfin, le nombre de caractères de remplissage supprimés est ajouté à la fin de la chaîne :

// Calcular el número de caracteres de relleno (`=`) que se habrían añadido
paddingCount := (4 - len(paddedBytes)%3) % 4

// Añadir el conteo de relleno al final de la cadena codificada (como hace UrlTokenEncode de C#)
if paddingCount > 0 {
    encoded += strconv.Itoa(paddingCount)
}

Dans la ligne paddingCount := (4 - len(paddedBytes)%3) % 4, le nombre de caractères de remplissage (=) est calculé puis ajouté à la fin de la chaîne encodée en base64 :

• len(paddedBytes)%3 calcule le nombre d'octets qui n'ont pas été codés en base64.
• (4 - len(paddedBytes)%3) % 4 calcule le nombre de caractères de remplissage manquants pour que la longueur soit divisible par 4. Si aucun remplissage n'est nécessaire, le résultat est 0.

En bref, le problème n'était pas l'algorithme de cryptage AES, mais l'encodage base64. Grâce aux informations obtenues auprès de ChatGPT, j'ai pu modifier l'implémentation en Go pour être compatible avec celle de C#. Dans ce cas, l’utilisation de ChatGPT a été très utile car elle m’a permis d’économiser beaucoup de temps et de maux de tête ; Bien sûr, j'ai dû ajuster chaque réponse jusqu'à ce que les résultats des deux implémentations soient égaux.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!