The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Утечка документов из АНБ свидетельствует о небезопасности SS..., opennews (?), 29-Дек-14, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


25. "Утечка документов из АНБ свидетельствует о небезопасности SS..."  +2 +/
Сообщение от Аноним (-), 29-Дек-14, 11:20 
AES упоминали?
В свое время были набросы, что и его и другие алгоритмы продавливали.
Якобы Serpent был бы лучше.
Ответить | Правка | Наверх | Cообщить модератору

36. "Утечка документов из АНБ свидетельствует о небезопасности SS..."  –5 +/
Сообщение от Анонимец (?), 29-Дек-14, 12:01 
Серпент же официально признан уязвимым, не?
Ответить | Правка | Наверх | Cообщить модератору

52. "Утечка документов из АНБ свидетельствует о небезопасности SS..."  +4 +/
Сообщение от Аноним (-), 29-Дек-14, 13:55 
Это гдейто он признан? Точно ничего не путаешь, Анонимец?  
Ответить | Правка | Наверх | Cообщить модератору

110. "Утечка документов из АНБ свидетельствует о небезопасности SS..."  +/
Сообщение от Аноним (-), 29-Дек-14, 21:01 
> Серпент же официально признан уязвимым, не?

Кем например? Берштейн что-то не в курсе, хотя тематикой интересуется :).

Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

124. "Утечка документов из АНБ свидетельствует о небезопасности SS..."  +1 +/
Сообщение от Аноним (-), 30-Дек-14, 00:35 
In 2000, a paper by Kohno et al. presents a meet-in-the-middle attack against 6 of 32 rounds of Serpent and an amplified boomerang attack against 9 of 32 rounds in Serpent.[3]

A 2001 attack by Eli Biham, Orr Dunkelman and Nathan Keller presents a linear cryptanalysis attack that breaks 10 of 32 rounds of Serpent-128 with 2118 known plaintexts and 289 time, and 11 rounds of Serpent-192/256 with 2118 known plaintexts and 2187 time.[4]

A 2011 attack by Hongjun Wu, Huaxiong Wang and Phuong Ha Nguyen, also using linear cryptanalysis, breaks 11 rounds of Serpent-128 with 2116 known plaintexts, 2107.5 time and 2104 memory.[1]

The same paper also describes two attacks which break 12 rounds of Serpent-256. The first requires 2118 known plaintexts, 2228.8 time and 2228 memory. The other attack requires 2116 known plaintexts and 2121 memory but also requires 2237.5 time.

Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

136. "Утечка документов из АНБ свидетельствует о небезопасности SS..."  +/
Сообщение от Аноним (-), 30-Дек-14, 12:25 
Как бы это сказать? 12 раундов из 32 - бааааальшой запас прочности.

И кроме того подозреваю что вы перекорежили степени, так что 2187 - это было нечто типа 2^187. А 2^187 что делает данное начинание крайне тухлым. Перебирать что 256 битов, что 187 - почти одинаково тухло, в том плане что вы никогда не переберете ни 2^187, ни 2^256 варантов.

Т.е. в целом атаки выглядят весьма умеренно и не несут никакой практически значимой угрозы. Более того - по другим алгоритмам смотреть еще надо насколько они лучше или хуже: такие атаки находят на практически все алгоритмы. Вот только параметры этих атак очень уж непрактичные. Ну как бы удачи с 2^118 известных шифротекстов :)

Ответить | Правка | Наверх | Cообщить модератору

41. "Утечка документов из АНБ свидетельствует о небезопасности SS..."  +1 +/
Сообщение от YetAnotherOnanym (ok), 29-Дек-14, 12:06 
Двойные и тройные рыбы рулят.
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

