Pull to refresh

Comments 24

Умножение на полином — чтобы все последующие значения tweak value были различными и не было линейной зависимости между ними. Полином — грубо говоря аналог простого числа, модуль группы 128-битных чисел.
А минимальное количество единичных бит в нем (и то что они находятся в младшем байте) позволяет более эффективно производить умножение по модулю полинома.
Это для саморазвития?
Или TrueCrypt чем-то не угодил?
1) «XTS-AES… считается самым безопасным способом хранить данные посекторно»
Откуда такая оценка? Кем считается и на основании чего.

2) «Вопрос к математически подкованной аудитории: Почему выбрано именно умножение на полином в GF(2) по модулю x128+x7+x2+x+1?»
Это порождающий полином (reduction polynomial) для поля Галуа длиной 128 бит — GF(2^128). Порождающий позволяет ввести для поля операцию умножения и деления, а также перебирать все элементы поля (кроме 0) путём многократного умножения первичного элемента на этот полином. Обычно выбирается трёхчлен (минимальный порождающий), но тут пятичлен.
>Откуда такая оценка? Кем считается и на основании чего
CBC не подходит, т.к. там одно зависит от другого, в LRW нашли дыру, XEX не позволяет работать с блоками, не кратными размеру блока шифра, в CMC/EME каждый блок нужно шифровать дважды.
Считается лучшим разработчиками утилит для шифрования дисков как не имеющий нормальных альтернатив.
Ну а CTR?
en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Counter_.28CTR.29
Брюс Шнайер с коллегами в «Практической криптографии» и «Cryptography Engeneering» рекомендуют CTR или CBC с random IV. CBC для по секторного не подходит, это понятно.

Есть ли работы по криптоанализу XTS-AES? Разработчиками обычно создаются шифры, которые только они не могут сломать.
counter mode turns a block cipher into a stream cipher. Не вижу тут применимости для посекторного шифрования. XTS, в частности, был специально разработан для этой цели. Ну а насчет анализа, думаю стоит начать с чтения стандарта. Вряд ли бы он туда попал, не будь он широко исследован.
WEP тоже был специально разработан для своей цели и попал в стандарт. Однако через пару лет его сломали.
Стандарты зачастую принимают люди очень слабо разбирающиеся в безопасности — менеджеры, лоббисты, юристы. Посмотрите главу «Процесс стандартизации» в «Практической криптографии» (она же «The Standards Process» в «Cryptography Engeneering»), думаю, у вас поуменьшится доверия к просто стандартизированным алгоритмам.
Спасибо, конечно, за мнение, но мне бы всё таки хотелось узнать как вы собираетесь использовать поточный шифр, коим является любой блочный в режиме CTR, для шифрования диска посекторно.
Так в том то и дело, что получается не просто потоковый шифр, а шифрование дающее random access к данным.
Ваши входные данные:
1) Ключ K
2) Адрес (номер) сектора — X
3) Блок данных длины L байт (кратной 128 битам — размер блока AES)
Начальное значение Counter для шифрования блока считаем через номер сектора:
Counter = L * X / 16
В этом случае у вас весь диск получается шифрован как единое целое, но вы можете в любой момент расшифровать любой блок отдельно. Даже любой байт можно расшифровать отдельно.
Да, виноват, не до конца вник в суть CTR. Рэндомно читать оно даёт. Но зато (там же)
Nevertheless, there are specialized attacks like a Hardware Fault Attack that is based on the usage of a simple counter function as input.
Вобщем, видимо есть причины по которым девелоперы используют именно XTS. Тот же recommendation, о котором написано ниже
А как же золотое правило использования потоковых шифров — запрет на переиспользование гаммы?

«Securely using a secure synchronous stream cipher requires that one never reuse the same keystream twice»

Если в один и тот же блоке, зашифрованным CTR, в два момента времени хранились разные данные, то сервис хранения файлов может получить xor от ваших данных. Особенно приятно будет, если изначально в контейнере хранились нули, а потом в те же блоки были записаны данные.

