Хотел поделиться одной тонкостью, на разбирательства с которой мне пришлось потратить некоторое количество времени при шифровании строки текста.
Итак, у меня была строка текста, которую я решил зашифровать. Для шифрования я решил использовать OpenSSL и планировал получить примерно следующее:
<base64>( <openssl aes-128-cbc>( исходная строка ) )
Сказано - сделано.
Итак, у меня была строка текста, которую я решил зашифровать. Для шифрования я решил использовать OpenSSL и планировал получить примерно следующее:
<base64>( <openssl aes-128-cbc>( исходная строка ) )
Сказано - сделано.
Я создаю файл, записываю в него исходный текст. Далее командой "openssl aes-128-cbc" создаю другой файл с зашифрованной строкой (формат двоичный). Напоследок создаю третий файл командой "openssl base64" и использую полученную строку Base64. Я счастлив, зрители ликуют.
Начинаю использовать полученную строку - что такое, md5 расшифрованной строки отличается от md5 исходной строки.
Дальше начинается проверка кода который отвечает за расшифровку - все нормально.
Пускаю в ход hexdump, смотрю, в конце расшифрованного текста затесался символ LF (Line Feed, 0x0A). Вот, думаю, подстава, OpenSSL некорректно работает, при этом еще google не полнится гневными письменами пользователей.
В итоге я делаю костыль и отрезаю этот символ. А через несколько часов до меня дошло - ни разу не OpenSSL это виноват. Просто текстовый редактор vim сует этот символ, cat так же этим грешит.
Если после этого сделать tr -d '\n' < src_file > dest_file, а потом открыть в vim, то он еще и предупредит что файл без eol. Не могу сказать точно, все ли редакторы лепят этот символ в конец файла, но получается что если нужно зашифровать строку - openssl можно использовать, но нужно шифрованный текст передавать в поток ввода, либо корректировать файл с исходной строкой. Кстати, openssl не вставляет этот символ в конец результирующего файла при выполнении шифрования openssl aes-128-cbc, а вот openssl base64 еще как вставляет. Чудеса.
Начинаю использовать полученную строку - что такое, md5 расшифрованной строки отличается от md5 исходной строки.
Дальше начинается проверка кода который отвечает за расшифровку - все нормально.
Пускаю в ход hexdump, смотрю, в конце расшифрованного текста затесался символ LF (Line Feed, 0x0A). Вот, думаю, подстава, OpenSSL некорректно работает, при этом еще google не полнится гневными письменами пользователей.
В итоге я делаю костыль и отрезаю этот символ. А через несколько часов до меня дошло - ни разу не OpenSSL это виноват. Просто текстовый редактор vim сует этот символ, cat так же этим грешит.
Если после этого сделать tr -d '\n' < src_file > dest_file, а потом открыть в vim, то он еще и предупредит что файл без eol. Не могу сказать точно, все ли редакторы лепят этот символ в конец файла, но получается что если нужно зашифровать строку - openssl можно использовать, но нужно шифрованный текст передавать в поток ввода, либо корректировать файл с исходной строкой. Кстати, openssl не вставляет этот символ в конец результирующего файла при выполнении шифрования openssl aes-128-cbc, а вот openssl base64 еще как вставляет. Чудеса.
Комментариев нет:
Отправить комментарий