107. "Утечка документов из АНБ свидетельствует о небезопасности SS..."  +/
Сообщение от Аноним (-), 29-Дек-14, 20:57 
№    Категория    Serpent    Twofish    MARS    RC6    Rijndael
1    Криптостойкость    +    +    +    +    +
2    Запас криптостойкости    ++    ++    ++    +    +
3    Скорость шифрования при программной реализации    -    ±    ±    +    +
4    Скорость расширения ключа при программной реализации    ±    -    ±    ±    +
5    Смарт-карты с большим объемом ресурсов    +    +    -    ±    ++
6    Смарт-карты с ограниченным объемом ресурсов    ±    +    -    ±    ++
7    Аппаратная реализация (ПЛИС)    +    +    -    ±    +
8    Аппаратная реализация (специализированная микросхема)    +    ±    -    -    +
9    Защита от атак по времени выполнения и потребляемой мощности3    +    ±    -    -    +
10    Защита от атак по потребляемой мощности на процедуру расширения ключа    ±    ±    ±    ±    -
11    Защита от атак по потребляемой мощности на реализации в смарт-картах    ±    +    -    ±    +
12    Возможность расширения ключа «на лету»    +    +    ±    ±    ±
13    Наличие вариантов реализации (без потерь в совместимости)    +    +    ±    ±    +
14    Возможность параллельных вычислений    ±    ±    ±    ±    +
Ответить | Правка | Наверх | Cообщить модератору

112. "Утечка документов из АНБ свидетельствует о небезопасности SS..."  +/
Сообщение от Аноним (-), 29-Дек-14, 21:05 
Ну вот и пропихали rijndael, который основан на довольно старых схемах которые криптографы стараются избегать, подвержен тайминг атакам (с фига ли в таблице плюсик?) и по вашей же таблице имеет ограниченный запас криптостойкости.
Ответить | Правка | Наверх | Cообщить модератору

114. "Утечка документов из АНБ свидетельствует о небезопасности SS..."  +/
Сообщение от Аноним (-), 29-Дек-14, 21:23 
Это с хобота таблица, там неплохой разбор в статье.
Приняли его таки из-за скорости, при том что устойчивость у всех кандидатов тогда считалась одинаково непонятно-высокой.
Ответить | Правка | Наверх | Cообщить модератору

117. "Утечка документов из АНБ свидетельствует о небезопасности SS..."  +/
Сообщение от Аноним (-), 29-Дек-14, 21:38 
> Это с хобота таблица,

1. Хобот большой. Я что, должен его весь перерывать в поисках источника? А ссылку догадаться кинуть вместо (или вместе с) копипасты - не того?
2. Квалификация хобота в технических вопросах в последнее время очень так себе. В вопросах криптографии я их считать экспертами не вижу смысла вообще.
3. Если эта таблица исходит от NIST, что от них ожидать - давно показал их недавно стандартизированный ГПСЧ, который они со скандалом отозвали. Ну а какие гарантии что остальное они стандартизировали лучше?

> там неплохой разбор в статье.

Я видел более интересный разбор и мысленный эксперимент, возможно дающий объяснение "почему оно так". От профессионала в области - DJB. http://www.opennet.ru/opennews/art.shtml?num=40877

> Приняли его таки из-за скорости,

...а потом DJB ненавязчиво намекнул нам что там тайминг атаки. А serpent без таковых и с более перспективной схемой - почему-то вот не стандартизировали.

Ответить | Правка | Наверх | Cообщить модератору
Часть нити удалена модератором

137. "Утечка документов из АНБ свидетельствует о небезопасности SS..."  +1 +/
Сообщение от Аноним (-), 30-Дек-14, 12:31 
> 1. Забанен в гугле?

А оно мне надо - искать непойми что от непойми кого?

> 2. Квалификация конкретного автора вполне ок для обзорной статьи.

И откуда следует этот вывод?

> Тайминг атаки при желании можно нейтрализовать при аппаратной реализации.

Однако в случае AES - NIST почему-то завирал что лукап таблицы якобы постоянная по времени операция. Хотя на современных процессорах с кэшом - это отнюдь не так. По поводу чего похоже на некую подтасовку фактов. Или в лучшем случае на некомпетентность. С учетом поимки на стандартизации пробэкдореного ГПСЧ, я на всякий случай буду считать что NIST втирает очки и не буду особо доверять их стандартам.

