Deux codages Base64 produisent le même décodage

Question

Est-il prévu que deux codages puissent correspondre au même décodage? J'essaie de résoudre un problème de signature numérique en effectuant des contrôles de cohérence sur les chaînes intermédiaires codées en base64.

Par exemple, le base64 suivant le codage:

R0VUDQoNCg0KRnJpLCAwNCBTZXAgMjAwOSAxMTowNTo0OSBHTVQrMDA6MDANCi8= 

et:

R0VUCgoKRnJpLCAwNCBTZXAgMjAwOSAxMDozMzoyOCBHTVQrMDA6MDAKLw== 

deux decode à:

GET 


Fri, 04 Sep 2009 11:05:49 GMT+00:00 
/

(avec les personnages se sont échappés, c'est: GET\n\n\n Fri, 04 Sep 2009 11:05:49 GMT+00:00\n/)

Le premier codage provient du test de deux encodeurs base64 en ligne.

Le deuxième codage provient d'un codeur Base64 Objective-C available here.

Y at-il un problème avec le résultat que je génère avec l'encodeur Obj-C?

Answer 1

Il est clair que les chaînes codées ont des modèles similaires lorsqu'elles correspondent à des caractères alphanumériques et différentes lorsqu'elles correspondent à des sauts de ligne. Donc la différence est que quelque part le long de la façon "Encode" -> "Décoder" le logiciel traite différemment les sauts de ligne (CR (\ r), LF (\ n) ou CRLF (\ r \ n)) et c'est pourquoi vous avez résultats. A part cela, il n'y a pas deux façons différentes de coder une chaîne donnée en Base64 et pas deux façons différentes de décoder une donnée codée Base64 valide.

Answer 2

En fait, ils ne décodent pas à la même chose.

$ echo 'R0VUCgoKRnJpLCAwNCBTZXAgMjAwOSAxMDozMzoyOCBHTVQrMDA6MDAKLw==' | base64 -d | hexdump 
0000000 4547 0a54 0a0a 7246 2c69 3020 2034 6553 
0000010 2070 3032 3930 3120 3a30 3333 323a 2038 
0000020 4d47 2b54 3030 303a 0a30 002f   
000002b 
$ echo 'R0VUDQoNCg0KRnJpLCAwNCBTZXAgMjAwOSAxMTowNTo0OSBHTVQrMDA6MDANCi8=' | base64 -d | hexdump 
0000000 4547 0d54 0d0a 0d0a 460a 6972 202c 3430 
0000010 5320 7065 3220 3030 2039 3131 303a 3a35 
0000020 3934 4720 544d 302b 3a30 3030 0a0d 002f 
000002f 

Answer 3

L'essentiel est que la base 64 des chaînes décoder des séquences d'octets et non des caractères. Comparer les tableaux d'octets produits par chacune de vos chaînes de base 64 montre que la différence réside dans la façon dont la terminaison de ligne est faite - partout où le premier a un 13 suivi d'un 10, le second a juste un 10. Ceci est le Windows standard vs- Différence de terminaison de ligne Unix.

Answer 4

Comme suggéré @sharptooth, les sauts de ligne sont \r\n dans la première, \n dans le second.

>>> base64.b64decode("R0VUDQoNCg0KRnJpLCAwNCBTZXAgMjAwOSAxMTowNTo0OSBHTVQrMDA6MDANCi8=") 
'GET\r\n\r\n\r\nFri, 04 Sep 2009 11:05:49 GMT+00:00\r\n/' 
>>> base64.b64decode("R0VUCgoKRnJpLCAwNCBTZXAgMjAwOSAxMDozMzoyOCBHTVQrMDA6MDAKLw==") 
'GET\n\n\nFri, 04 Sep 2009 10:33:28 GMT+00:00\n/' 

Answer 5

Un autre exemple pour prouver que les chaînes ne sont pas égaux, en utilisant Python:

>>> from base64 import decodestring as d 
>>> a = "R0VUDQoNCg0KRnJpLCAwNCBTZXAgMjAwOSAxMTowNTo0OSBHTVQrMDA6MDANCi8=" 
>>> b = "R0VUCgoKRnJpLCAwNCBTZXAgMjAwOSAxMDozMzoyOCBHTVQrMDA6MDAKLw==" 
>>> d(a) 
'GET\r\n\r\n\r\nFri, 04 Sep 2009 11:05:49 GMT+00:00\r\n/' 
>>> d(b) 
'GET\n\n\nFri, 04 Sep 2009 10:33:28 GMT+00:00\n/' 
>>> d(a) == d(b) 
False 

La chaîne utilise plus CLRF linebreaks, le shorther un lfs plaine.