егістри.
. З цих регістрів «набирається» необхідну кількість бітів ключової інформації за допомогою розширює перестановки. Операція не виконує будь-яких обчислень, отримання 108 бітів ключової інформації з 48 відбувається шляхом неодноразового використання певних бітів ключових регістрів. Ключова перестановка не описана детально в специфікації алгоритму.
. Для отримання ключової інформації для наступного раунду виконується побітовий циклічний зсув на 1 біт вмісту кожного з ключових регістрів. Потім знову проводиться перестановка. Цей крок повторюється в циклі необхідну кількість разів до завершення роботи алгоритму.
Рис. 1.9 - Процедура розширення ключа у варіанті № 1
Варіант № 2
За сучасними мірками 48-бітний розмір ключа шифрування є абсолютно недостатнім; мабуть, подібні думки були і у розробників алгоритму Lucifer, тому вже в тому ж 1971 з'явився другий варіант алгоритму, зашифровує дані 64-бітовим ключем. Проте другий варіант шифрував блоками всього по 32 біта, що також явно недостатньо (оскільки при -бітний блоці після зашіфровиванія порядку блоків відкритого тексту на одному і тому ж ключі починає відбуватися витік інформації про шіфруемих даних).
Цей варіант алгоритму, як і попередній, запатентований фірмою IBM і описаний в патенті.
Між варіантами № 2 та № 1 істотно більше відмінностей, ніж подібностей. Другий варіант алгоритму розбиває шіфруемий 32-бітний блок даних на два субблока по 16 бітів і виконує 16 раундів перетворень, в кожному з яких виконується наступна послідовність операцій (загальна структура алгоритму наведена на рис. 1.10):
Рис. 1.10 - Структура варіанта № 2
. Шіфруемий блок даних розбивається на два субблока: і.
. Субблок розбивається на 4 фрагмента по 4 біта, кожен з яких обробляється окремо, тобто інші операції повторюються для кожного фрагмента.
. Кожен з фрагментів складається по модулю 16 с - 4-бітовим фрагментом ключа раунду для операції додавання, де:
- номер оброблюваного фрагмента;
- номер поточного раунду.
. Над кожним із фрагментів виконується залежна від ключа таблична заміна: оброблюваний фрагмент замінюється 4-бітовим значенням згідно табл. 1.2.
Таблиця 1.2.
де:
, являє собою -й біт 4-бітного фрагмента ключа раунду, керуючого замінами.
- зворотне значення для.
Згідно вхідному значенню, з таблиці вибираються бітові значення, наприклад, для вхідного значення 14 і будуть отримані наступні значення:
. Виконується накладення операцією послідовності, що представляє собою результат обробки фрагмента субблока, на певні біти субблока. Біти субблока, що беруть участь в даній операції, вибираються за участю певного 4-бітного фрагмента ключа раунду згідно табл. 1.3.
Таблиця 1.3.
Керуючим бітом для є біт фрагмента.
Варіант № 3
Це найменш докладно описаний варіант алгоритму Lucifer, його опис наведено в статті [25]. Судячи з опису, алгоритм являє собою послідовність наступних операцій (рис. 1.11):
· керовані контрольними бітами секретного ключа табличні заміни - аналогічно варіанту № 1, в залежності від значення контрольного біта ключа виконується заміна або.
· фіксовані бітові перестановки.
Рис. 3.11 - Структура варіанта № 3
Багаторазове повторення цих операцій і являє собою алгоритм шифрування.
У статті [25] не вказується переважна більшість параметрів алгоритму: немає ні точної кількості раундів, ні значень таблиць замін і перестановок, не вказані розмір блоку і ключа (128-бітові блоки і ключі вказуються лише в якості можливих значень). Таким чином, даний варіант алгоритму Lucifer є ще більш «шаблонним», ніж варіант №1. Варто відзначити той факт, що навіть всесвітньо відомі експерти в області криптографії роблять різні припущення про те, який з варіантів алгоритму Lucifer був попередником алгоритму DES.
У главі був виконаний огляд існуючого програмного забезпечення для забезпечення безпеки переданої в мережі інформації за допомогою криптографічних алгоритмів. Також розглянули криптографічні алгоритми, що застосовуються в існуючих програмах.
Скористатися пропонованими продуктами може і зловмисник, тому для особистих цілей краще розробити с...