> Однако тогда и соображения по поводу скорости как критерия выбора
> не выдерживают никакой критики.

Ну как бы в идеале всем хотелось бы чтобы работало быстро. К сожалению, это клещится с другим требованием - качественной диффузией. Чем больше раундов - тем лучше диффузия и выше запас прочности. Но тем ниже скорость. Если уж на то пошло, у DJB есть довольно резвые Salsa/ChaCha которые и шустрые и диффузия хорошая и на полные варианты вроде особо крутых атак никто не нашел..

Ответить | Правка | К родителю #200 | Наверх | Cообщить модератору

140. "Утечка документов из АНБ свидетельствует о небезопасности SS..."  +/
Сообщение от Аноним (-), 30-Дек-14, 13:12 
>> Однако тогда и соображения по поводу скорости как критерия выбора
>> не выдерживают никакой критики.
> Ну как бы в идеале всем хотелось бы чтобы работало быстро.

В идеале оно должно работать одинаково быстро. Для любых исходных данных, для любых ключей.
Т.е. аппаратно сделать раунд квантом времени в черном ящике;


>  завирал что лукап таблицы якобы постоянная по времени операция. Хотя на современных процессорах с кэшом - это отнюдь не так.

если нужен кеш, то пусть будет отдельный свой, внутри черного ящика, без доступа.

> Если уж на то пошло, у DJB есть довольно резвые Salsa/ChaCha которые и шустрые и диффузия хорошая и на полные варианты вроде особо крутых атак никто не нашел..

Гугло уже использует вроде.

Ответить | Правка | Наверх | Cообщить модератору

153. "Утечка документов из АНБ свидетельствует о небезопасности SS..."  +1 +/
Сообщение от Аноним (-), 30-Дек-14, 21:47 
> В идеале оно должно работать одинаково быстро. Для любых исходных данных, для
> любых ключей.

Ну так нормально сделанные алгоритмы - отрабатывают за фиксированное время. Даже в софте. Потому что не используют лукап по таблицам. Смотреть например на Salsa и ChaCha от Бернштейна и его команды - только математические операции регистр-регистр, никаких таблиц. Вполне себе может работать за фиксированное время: операции регистр-регистр не зависят от cache hit/cache miss и свойств входных данных и ключа.

> Т.е. аппаратно сделать раунд квантом времени в черном ящике;

А в том что черный ящик работает честно - мы поверим на слово, да? Так не пойдет. Я предпочту софтварный алгоритм сделанный компетентными людьми, который можно проверить, чем какой-то черный ящик где неизвестно кто сделал неизвестно что и предлагается поверить ему на слово. Да, это касается и интела с их AES.

> если нужен кеш, то пусть будет отдельный свой, внутри черного ящика, без доступа.

Для начала я не вижу никаких оснований доверять черным ящикам.

> Гугло уже использует вроде.

На самом деле их уже довольно много кто использует. Хоть это и не стандарты. И не ускоряется железом. А любители стандартов могут идти пользоваться DESом и нистовским генератором ПСЧ, чего уж там.

Ответить | Правка | Наверх | Cообщить модератору

157. "Утечка документов из АНБ свидетельствует о небезопасности SS..."  –1 +/
Сообщение от Аноним (-), 30-Дек-14, 22:31 
> Ну так нормально сделанные алгоритмы - отрабатывают за фиксированное время. Даже в софте.

Я не спорю. Но поскольку принятое стандартом реализуется на уровне инструкций, следовательно даже то, что софтом реализуется за разное время, на уровне команд проца можно сделать за фиксированное число тактов.
AES-NI уже в большинстве новых процов.

> А в том что черный ящик работает честно - мы поверим на слово, да?

А в том, что процессор работает честно?
Да, я в курсе базовых вещей, про открытость. Но открытый алгоритм таки реализуется в железе.
Миллионными тиражами.

