Строка -> SHA -> base64, 3 способа и 3 разных результата с помощью инструментов cmd (openssl / xxd / base64), почему? - PullRequest
Новая
       108

Строка -> SHA -> base64, 3 способа и 3 разных результата с помощью инструментов cmd (openssl / xxd / base64), почему?

1 голос
/ 13 апреля 2020 
method1:
$echo -n "The quick brown fox jumps over the lazy dog" | openssl sha1 | base64
MmZkNGUxYzY3YTJkMjhmY2VkODQ5ZWUxYmI3NmU3MzkxYjkzZWIxMgo=

method2:
$ echo -n "The quick brown fox jumps over the lazy dog" | openssl sha1 | xxd -r -p | base64
L9ThxnotKPzthJ7hu3bnORuT6xI=

method3:
echo -n "The quick brown fox jumps over the lazy dog" | openssl sha1 | xxd -b -p | base64
MzI2NjY0MzQ2NTMxNjMzNjM3NjEzMjY0MzIzODY2NjM2NTY0MzgzNDM5NjU2NTMxNjI2MjM3MzY2NTM3CjMzMzkzMTYyMzkzMzY1NjIzMTMyMGEK

Я в основном пытаюсь сделать контрольную сумму для входной строки The quick brown fox jumps over the lazy dog через sha1 в качестве контрольной суммы, а затем base64 результат, и у меня есть два метода выше, я думаю, method2 правильный ответ, но я должен дополнительный шаг, чтобы преобразовать гекс обратно в двоичный файл через xxd -r и простой формат -p, прежде чем я снова передам его в base64, почему я должен сделать этот дополнительный шаг?

Я не нахожу, чтобы инструмент base64 cmd ожидал, чтобы вход был двоичным? Но давайте предположим, что когда я явно конвертирую его в двоичный файл и передаю его в base64 через mehod3 xxd -b option, результат снова будет другим.

Это может быть проще, если в языке программирования bcos мы имеем полный контроль, но через Несколько инструментов cmd немного сбивают с толку, может кто-нибудь помочь мне объяснить это?

1 Ответ

0 голосов
/ 14 апреля 2020

Здесь есть три разных результата, потому что вы передаете три разные строки в base64.

По вашему вопросу на base64, ожидая, что вход будет двоичным, @chepner прямо здесь:

Все данные являются двоичными; text - это просто поток байтов, представляющих кодировку (ASCII, UTF-8 и т. д. c) текста.

Промежуточные шаги

Давайте сохраним общую команду в переменной для ясности. 

$ msg='The quick brown fox jumps over the lazy dog'
$ sha_val="$(printf "$msg" | openssl sha1 | awk '{ print $2 }')"
$ printf "$sha_val"
2fd4e1c67a2d28fced849ee1bb76e7391b93eb12

Несколько замечаний:

Сравнение байтов

Мы можем использовать xxd для сравнения байтов для каждый, используя -c 1000, чтобы использовать 1000-символьные строки (т.е. не добавлять новые строки для <1000-символьных строк). Это полезно для строк, таких как вывод в method2, где есть управляющие символы, которые не могут быть напечатаны. </p>

method 1

Это шестнадцатеричное представление значения sha. Например, первый 2 в выводе шага в этом результате равен 32, поскольку шестнадцатеричное число 32 <=> de c 50 <=> ASCII / UTF-8 "2". Если это сбивает с толку, взгляните на ASCII таблицу . 

$ printf "$sha_val" | xxd -p -c 1000
32666434653163363761326432386663656438343965653162623736653733393162393365623132

метод 2

Этот вывод ТОЧНЫЙ ЖЕ, как $ sha_val, учитывая, что мы преобразование из шестнадцатеричного в бинарный ASCII и затем обратно с xxd. Обратите внимание, что преобразование значения sha из шестнадцатеричного в двоичное не обязательно для base64. 

$ printf "$sha_val" | xxd -r -p | xxd -p -c 1000
2fd4e1c67a2d28fced849ee1bb76e7391b93eb12

метод 3

xxd -p переопределяет параметр -b, поэтому xxd -b -p <=> xxd -p. 

$ printf "$sha_val$" | xxd -p -c 1000 | xxd -p -c 1000
33323636363433343635333136333336333736313332363433323338363636333635363433383334333936353635333136323632333733363635333733333339333136323339333336353632333133323061

Как видите, base64 генерирует три разные строки, поскольку получает три разные строки.

...