Спек (шифр)
![]() 3 раунда Speck с расписанием из 2 слов. | |
Общий | |
---|---|
Дизайнеры | Рэй Болье, Дуглас Шорс, Джейсон Смит, Стефан Тритман-Кларк, Брайан Уикс, Луис Уингерс, АНБ |
Впервые опубликовано | 2013 |
Связано с | Саймон , Тройка |
Деталь шифрования | |
Размеры ключей | 64, 72, 96, 128, 144, 192 или 256 бит. |
Размеры блоков | 32, 48, 64, 96 или 128 бит |
Структура | АРКС |
Раунды | 22–34 (в зависимости от размера блока и ключа) |
Скорость | 2,6 cpb (5,7 без SSE ) на Intel Xeon 5640 (Speck128/128) |
Лучший публичный криптоанализ | |
Никаких атак на полные шифры не известно, но были атакованы версии с уменьшенным числом раундов. Дифференциальный криптоанализ может сломать около 70–75% раундов большинства вариантов немного быстрее, чем грубая сила; [1] [2] см . #Криптоанализ . |
Speck — это семейство облегченных блочных шифров, публично опубликованное Агентством национальной безопасности (АНБ) в июне 2013 года. [3] Speck был оптимизирован для повышения производительности программных реализаций, а его родственный алгоритм Simon — для аппаратных реализаций. Speck — это шифр добавления-поворота-исключения (ARX).
АНБ начало работать над шифрами Саймона и Спека в 2011 году. Агентство ожидало, что некоторым агентствам федерального правительства США понадобится шифр, который будет хорошо работать на разнообразном наборе устройств Интернета вещей , сохраняя при этом приемлемый уровень безопасности. [4]
Описание шифра [ править ]
Speck поддерживает различные размеры блоков и ключей. Блок всегда состоит из двух слов, но слова могут иметь размер 16, 24, 32, 48 или 64 бита. Соответствующий ключ состоит из 2, 3 или 4 слов. Функция округления состоит из двух вращений: добавления правого слова к левому слову, xoring ключа в левое слово, а затем xoring левого слова в правое слово. Количество раундов зависит от выбранных параметров следующим образом: [3]
Размер блока (биты) | Размер ключа (биты) | Раунды |
---|---|---|
2×16 = 32 | 4×16 = 64 | 22 |
2×24 = 48 | 3×24 = 72 | 22 |
4×24 = 96 | 23 | |
2×32 = 64 | 3×32 = 96 | 26 |
4×32 = 128 | 27 | |
2×48 = 96 | 2×48 = 96 | 28 |
3×48 = 144 | 29 | |
2×64 = 128 | 2×64 = 128 | 32 |
3×64 = 192 | 33 | |
4×64 = 256 | 34 |
Ключевое расписание использует ту же функцию раунда, что и основной блочный шифр.
Справочный код [ править ]
Ниже приведена эталонная реализация дизайнерами, написанная на C , варианта Speck с размером блока и ключом 128 бит, где ключ = (K[1], K[0]). Он адаптирован из их электронного издания IACR . [3]
#include <stdint.h>
#define ROR(x, r) ((x >> r) | (x << (64 - r)))
#define ROL(x, r) ((x << r) | (x >> (64 - r)))
#define R(x, y, k) (x = ROR(x, 8), x += y, x ^= k, y = ROL(y, 3), y ^= x)
#define ROUNDS 32
void encrypt(uint64_t ct[2],
uint64_t const pt[2],
uint64_t const K[2])
{
uint64_t y = pt[0], x = pt[1], b = K[0], a = K[1];
R(x, y, b);
for (int i = 0; i < ROUNDS - 1; i++) {
R(a, b, i);
R(x, y, b);
}
ct[0] = y;
ct[1] = x;
}
Обратите внимание, что этот код вычисляет раундовые ключи ( расписание ключей ) по требованию. На практике, как и в случае с другими блочными шифрами, реализации обычно вычисляют раундовые ключи только один раз и кэшируют их, а не пересчитывают их для каждого зашифрованного или расшифрованного блока. Хотя, как отмечают авторы, «учитывая, что малый размер кода был основной целью разработки, имело смысл повторно использовать функцию round для генерации раундовых ключей. Этот подход позволяет генерировать раундовые ключи «на лету» для реализаций микроконтроллера, используя только круглый функциональный код, очень мало ПЗУ и никакой оперативной памяти, кроме того, что требуется для хранения ключа и открытого текста». [5]
Для 16-битных слов (Speck32) поворот составляет 7 бит вправо и 2 бита влево; для всех остальных размеров слов это 8 и 3, как показано здесь.
Если длина ключа превышает 2 слова, их 2 или 3. a
значения, которые используются в ротации.
Порядок байтов [ править ]
В исходной статье Спека явно не указывается порядок байтов, когда блок открытого текста интерпретируется как два слова, используемые в алгоритме шифрования. Тестовые векторы, приведенные в статье, предполагают порядок с прямым порядком байтов. Однако авторы алгоритма посоветовали некоторым разработчикам [6] этот порядок байтов с прямым порядком байтов должен использоваться для ключей, открытого текста и зашифрованного текста, и эта практика была принята другими. [7]
Производительность [ править ]
Согласно тестам потокового шифрования ECRYPT (eBASC), Speck является одним из самых быстрых доступных шифров как для длинных, так и для коротких сообщений. Некоторые средние показатели производительности для длинных сообщений (128-битная версия с размером 128 блоков): 1,99 циклов на байт (cpb) на AMD Ryzen 7 1700; 1,27 cpb на Intel Core i5-6600; 15,96 cpb на Broadcom BCM2836 Cortex A7. [8] Например, на платформе ARMv7 Speck примерно в 3 раза быстрее AES . [9]
При реализации на 8-битном микроконтроллере AVR шифрование Speck с 64-битными блоками и 128-битным ключом потребляет 192 байта флэш-памяти , временные переменные занимают 112 байт ОЗУ, а для шифрования каждого байта в блоке требуется 164 цикла. [10]
Salsa20 — это поточный шифр с сопоставимой производительностью, но его сложно безопасно использовать в некоторых приложениях, где хорошо работают блочные шифры, такие как Speck. Это побудило Google добавить реализацию Speck в ядро Linux версии 4.17, планируя предложить его в качестве опции для шифрования дисков на младших устройствах Android , которые в противном случае были бы незашифрованы из-за низкой производительности AES на процессорах, в которых отсутствуют инструкции AES . [11] [12] Позже Speck был исключен из ядра Linux из-за негативной реакции и опасений, и вместо этого Google переключился на алгоритм Adiantum . [13] [14] [15]
Безопасность [ править ]
Криптоанализ [ править ]
Разработчики утверждают, что Speck, хотя и является «облегченным» шифром, спроектирован так, чтобы обеспечить полную безопасность для каждого блока и размера ключа от стандартных атак с выбранным открытым текстом (CPA) и выбранным зашифрованным текстом (CCA) . Устойчивость к атакам с использованием связанных ключей также была заявлена как цель, хотя и менее важная, поскольку атаки в этой модели не подходят для типичных случаев использования. [16] : 2 Не было предпринято никаких усилий для противодействия атакам в модели атаки с распознаванием известного ключа , и разработчики не оценивали использование Speck в качестве хеш-функции . [3] : 8
По состоянию на 2018 год об успешных атаках на Спека любого варианта не известно. Благодаря интересу к Саймону и Спекам по ним было опубликовано около 70 статей по криптоанализу. [16] : 10 Как это типично для итерированных шифров , варианты с уменьшенным циклом были успешно атакованы. Лучшие опубликованные атаки на Спека в стандартной модели атаки (CPA/CCA с неизвестным ключом) — это атаки дифференциального криптоанализа ; они проходят примерно 70–75% раундов большинства вариантов, хотя эти лучшие атаки лишь незначительно быстрее, чем грубая сила . [1] [2] [16] : 12 Команда разработчиков заявляет, что при разработке Speck они обнаружили, что дифференциальные атаки являются ограничивающими атаками, то есть типом атаки, который проходит наибольшее количество раундов; затем они установили количество раундов, чтобы оставить запас безопасности, аналогичный AES-128 , примерно на 30%. [16] : 12–13
Вариант | Раунды атакованы | Временная сложность | Сложность данных | Пространственная сложность | Тип атаки |
---|---|---|---|---|---|
Спек128/256 | 25/34 (74%) | 2 253.35 | 2 125.35 | 2 22 | дифференциал [1] |
Спек128/192 | 24/33 (73%) | 2 189.35 | 2 125.35 | 2 22 | дифференциал [1] |
Спек128/128 | 23/32 (72%) | 2 125.35 | 2 125.35 | 2 22 | дифференциал [1] |
Спек96/144 | 21/29 (72%) | 2 143.94 | 2 95.94 | 2 22 | дифференциал [1] |
Спек96/96 | 20/28 (71%) | 2 95.94 | 2 95.94 | 2 22 | дифференциал [1] |
Характеристики 64/128 | 20/27 (74%) | 2 125.56 | 2 61.56 | 2 22 | дифференциал [1] |
Спец64/96 | 19/26 (73%) | 2 93.56 | 2 61.56 | 2 22 | дифференциал [1] |
Спек48/96 | 17/23 (74%) | 2 95.8 | 2 47.8 | 2 22 | дифференциал [2] |
Спек48/72 | 16/22 (73%) | 2 71.8 | 2 47.8 | 2 22 | дифференциал [2] |
Спек32/64 | 15/22 (68%) | 2 63.39 | 2 31.39 | 2 22 | дифференциал [2] |
Спек критиковали за слишком маленький запас безопасности, то есть слишком мало раундов между лучшими атаками и полным шифром, по сравнению с более консервативными шифрами, такими как ChaCha20 . [17] Шифры с небольшим запасом безопасности с большей вероятностью будут взломаны будущими достижениями криптоанализа . Команда разработчиков Спека возражает, что неоправданно большие запасы безопасности, особенно на легких устройствах, дорого обходятся в реальной жизни, что криптоанализ на этапе проектирования позволил правильно установить количество раундов и что они нацелены на запас безопасности AES. [16] : 17
Speck включает счетчик раундов в расписание ключей . Разработчики заявляют, что это было включено для блокировки слайдового и ротационного криптоанализа . атак [16] : 16 Тем не менее, криптоанализ с ротационным исключающим ИЛИ использовался для поиска отличий от версий Speck с уменьшенным числом раундов. [18] Хотя авторы не описывают стандартные атаки с восстановлением ключей, основанные на их различителях, их лучшие распознаватели на Speck32 и Speck48 в модели атаки с распознаванием известного ключа для определенных классов слабых ключей проходят немного больше раундов, чем лучшие дифференциальные различители. Один из авторов сказал, что его исследование было ограничено ресурсами и что, вероятно, возможны распознаватели ротационного XOR на большем количестве раундов. [19] Однако этот тип криптоанализа предполагает использование моделей атаки со связанным ключом или даже с известным ключом. [18] которые не являются проблемой в типичных криптографических протоколах и решениях. [20] : 8 Разработчики также заявляют, что Speck не был разработан для защиты от атак с использованием различения известных ключей (которые не ставят под угрозу конфиденциальность шифров напрямую). [3] : 8
Разработчики заявляют, что криптоанализ АНБ обнаружил, что у алгоритмов нет недостатков, а безопасность соответствует длине их ключей. [4] : 2 Команда разработчиков сообщает, что их криптоанализ включал линейный и дифференциальный криптоанализ с использованием стандартных методов, таких как алгоритм Мацуи и решатели SAT/SMT, хотя полный список использованных методов не приводится. [16] : 10 Разработчиков Спека критиковали за то, что они не предоставили более подробную информацию о криптоанализе шифров АНБ. [19]
АНБ одобрило Simon128/256 и Speck128/256 для использования в системах национальной безопасности США, хотя AES-256 по-прежнему рекомендуется для приложений без ограничений. [21]
Атаки по побочным каналам [ править ]
Будучи шифром ARX , Speck не использует S-блоки или другие таблицы поиска; поэтому он естественным образом невосприимчив к атакам с использованием тайминга кэша . [4] : 12 Это контрастирует с шифрами, использующими таблицы поиска, такие как AES , которые, как было показано, уязвимы для таких атак. Однако, как и большинство блочных шифров (включая AES), Speck уязвим для атак анализа мощности , если не приняты аппаратные меры противодействия. [22] [4] : 12
Размеры блоков и ключей [ править ]
Хотя семейство шифров Speck включает варианты с теми же размерами блоков и ключей, что и AES (Speck128/128, Speck128/192 и Speck128/256), оно также включает варианты с размером блока всего 32 бита и размером ключа всего лишь 64 бита. Эти небольшие размеры блоков и ключей небезопасны для общего использования, поскольку они могут допускать атаки «дня рождения» и атаки методом перебора , независимо от формальной безопасности шифра. [23] Разработчики заявляют, что эти размеры блоков и ключей были включены для устройств с очень ограниченными ресурсами, где ничего лучшего невозможно или где когда-либо шифруются только очень небольшие объемы данных, например, в RFID . протоколах [4] : 2–3 Только вариант с размером блока 128 бит и размером ключа 256 бит одобрен для использования в системах национальной безопасности США. [21]
Усилия по и противоречия стандартизации
Первоначальные попытки стандартизировать Саймона и Спека не смогли удовлетворить требования Международной организации по стандартизации, требуемого для этого процесса, и шифры не были приняты. супербольшинства [24] [19] Делегаты-эксперты в ISO из нескольких стран, включая Германию, Японию и Израиль, выступили против усилий АНБ по стандартизации шифров Саймона и Спека, ссылаясь на опасения, что АНБ настаивает на их стандартизации, зная об уязвимых местах в шифрах. Эта позиция была основана на частичных доказательствах слабостей шифров, отсутствии явной необходимости в стандартизации новых шифров и предыдущем участии АНБ в создании и продвижении скрытого криптографического алгоритма Dual_EC_DRBG . [25] [26]
В ответ на обеспокоенность АНБ заявило, что более 70 документов по анализу безопасности, написанных некоторыми ведущими криптографами мира, подтверждают вывод АНБ о том, что алгоритмы безопасны, и АНБ подтвердило, что ему не известно о каких-либо криптоаналитических методах, которые позволили бы им или кому-либо еще эксплуатировать Саймона или Спека [27] [ нужна ссылка ]
После того, как первоначальные попытки стандартизировать шифры потерпели неудачу, ISO стандартизировала Саймона и Спека в других рабочих группах. По состоянию на октябрь 2018 года шифры Саймона и Спека были стандартизированы ISO как часть стандарта радиоинтерфейса RFID, международного стандарта ISO/29167-21 (для Саймона) и международного стандарта ISO/29167-22 (для Спека), что делает они доступны для использования коммерческими организациями. [ нужна ссылка ]
7 августа 2018 г. Speck был полностью удален из ядра Linux 4.20. [15]
7 февраля 2023 года NIST выбрал семейство аутентифицированных шифров Ascon в качестве стандарта облегченной криптографии. [28]
Ссылки [ править ]
- ^ Jump up to: Перейти обратно: а б с д и ж г час я Линг, Сун; Хуан, Чжанцзе; Ян, Цяньцянь (30 июня 2016 г.). «Автоматический дифференциальный анализ блочных шифров ARX с применением к SPECK и LEA» (PDF) . Проверено 06 мая 2018 г.
- ^ Jump up to: Перейти обратно: а б с д и Ли, ХоЧанг; Ким, Соджин; Кан, ХёнЧоль; Хонг, Дыкджо; Сун, Джечоль; Хон, Сохи (февраль 2018 г.). «Вычисление приблизительной вероятности дифференциалов для шифрования на основе ARX с использованием решателя SAT» . Журнал Корейского института информационной безопасности и криптологии (на корейском языке). 28 (1): 15–24. дои : 10.13089/JKIISC.2018.28.1.15 .
- ^ Jump up to: Перейти обратно: а б с д и Болье, Рэй; Шорс, Дуглас; Смит, Джейсон; Тритман-Кларк, Стефан; Уикс, Брайан; Вингерс, Луис (19 июня 2013 г.). «Семейства облегченных блочных шифров SIMON и SPECK» . Проверено 20 сентября 2016 г.
- ^ Jump up to: Перейти обратно: а б с д и Болье, Рэй; Шорс, Дуглас; Смит, Джейсон; Тритман-Кларк, Стефан; Уикс, Брайан; Вингер, Луи (9 июля 2015 г.). «Саймон и Спек: блочные шифры для Интернета вещей» (PDF) . Проверено 23 ноября 2017 г.
- ^ «Заметки по проектированию и анализу Саймона и Спека» (PDF) . eprint.iacr.org . Проверено 26 апреля 2018 г.
- ^ «Re: [PATCH 0/5] криптография: поддержка Speck» . www.mail-archive.com . Проверено 12 апреля 2018 г.
- ^ «СПЕК – Крипто++ Wiki» . www.cryptopp.com . Проверено 12 апреля 2018 г.
- ^ «Бенчмаркинг потоковых шифров ECRYPT» . Проверено 22 июня 2017 г.
- ^ «Криптография Linux — Re: [PATCH v2 0/5] криптография: поддержка Speck» . www.spinics.net . Проверено 6 августа 2018 г.
- ^ «Блочные шифры Саймона и Спека на 8-битных микроконтроллерах AVR» (PDF) . Проверено 25 сентября 2017 г.
- ^ «crypto: speck – добавить поддержку блочного шифра Speck» . 14 февраля 2018 г. Проверено 11 января 2019 г.
- ^ «Алгоритм шифрования АНБ в ядре Linux 4.17 вызывает недовольство пользователей | Это FOSS» . Это ФОСС . 04.08.2018 . Проверено 6 августа 2018 г.
- ^ «Спорный спековский код шифрования действительно будет исключен из ядра Linux – Phoronix» . www.phoronix.com . 04.09.2018 . Проверено 8 декабря 2018 г.
- ^ «Adiantum стоит в очереди перед Linux 4.21 как замена Google Speck» . www.phoronix.com . 29.11.2018 . Проверено 11 января 2019 г.
- ^ Jump up to: Перейти обратно: а б «kernel/git/herbert/cryptodev-2.6.git — разработка API шифрования» . git.kernel.org . Проверено 8 декабря 2018 г.
- ^ Jump up to: Перейти обратно: а б с д и ж г «Заметки по проектированию и анализу Саймона и Спека» (PDF) . 19 января 2018 г. Проверено 13 июня 2018 г.
- ^ Бернштейн, Дэниел Дж. [@hashbreaker] (12 апреля 2016 г.). «АНБ утверждает, что сломать 70% Simon+Speck — это нормально» ( твит ) . Проверено 13 июня 2018 г. - через Twitter .
- ^ Jump up to: Перейти обратно: а б Лю, Юньвэнь; Де Витте, Гленн; Ранея, Адриан; Ашур, Томер (2017). «Вращательный XOR-криптоанализ SPECK с уменьшенным числом раундов» (PDF) . Проверено 13 июня 2018 г.
- ^ Jump up to: Перейти обратно: а б с Ашур, Томер. «[PATCH v2 0/5] крипто: поддержка Speck» .
- ^ Бернштейн, Дэниел Дж. (27 апреля 2015 г.). «Безопасность Salsa20» (PDF) . Проверено 13 июня 2018 г.
- ^ Jump up to: Перейти обратно: а б Агентство национальной безопасности (18 ноября 2016 г.). «Алгоритмы для поддержки эволюции потребностей в обеспечении информации» .
- ^ Гамаараччи, Хасинду; Ганегода, Харша; Рагель, Рошан (20 июля 2017 г.). «Взлом криптосистемы Спека с помощью атаки корреляционного анализа мощности» . Журнал Национального научного фонда Шри-Ланки . 45 (4): 393–404. doi : 10.4038/jnsfsr.v45i4.8233 .
- ^ Бхаргаван, Картикеян; Леран, Гаэтан (2016). О практической (не)безопасности 64-битных блочных шифров: коллизионные атаки на HTTP через TLS и OpenVPN (PDF) . Конференция ACM по компьютерной и коммуникационной безопасности . стр. 456–467. дои : 10.1145/2976749.2978423 .
- ^ Понимание причин, по которым Спек и Саймон были отклонены от стандартизации ISO.
- ^ «Недоверчивые союзники США вынуждают шпионское агентство отступить в борьбе за шифрование» . Рейтер . 21 сентября 2017 г.
- ^ Ашур, Томер; Луйкс, Атул (15 января 2021 г.). «Отчет о стандартизации ISO/IEC семейств блочных шифров Саймона и Спека» . В Авойне Гильдас; Эрнандес-Кастро, Хулио (ред.). Безопасность повсеместных вычислительных систем . Спрингер. стр. 63–78. дои : 10.1007/978-3-030-10591-4_4 . ISBN 978-3-030-10590-7 . S2CID 234119694 .
- ^ Информационный документ Саймона и Спека
- ^ «Процесс стандартизации облегченной криптографии: NIST выбирает Ascon» . nist.gov . Национальный институт стандартов и технологий . Февраль 2023.