Так что CTR не подходит для изменяемых файлов и требует использования уникальных nonce (IV) для разных файлов
Спасиба, дорогой. Приятно, что на хабребабре есть люди, еще могущие в нужный момент предоставить нужную инфу )
Правильно.
CTR не даёт защиты в случае если у вас шифротекст украли два раза. А даёт ли защиту XTS от этого? Без реальных работ по криптоанализу этого нельзя утверждать.
Ниже привёл ссылку на комментарии Neils Ferguson об XTS (это соавтор Шнайера по «Практической криптографии»).
Меня доставляют товарищи прочитавшие Шнайера в полглаза и пытающиеся учить других даже не попытавшись включить мозги.
CTR это потоковый режим, но не просто не рекомендован, а люто, бешено, категорически противопоказан к применению на изменяемых данных, и еще более противопоказан для дискового шифрования. Допустим изначально на диске хранились нули (а обычно так и есть), атакующий снимает дамп чистого диска, ждет пока жертва заполнит его данными, снимает второй дамп, ксорит два дампа и оляля — всё шифрование полностью взломано. Вот что бывает когда программист думает не головой, а запомнившимися отрывками из Шнайера.

> А даёт ли защиту XTS от этого? Без реальных работ по криптоанализу этого нельзя утверждать.
Дает, уж поверьте мне. Я могу вам на пальцах доказать, что режим XTS по крайней мене не хуже ECB, и данном применении 100% лучше CTR. Но сначала попробуйте включить мозги и догадаться сами.
Я написал, что «CTR не даёт защиты в случае если у вас шифротекст украли два раза», не обязательно мне это повторять своими словами.

Я устроил небольшую провокацию автору статьи, предложив метод, являющийся рекомендованным для некоторых применений, но уязвимым для данного случая. Автор показал, что он не знает про режим CTR, не видел статей по криптоанализу ни CTR, ни XTS, но при этом легко пишет в статье «считается самым безопасным способом хранить данные посекторно» лишь на основании рекомендации одного стандарта. Вам не кажется такой способ мышления неосторожным?

XTS выглядит, как будто он лучше ECB и CTR. Реально ли он лучше или нет для посекторного шифрования — оценить можно только после интенсивного анализа разными специалистами. Всё что мы видим сейчас — стандарт, принятый не смотря на развёрнутую критику разбирающихся товарищей, которую NIST не мог не видеть, раз разместил на своём сайте.
Реально для посекторного шифрования нет ничего более подходящего. Все режимы используемые при шифровании неизменяемых данных уязвимы к тем или иным атакам (ватермаркинг и.т.п.) и CTR это худший случай. LRW уязвим, им нельзя шифровать его собственные ключи, XEX упрощенный вариант XTS который точно не лучше, CMC, EME и CBC-ESSIV требуют двойного шифрования. Получается ничего лучше нет, а шифровать диски чем-то надо.
Лучше/хуже — субъективная оценка, когда вы сравниваете и по производительности, и по возможным атакам.
Я вот считаю, что лучше исследованный режим с двумя шифрованиями, чем плохо исследованная новинка с одним.
On January 27, 2010, NIST Computer Security Division released Special Publication (SP) 800-38E in final form. SP 800-38E is a recommendation for the XTS-AES mode of operation for cryptographic modules… According to SP 800-38E, «In the absence of authentication or access control, XTS-AES provides more protection than the other approved confidentiality-only modes against unauthorized manipulation of the encrypted data.»

csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf
И ни одной ссылки на криптоанализ данного режима шифрования.

Зато нагуглилось вот такое:
csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/XTS/collected_XTS_comments.pdf
Смотрим комментарии Vijay Bharadwaj and Neils Ferguson
1) «does not contain a clear statement of what application-level security goals XTS aims to achieve»
2) «proposal lacks the margin of safety that would be expected of a mode which is to be used for 20-30 years»
3) «In general, the attacker can perform a number of manipulations to the ciphertext in order to influence the decrypted plaintext»
4) «This shows that large data units significantly weaken the system. The standard should not allow data units larger than the recommended 2^20 blocks.» (16 мегабайт)
Хорошее предложение, если выхожите в опен сорс, то даже поучавствовать охото.
Есть одно замечание: новые процессоры (интела по крайней мере) имеют новую инструкцию AES-NI. И только взглянув на эту картинку становится понятно, что её надо использовать:
image
Это мы в курсе. Либу ток надо найти нормальную )
Рекомендую либу crypto_fast из исходников последней беты DiskCryptor, ничего быстрее вы не найдете, я гарантирую это.

image
Сегодня приснилось что этот комментарий с картинкой собирает -165 :)
Sign up to leave a comment.

Articles