До появления Blowfish существовавшие алгоритмы были либо запатентованными, либо ненадёжными, а некоторые и вовсе держались в секрете (например, Skipjack). Алгоритм был разработан в 1993 году Брюсом Шнайером в качестве быстрой и свободной альтернативы устаревшему DES и запатентованному IDEA.
По заявлению автора, критериями проектирования Blowfish были[1][2]:
скорость (шифрование на 32-битных процессорах происходит за 26 тактов);
простота (за счёт использования простых операций, уменьшающих вероятность ошибки реализации алгоритма);
компактность (возможность работать в менее, чем 5 Кбайт памяти);
настраиваемая безопасность (изменяемая длина ключа).
Алгоритм состоит из двух частей: расширение ключа и шифрование данных. На этапе расширения ключа исходный ключ (длиной до 448 бит) преобразуется в 18 32-битовых подключей и в 4 32-битных S-блока, содержащих 256 элементов. Общий объём полученных ключей равен бит или байт[1][2].
Производится операция XOR над с первыми 32 битами ключа , над со вторыми 32-битами и так далее. Если ключ короче, то он накладывается циклически.
Шифрование ключей и таблиц замен
Алгоритм шифрования 64-битного блока, используя инициализированные ключи и таблицу замен , шифрует 64 битную нулевую (0x0000000000000000) строку. Результат записывается в , .
и шифруются изменёнными значениями ключей и таблиц замен. Результат записывается в и .
Шифрование продолжается до изменения всех ключей и таблиц замен .
Шифрование текста полученными ключами и F(x), с предварительным разбиением на блоки по 64 бита. Если невозможно разбить начальный текст точно на блоки по 64 бита, используются различные режимы шифрования для построения сообщения, состоящего из целого числа блоков. Суммарная требуемая память 4168 байт.
Дешифрование происходит аналогично[1][2], только применяются в обратном порядке.
Выбор начального значения P-массива и таблицы замен[править | править код]
Нет ничего особенного в цифрах числа пи[2][3]. Данный выбор заключается в инициализации последовательности, не связанной с алгоритмом, которая могла бы быть сохранена как часть алгоритма или получена при необходимости (Пи (число)). Как указывает[3]Шнайер: «Подойдёт любая строка из случайных битов — цифры числа e, RAND-таблицы или биты с выхода генератора случайных чисел.»
S-блоки называются слабыми, если существуют такие . Ключ, генерирующий слабыеS-блоки, тоже называется слабым. Серж Воденэ указал[4] на наличие небольшого класса слабых ключей (генерирующих слабые S-блоки). Вероятность появления слабого S-блока равна . Он также рассмотрел упрощенный вариант Blowfish, с известной функцией F(x) и слабым ключом. Для этого варианта требуется выбранных открытых текстов (t — число раундов, а символы [] означают операцию получения целой части числа). Эта атака может быть использована только для алгоритма с . Для требуется открытых текстов, причём для варианта с известным F(x) и случайным ключом требуется открытых текстов. Но данная атака неэффективна для Blowfish с 16 раундами ().
Невозможно заранее определить, является ли ключ слабым. Проводить проверку можно только после генерации ключа.
Криптостойкость можно настраивать за счёт изменения количества раундов шифрования (увеличивая длину массива P) и количества используемых S-блоков. При уменьшении используемых S-блоков возрастает вероятность появления слабых ключей, но уменьшается используемая память. Адаптируя Blowfish для 64-битной архитектуры, можно увеличить количество и размер S-блоков (а следовательно и память для массивов P и S), а также усложнить F(x), причём для алгоритма с такой функцией F(x) невозможны вышеуказанные атаки.
Модификация F(x): на вход подается 64-битный блок, который делится на восемь 8-битных блоков (X1-X8). Результат вычисляется по формуле
, где — это операция сложения по модулю
Использование Blowfish 64-битного блока (в отличие, например, от 128-битного блока AES) делает его уязвимым для атаки дней рождения, в частности, в контекстах типа HTTPS. В 2016 году атака SWEET32 продемонстрировала, как использовать атаку дней рождения для восстановления открытого текста (то есть расшифровки) из 64-битных блоков.[5] Проект GnuPG рекомендует не использовать Blowfish для файлов с размером, превышащим 4 ГБ[6] из-за малого размера блока[7].
Известно, что вариант Blowfish с уменьшенным количеством раундов является уязвимым для атак на основе открытых текстов на сравнительно слабых ключах. Реализации Blowfish с 16 раундами шифрования не подвержены подобным атакам.[8][9] Тем не менее, Брюс Шнайер рекомендовал переход на последователя Blowfish - Twofish.[10]
Blowfish зарекомендовал себя как надёжный алгоритм, поэтому реализован во многих программах, где не требуется частая смена ключа и необходима высокая скорость шифрования/расшифровывания.[3]
Скорость шифрования алгоритма во многом зависит от используемой техники и системы команд. На различных архитектурах один алгоритм может значительно опережать по скорости своих конкурентов, а на другом ситуация может сравняться или даже измениться в прямо противоположную сторону. Более того, программная реализация значительно зависит от используемого компилятора. Использование ассемблерного кода может повысить скорость шифрования. На скорость шифрования влияет время выполнения операций mov, add, xor, причём время выполнения операций увеличивается при обращении к оперативной памяти (для процессоров серии Pentium примерно в 5 раз). Blowfish показывает более высокие результаты при использовании кэша для хранения всех подключей. В этом случае он опережает алгоритмы DES, IDEA.[12] На отставание IDEA влияет операция умножения по модулю . Скорость Twofish может быть близка по значению к Blowfish за счёт большего шифруемого блока.
Хотя Blowfish по скорости опережает некоторые свои аналоги, но при увеличении частоты смены ключа основное время его работы будет уходить на подготовительный этап, что в сотни раз уменьшает его эффективность.
↑GnuPG Frequently Asked Questions (неопр.). — «Blowfish should not be used to encrypt files larger than 4Gb in size, but Twofish has no such restrictions.» Дата обращения: 26 января 2018. Архивировано 21 декабря 2017 года.
↑GnuPG Frequently Asked Questions (неопр.). — «For a cipher with an eight-byte block size, you’ll probably repeat a block after about 32 gigabytes of data. This means if you encrypt a single message larger than 32 gigabytes, it’s pretty much a statistical guarantee you’ll have a repeated block. That’s bad. For this reason, we recommend you not use ciphers with eight-byte data blocks if you’re going to be doing bulk encryption. It’s very unlikely you’ll have any problems if you keep your messages under 4 gigabytes in size.» Дата обращения: 27 января 2018. Архивировано 21 декабря 2017 года.