> Я предпочту софтварный алгоритм сделанный компетентными людьми, который можно проверить, чем какой-то черный ящик где неизвестно кто сделал неизвестно что и предлагается поверить ему на слово. Да, это касается и интела с их AES.

В чем там проблема? - дополнительные дыры изобрели?

> На самом деле их уже довольно много кто использует. Хоть это и не стандарты. И не ускоряется железом.

Вполне может быть что скоро будет ускоряться. Крупные конторы уже какое-то время рассматривают возможность (а то и проектируют) железа под себя. ARM дешев, можно заодно кучу всего всобачить в кристалл.

Ответить | Правка | Наверх | Cообщить модератору

192. "Утечка документов из АНБ свидетельствует о небезопасности SS..."  +/
Сообщение от Аноним (-), 06-Янв-15, 14:35 
> AES-NI уже в большинстве новых процов.

Поскольку компьютерные системы состоят не только из новых процов и не только из интеловских процов - этому "достижению" грош цена в базарный день. Тем более что интеловское добро без огромного блоба биоса а то и UEFI на 5 мегов с целой псевдооперационкой - не запускается. Плюс пара фирмварин сервисных сопроцов. Без сорцов, зато с доступом в сеть (AMT/vPro же). При том этот сопроцык - штатная фича в большинстве новых интеловских чипсетов. А то что он пишет что disabled в bios setup - это гон, потому что этот процык питаемый от дежурки еще рулит вентиляторами и прочая, так что то что он disabled - мы его немеряной фирмваре (которая работать при этом не прекращает, иначе у вас вентили в системе встанут) поверим на слово. А потом анбисты немного так пойдут и сдампят ключи AES. По сети. Мало ли, вдруг проц их прихранил, например?

> А в том, что процессор работает честно?

Здесь мы знакомимся с Тюрингом, который сказал что одна программа не может проанализировать другую произвольную программу и вынести вердикт. Но в случае AES мы явно сигналим порцу что это - именно шифрование, по вполне конкретному алгорирму. Это сильно упрощает дело. Как по мне - такое нахрапистое продвижение далеко не лучшего алгоритма, с засовыванием в железо и киванием на стандартность - выглядит в высшей степени подозрительно. И со своей стороны я лучше буду доверять софтварной реализации алгоритма от, допустим, DJB (который может обосновать что и почему он сделал в понятном мне формате) чем какому-то мутному черному ящику, реализующий алгоритм выбранный NIST'ом, которые известны тем что стандартизировали и заведомо несекурный DES, и пробэкдоренный Dual EC DRBG. А в случае AES я должен им наверное после таких фокусов на слово верить что все честно и в стандарте и в черном ящике от интеля. Размечтались то.

> реализуется в железе.
> Миллионными тиражами.

После чего утрачивается возможность проверить что это - именно тот алгоритм, и что он делает только то что заявлено, не откалывая побочных нежелательных действий. И мы явно информируем проц о том что это именно шифрование по вон тому алгоритму. А не что-нибудь еще. А оно мне такое надо? Вот вы миллионами и кушайте гуано, если в гумно вляпаться охота лишний раз. А у меня нет оснований доверять ни NIST, несколько раз жирно дискредитировавшим себя, ни интелу с их черными ящиками.

> В чем там проблема? - дополнительные дыры изобрели?

Хотя-бы в том что алгоритм реализуемый в черном ящике невозмжно валидировать вообще. И идея явно информировать проц о том что мы сейчас именно шифрование будем фигарить, а не что-нибудь еще - мне что-то совсем не нравится.

> Вполне может быть что скоро будет ускоряться. Крупные конторы уже какое-то время
> рассматривают возможность (а то и проектируют) железа под себя. ARM дешев,
> можно заодно кучу всего всобачить в кристалл.

Пусть себе ускоряют. А я предпочту софтварную реализацию которая поддается валидации. Проверять на своих чувствительных данных что там впихали в черный ящик лично мне лишний раз не хочется.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру