— SATtva (13/02/2011 10:50, исправлен 13/02/2011 10:50)   

RC4 не взломан, но его применение сопряжено с определёнными нюансами, несоблюдение которые способно привести к взлому. Алгоритм вкупе с этим режимом применения назван ARC4. Как видно по скриншоту, он и используется в TLS.

— unknown (13/02/2011 18:58, исправлен 13/02/2011 18:59)   

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

С помощью ряда нюансовкостылей от этих атак можно защититься (хэширование вектора инициализации и ключа, отбрасывание начального участка гаммы), но строго говоря он не может больше считаться криптостойким. Из текущих стандартов его рекомендовано выводить и в новых системах не использовать.

— Гость (13/02/2011 19:10)   
Стоп, в википедии написано, что RC4 и ARC4 – это одно и то же. Или это разные шифры?

Алсо почему бы его совсем не запретить, если он уже сыпаться начал?

— unknown (13/02/2011 20:11)   
А почему бы совсем не запретить SHA-1 ?

вот пройдёт конкурс SHA-3, тогда и SHA-1 и SHA-2 станут не нужны. Если победит один из двух универсальных криптомитивов (Keccak или Skein), то возможно и на ситуацию с потоковыми шифрами он также повлияет, как и на пересмотр множества других криптостандартов.

Прошедший конкурс потоковых шифров e-Stream особых результатов не дал или не оказался замечен и RC4 не исключили из стандартов. ARC4 — приставка "A" — как альтернативная реализация имеющему неопределённый патентный статус RC4.

— Гость (14/02/2011 00:13)   
То есть RC4 и ARC4 не одно и то же и википедия http://ru.wikipedia.org/wiki/RC4 не права?

Матапушта он еще практически не взломан. MD5 уже убирают отовсюду, откуда можно.

А почему надо обязательно использовать потоковый шифр? Есть же AES.

— unknown (14/02/2011 01:09, исправлен 14/02/2011 01:13)   

RuWiki на данный момент права. Там этот исторический казус отражён. RC4 является коммерческой собственностью компании RSA security. Но они его не запатентовали открыто, а держали в секрете. Когда код был восстановлен реверс-инженерингом и получено подтверждение о его идентичности от независимых источников, то его приняли как RC4. Но затем переименовали в ARC4, чтобы избежать возможных судебных претензий. Плюс официально RSA security не заявляла о том, что это именно тот алгоритм. Но все-то знают ...

Есть ещё ARC4-DROP — вариант с отбрасыванием начального потока гаммы. Были предприняты и множественные попытки усовершенствования алгоритма. Успеха достигнуто не было.

А почему надо обязательно использовать потоковый шифр? Есть же AES.

Когда-то RC4 был, а AES не было. Затем привлекала ещё большая простота, скорость и в некоторых местах меньщая ресурсоёмкость по сравнению с AES. Теперь это неактуально. Проще использовать AES в потоковом режиме с аутентификацией. ARC4 действительно не нужен.

— Гость (14/02/2011 19:10)   
То есть можно написать админу письмо и попросить перейти на AES? Надо ли запрещать другие шифры, кроме AES, чтобы через митм нельзя было на них откатиться?

— sentaus (14/02/2011 21:45)   

Надо ли запрещать другие шифры, кроме AES, чтобы через митм нельзя было на них откатиться?

Что значит запрещать? Отключать на клиентской стороне?

— Гость (14/02/2011 21:59)   
На стороне сервера, раз речь про админа.

— unknown (14/02/2011 22:03, исправлен 14/02/2011 22:06)   

Желательно. Не содержащие AES режимы актуальны для совместимости с какими-нибудь старыми программами (что там внутри всяких "клиент-банков"?), смарт-картами, встраиваемыми устройствами и т.д., но не для веб-серверов и браузеров с обычных операционных систем нормальной версии openssl-lib.

Хотя ещё лет пять назад в особо стабильных дистрибутивах Линукса была версия openssl без нормальной поддержки AES.

— Гость (14/02/2011 22:10)   
Ради интереса в красной дырке запретил ARC4 – страница не открывается вообще, причем сообщение об ошибке ни о чем не говорит. Я думал, они другие протоколы согласуют.
А как с производительностью сабжей?

Не удаётся завершить защищённую транзакцию

Вы попытались получить доступ к адресу xxxxxxxx, который сейчас недоступен. Убедитесь, что веб-адрес (URL) введен правильно, и попытайтесь перезагрузить страницу.
Убедитесь, что соединение с Интернет активно, и проверьте, работают ли другие приложения, использующие это соединение.
Проверьте правильность настроек программного обеспечения безопасности Интернета и убедитесь, что данные программы не блокируют использование браузера.
Если компьютер защищен межсетевым экраном локальной вычислительной сети и его использование может быть источником проблем, обратитесь к вашему системному администратору.
Нажмите клавишу F12 на клавиатуре и отключите прокси-серверы, если только вам не нужен прокси-сервер для подключения к Интернету. Загрузите страницу еще раз.

— unknown (14/02/2011 22:29)   

RC4 примерно в два раза быстрее AES, но с включением AES в аппаратную поддержку Intel-процессоров на таких серверах не должно быть никаких проблем — AES таким нечестным способом далеко обгоняет всех по производительности. Кроме того AES занимает меньше памяти, параллелится (вероятно актуально при обработке миллионов параллельных запросов).

— Гость (19/02/2011 17:46)   
Написал письмо админу, думал, положат болт, как обычно, на мои репорты, но вот захожу, решил посмотреть шифрование – а там AES-256. Захожу в почту – получил ответ: спасибо за репорт, RC4 остался с времен, когда еще не все браузеры нормально работали с нормальным шифрованием. Мелочь, а приятно.

— Гость (19/02/2011 17:49)   
Теперь там
Зачем ставить в 2 раза меньшую длину ключа для открытого ключа – хз, хотя 1024 еще вроде бы безопасно.

— Гость (19/02/2011 21:24)   
Возможно, дело в нагрузке на сервер. По этой же причине, насколько я помню (и если ничего не путаю), и в Tor'е 1024-ключи.

— Гость (20/02/2011 20:41)   
Так 2048 стоял же и нормально.

— Гость (21/02/2011 12:55)   

SATtva:
RC4 не взломан

unknown:
он взломан не только в ряде теоретических, но и практических вариантов

Гость:
он еще практически не взломан

А не создать ли в FAQ список взломанных и не взломанных?

— unknown (21/02/2011 13:33)   
У нас нет такого раздела в FAQ.

В разделе FAQ по общим вопросам криптографии даны только самые общие понятия, что такое криптоалгоритмы (без примеров), по каким принципам их проектируют, как ведут исследования, как применяют.

В "криптоконтейнерах и защите диска" потоковый (A)RC4 не может встретиться, в разделах, связанных с OpenPGP тоже.

Работа с SSL не освещается, т.к. сама модель централизованной выдачи заверений для сертификатов неинтересна и ущербна, о чём есть статья в библиотеке.

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

В FAQ подошла бы рекомендация вида: в большинстве нормальных программ выбор криптоалгоритмов по-умолчанию — самый оптимальный и если сомневаетесь, то и не трогайте там в настройках ничего лишнего. Если кто-то использует устаревшую версию программы, не обновляет предлагаемые алгоритмы и режимы на новые рекомендуемые (по умолчанию) — ССЗБ.

— Гость (22/02/2011 21:44)   

А не создать ли в FAQ список взломанных и не взломанных?

По крайней мере в английской педивикии для взломаных алгоритмы есть раздел Security, где описаны проблемы.

— unknown (22/02/2011 22:52)   
У RC4 — особый статус. У него много проблем (начиная от нахождения статистических различитилей), но его не доламывают. вероятно из-за снижения интереса исследователей и уменьшения областей использования.

В часто обсуждаемых программах на сайте он может встретиться в специфических случаях, вроде того же SSL.

М.б. в FAQ следует включить вопрос об инфраструктуре открытых ключей и принципах https с учётом критики Р. Андерсона, Б. Шнайера и Согояна со Стэмом.

— Гость (27/02/2011 04:24)   
ПЦ, и гугл тут

— Гость (20/03/2011 19:33)   
Отключите в настройках браузера ARC, и будет у вас коннект с гуглом с AES.

— Гость (20/03/2011 19:33)   
Кстати, сервер этого сайта, как мне говорит браузер, не поддерживает Safe Renegotiation.

— SATtva (21/03/2011 12:21)   
Пересогласование параметров полностью отключено на сервере. Уязвимости, связанные с отсутствием поддержки расширений RFC 5746, в данном случае неприменимы.

— Гость (27/03/2011 07:26)   

— Гость (20/03/2011 19:33) <#>

Отключите в настройках браузера ARC, и будет у вас коннект с гуглом с AES.

Пробовал на другом сайте, получил болт.

SATtva, я уже писал в другой теме, из-за этого красная буква О мне замочек не показывает? Не проще ли обновиться?

— SATtva (27/03/2011 08:23)   
А не проще перейти на такой браузер, который не выдаёт ложную тревогу? Я Вам тогда ответил: обновление серверного ПО не в моих полномочиях. Прошу не продолжать эту дискуссию, тем более, что оффтопик.

— Гость (27/03/2011 18:06)   

ложную ли?

Хм.. смена хостинга на вменяемый в ваших? Какой-то у вас хостер кран.

— SATtva (27/03/2011 18:10)   

/comment45413^[link2]

— Гость (27/03/2011 20:19)   
Модеры, может хватит коменты тереть?

— Гость (27/03/2011 23:25)   

Замочек вам не показывают, скорее всего, потому, что у вас не установлен корневой сертификат cacert.org, выдавшего сертификат этому сайту.

— Гость (28/03/2011 00:52)   
Замочек должен быть по идее появиться после того, как я добавил серт сайта в исключения.

Но продолжать дискуссию, когда просто трутся посты, я не настроен. Гнийте дальше.

— Гость (28/03/2011 18:32)   
Здесь ничто не пропадает бесследно^[link3].

— Гость (28/03/2011 19:57)   
Троллинг – это модное слово, которое употребляют когда хотят, в том числе когда руки из жопы растут?

— Гость (29/03/2011 02:15)   
Мне кажется, что необходимо в любом случае обновить сервер (даже если уязвимости нет) — хотя бы для того, чтобы у пользователя не появлялось предупреждения об уязвимости. Потому что когда посетитель заходит на сайт, посвящённый информационной безопасности и видит предупреждение о дыре в безопасности, это ни в какие ворота.

— Гость (29/03/2011 03:33)   
Это не форум вебдевелоперов :) Говорить о безопасности сайта с учётом всего того, что известно про SSL как-то не приходится. Там, где реально нужна надёжная аутентификация, пробрасываются IPSec/OpenVPN/OpenSSH-туннели с беспарольной аутентификацией по ключу. В тех местах сайта, где это может оказаться нужным, ещё прикручены PGP-подписи. SSL здесь не более, чем рюшечка "по умолчанию".
И да, никто не будет менять хостинг из-за того, что у вас браузер на что-то там ругается, ну как бы наивно с такими просьбами обращаться — слишком несущественная причина для.

— Гость (29/03/2011 05:55)   

Мне кажется, что необходимо в любом случае обновить сервер (даже если уязвимости нет) — хотя бы для того, чтобы у пользователя не появлялось предупреждения об уязвимости. Потому что когда посетитель заходит на сайт, посвящённый информационной безопасности и видит предупреждение о дыре в безопасности, это ни в какие ворота.

Как бы да. Безопасность-паранойя, а собственный сайт залатать не в состоянии.

Говорить о безопасности сайта с учётом всего того, что известно про SSL как-то не приходится.

А что о нем известно? Просвятишь? Ты не путаешь случайно SSL и проблемы дизайна PKI?

браузер на что-то там ругается

Браузер ругается не много не мало на непоставленное критическое обновление безопасности. Актуально ли оно для данного сайта – вопрос четвертый.

— SATtva (29/03/2011 10:35)   

Актуально ли оно для данного сайта – вопрос четвертый.

Очень интересно. А может браузер прежде, чем стращать юзера, должен всё-таки удостовериться, что сайт поддерживает пересогласование, как таковое (т.е. попытаться пересогласовать параметры)?

Мне кажется, что необходимо в любом случае обновить сервер (даже если уязвимости нет) — хотя бы для того, чтобы у пользователя не появлялось предупреждения об уязвимости.

Мне кажется, что необходимо в любом случае обновить браузер — хотя бы для того, чтобы у пользователя не появлялось предупреждения об уязвимости.

Все доводы высказаны. Продолжение дискуссии будет расцениваться как унылый троллинг.

— Гость (02/04/2011 12:24)   
Способ использования RC4 в SSL не опасен с точки зрения практических атак. Если вы думаете, что сможете тривиально расшифровать перехваченные пакеты, зашифрованные им, вас ждёт разочаровние.

— Гость (13/03/2013 02:14)   

Если вы думаете, что сможете тривиально расшифровать перехваченные пакеты, зашифрованные им, вас ждёт разочаровние.

Несколько проще^[link4], чем в теории. Время твикать настройки браузера, атаку могут оптимизировать быстрей ваш любимый веб-сервис сменит шифр.

— unknown (13/03/2013 10:20)   
Слайды^[link5] удивляют.

Только сейчас, спустя почти 25 лет догадались полностью составить тривиальные 256 таблиц распределения выхода байтов для RC4? С подобных таблиц начинается дизайн составных частей любого шифра, даже не доказательство его стойкости. Это работа уровня лабораторных заданий для студентов. По результатам которой шифр должен был быть сразу же забракован ещё в восьмидесятые годы.

Правильно написано, что всех надо переводить на Keccak или аналоги. То, как безграмотно используют даже стойкие шифры в нынешних криптопродуктах в виде каши из криптопримитивов, неизбежное последствие существующих стандартов.

Правильно и отмечено, что нужны шифры с большим размером блока. Не отмечено почему-то, что в перспективе нужен блочный шифр, как универсальная перестановка с опционально любым размером блока и ключа (хотя бы кратно меняющимся 8-ми битам).

— sentaus (13/03/2013 11:01)   

Только сейчас, спустя почти 25 лет догадались полностью составить тривиальные 256 таблиц распределения выхода байтов для RC4?

В MSCHAPv2 эквивалентность двум одинарным DES тоже заметили спустя только лет 15. Интересно, сколько ещё такого всего незамеченного.

— Гость (19/03/2013 07:40)   
unknown, ээ, какие 256? Там надо хотя бы 2^24, а для гарантированного успеха – 2^30 зашифрованых сообщений. Это еще не капец, но уже звоночек.

— unknown (19/03/2013 09:52)   
Всё правильно, на основании данных 256 таблиц распределения можно вывести результат по крайней мере для 2²⁴ — 2³⁰ известных открытых текстов. Также как на основании всего одного или нескольких дифференциалов или линейных характеристик можно взломать некий алгоритм за 2ⁿ шагов, где 2ⁿ — очень большое число, выводимое из количества исходных дефектов по достаточно сложной формуле.

Для тех, кто совсем не понял: одно связано с другим, но это разные вещи. Таблицы распределения — аналог элементарного статтеста для каждого байта, по которому уже даже визуально видна дефектность алгоритма.

— Гость (19/03/2013 13:19)   

И после этого все сразу же все поняли.

— Гость (19/03/2013 13:25)   
Если и после не поняли, то медицина бессильна.

— Гость (20/03/2013 13:57)   
Гость (19/03/2013 13:25) а ты понял? Может, обьяснишь?

— Гость (20/03/2013 23:00)   

Гость (19/03/2013 13:25) а ты понял? Может, обьяснишь?

По всей видимости, Гость (19/03/2013 13:25) как бы хочет нам сказать «надо как можно скорее отказываться от использования RC4, а те, кто продолжают им пользоваться, ССЗБ».

— sentaus (21/03/2013 00:06)   

По всей видимости, Гость (19/03/2013 13:25) как бы хочет нам сказать «надо как можно скорее отказываться от использования RC4, а те, кто продолжают им пользоваться, ССЗБ».

А с SSL сейчас вообще беда и огорчение. RC4 без пяти минут взломан, а механизм использования блочных шифров к padding oracle атакам уязвим. Тут нужен как минимум какой-нибудь новый TLS 1.3, в которому будет другой padding или лучше возможность выбора padding в качестве параметра. Только когда всё это будет, если даже не все ещё TLS 1.1 внедрили?

— Гость (21/03/2013 09:29)   
Beast вроде как пофикшен^[link6]

Также есть костылик^[link7], который рандомизирует положение кук или вообще убирает их из первых 256 байтов. Запрашиваемый адрес по-прежнему под ударом.

— Гость (21/03/2013 09:30)   
Вообще, кто-то может перевести то, что ункноун написал^[link8]?

— unknown (21/03/2013 09:52)   
Beast не действует против RC4, а только против определённых способов использвания блочных шифров в режиме CBC.


Что взглянув на 256 графиков из слайдов Бернштейна и Ко надо сразу ужаснуться, независимо от того, к какому числу реальных шагов атаки приводит такой очевидный дефект шифра. Ну т.е. — это такой шок-контент для криптографов.

— sentaus (21/03/2013 13:19)   

Beast вроде как пофикшен

К beast да, костыль прикрутили. А что с Lucky13 делать?

— Гость (21/03/2013 13:34)   

Я перевести просил. На русский.

А что с ним?

— sentaus (21/03/2013 15:11)   

А что с ним?

http://arstechnica.com/securit.....d-by-ssl-encryption/^[link9]

It took the scientists as little 2^23 sessions to extract the entire contents of a TLS-encrypted authentication cookie. They were able to improve their results when they knew details of a the ciphertext they were trying to decrypt. Cookies formatted in base 64 encoding, for example, could be extracted in 2^19 TLS sessions. The researchers required 2^13 sessions when a byte of plaintext in one of the last two positions in a block was already known.

Уязвим даже TLS 1.2

— unknown (21/03/2013 15:25, исправлен 21/03/2013 15:27)   

На графиках ясно виден тривиальный статистический различитель. Да ещё и побайтовый.

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

Обратное неверно: графики могут быть идеальными, а шифр легковзламываемый. Но когда такие элементарные графики показывают плохие показатели — это, соответственно, совсем плохо.

— Гость (21/03/2013 18:27)   

Уязвим даже TLS 1.2

о_О а эта атака вообще реалистична?

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

— sentaus (21/03/2013 18:48, исправлен 21/03/2013 23:57)   

о_О а эта атака вообще реалистична?

Не сказать, что столь же практична, как beast, но 2^23 сессий в тяжелейшем случае – это даже меньше, чем нужно для атаки на RC4 сейчас. В общем, всё на грани. Криптографы-теоретики хватаются за сердце, остальным явно плевать.

Upd: А я как-то упустил, что в tls 1.2 Galois/Counter ещё появился – можно и с ним жить. Надо только дождаться, пока рак на горе свистнет tls 1.2 появится во всех браузерах и сайтах.

— Гость (22/03/2013 13:43)   
Не просто появится, а уязвимые версии будут запрещены хотя бы на одной стороне, иначе митмом можно будет сделать даунгрейд, так ведь? А это будет как минимум тогда, когда все браузеры его начнут поддерживать.

http://www.imperialviolet.org/...../08/tlsversions.html^[link10] – тут пишут о проблемах совместимости.

Какие условия для Lucky13? MitM или пассивное прослушивание?


2^23 сессий, а там – сообщений (запросов). SSL просто так сессию не начинает, ибо нужно впрягать асимметрику.

Чем этот счетчик галуа так привлекателен?

— sentaus (22/03/2013 20:01, исправлен 22/03/2013 20:05)   

Какие условия для Lucky13? MitM или пассивное прослушивание?

Это padding oracle, т.е. одной из сторон (серверу на практике) посылаются фрагменты зашифрованных данных со спецаильно подобранным IV. Это не пассивное прослушивание, но и не mitm. Скорее, человек "со стороны" :)

2^23 сессий, а там – сообщений (запросов). SSL просто так сессию не начинает, ибо нужно впрягать асимметрику.

А вот тут на сцену выходит beast-оподобная техника с внедреним скрипта на страничку, который и будет новые сессии создавать.

митмом можно будет сделать даунгрейд, так ведь?

Да, можно.

— Гость (22/03/2013 22:41)   

А вот тут на сцену выходит beast-оподобная техника с внедреним скрипта на страничку, который и будет новые сессии создавать.

Каким же образом?

Да, можно.

Получаем замкнутый круг – поддержка в браузерах может заставить глючить сервера, а пока не будет полной поддержки – нельзя будет запретить уязвимые версии.

— sentaus (22/03/2013 22:54, исправлен 23/03/2013 02:06)   

Каким же образом?

In the web setting, our techniques can be combined with
those used in the BEAST attack [13]: client-side malware
running in the browser can be used to initiate all the needed
TLS sessions, with an HTTP cookie being automatically
injected by the browser in a predictable location in the
plaintext stream in each session. The malware can also
control the location of the cookie such that there is only
one unknown byte in the target block at each stage of the
attack. The attacker then combines the “one known byte”
variant of our attack and the base64 optimisation above
(assuming the sensitive part of the cookie is base64 en-
coded). Putting all of these improvements together, we
estimate that HTTP cookies can be recovered using 2^13
sessions per byte of cookie (with all the sessions being au-
tomatically generated). Note that the malware does not
need the ability to inject chosen plaintext into an existing
TLS session for this attack.

http://www.isg.rhul.ac.uk/tls/TLStiming.pdf

Фатальные ошибки (например, ошибка padding) прерывают tls-сессию. Хотя вот конкретно здесь будет нужен mitm – malware в браузере посыылает запросы, которые нужно на лету корректировать.

— Гость (24/03/2013 00:19)   

По нему была отдельная тема^[link11] недавно, кстати.

— Гость (24/03/2013 18:07)   
Мож переведет кто-то? Про Beast и lucky13.

— SATtva (25/03/2013 07:21)   
translate.google.com.

— Гость (25/03/2013 10:42)   

Незачем. Если есть проблемы даже с техническим английским, то непонимание Beast и lucky13 на этом фоне — такая мелочь, что и упоминать не стоит.

— Гость (25/03/2013 17:33)   
Мне просто влом простыни на англицком в одиночку читать, да и мое материальное благополуче от этого не зависит.

SATtva, гуглтранслейт уже с днища поднялся?

— sentaus (09/08/2013 16:03)   
http://nakedsecurity.sophos.co.....g-the-breach-attack/^[link12]

Ну вот ещё и что-то.

— sentaus (11/12/2013 21:22)   
Гугл тем временем пытается вставить в спецификацию TLS потоковый шифр Chacha20 и MAC Poly1305.
http://tools.ietf.org/html/dra.....-chacha20poly1305-01^[link13]

— unknown (12/12/2013 10:43, исправлен 12/12/2013 10:46)   

Torproject тоже хотел.

В принципе, Бернштейн не одиночка, он совместно с другими «звёздами криптотусовки» (включая разработчиков Rijndael и KeccaK) ведёт проект DIAC (подробнее здесь^[link14] и здесь^[link15]), частично финансируемый грантами НИСТ.

Вот если бы он провёл через массу конференций и конкурсов свои разработки (хотя частично это сделано), тогда можно было бы подумать о включении его разработок в стандарты. А так, пока ещё они остаются несколько особняком от мэйнстрима.

Кодерам его алгоритмы нравятся за простоту, нетребовательность к ресурсам, исследователям-практикам — за константы по времени исполнения операций, что исключает утечку данных о внутреннем состоянии шифра по побочным тайминг-каналам.

— sentaus (12/12/2013 14:12)   
А какие сейчас есть вообще сравнительно хорошо изученные потоковые шифры? Или весь мир уже забил на них, даже у самых слабых железяк производительность достаточна для блочных?

— unknown (12/12/2013 15:04)   
Скорее делают ослабленные легковесные блочные. И легковесные варианты на основе Sponge-конструкций тоже активно прорабатываются.

— Гость (13/12/2013 05:28)   

ChaCha20, Salsa20^[link16], Kecak^[link17]... Dance! Ждём Rumba20, Jive35, Tango70, Waltz13...

На личной странице djb не нашёл ничего про его увлечение латиноамериканскими танцами. Наверно, шифруется.


Помню, вы критиковали направления в криптографии, которые пытаются решать проблемы реализации (типа side channel attacks) не физически, а перекладывая это на математику. Мне сейчас уже нереально найти конкретный пост, но что-то было здесь^[link18]:

сохранение внутреннего состояние от взлома — это проблемы реализации. Хотя существуют и направления, которые пытаются создавать алгоритмы, устойчивые к проблемам реализации (напр. атакам по побочным каналам), но зато повышая риск создать алгоритм с плохо обоснованной стойкостью (фактически более слабый).

Т.е. типа негоже и так непростую криптографию грузить ещё и проблемами утечек внутренних состояний по побочным каналам.


… от АНБ^[link19]. У них там своя атмосфера^[link20]…

— sentaus (14/12/2013 23:03)   

Помню, вы критиковали направления в криптографии, которые пытаются решать проблемы реализации (типа side channel attacks) не физически, а перекладывая это на математику.

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

Например, если нужно сравнить два массива байтов, у любого программиста будет желание прерваться на первом несовпавшем байте. В итоге становится возможной тайминг-атака. Вычисления в RSA вроде как можно оптимизировать с помощью китайской теоремы об остатках, только опять всплывёт та же уязвимость. В общем, не очень ясно, где заканчивается математика, а где начинается чисто "реализация" 6)

— unknown (14/12/2013 23:42)   

New Features of Latin Dances: Analysis of Salsa, ChaCha, and Rumba^[link21]

— Гость (15/12/2013 13:43)   
Настраиваю ssl на веб сервере. На что можно заменить rc4, не считая 3des, чтобы ie8 на win xp, имел возможность ходить по ssl?

— Гость (15/12/2013 14:45)   
...это печально раз так... Правильно ли я понимаю, что 3des пока более безопасен, чем rc4 при работе по SSL3?

— SATtva (15/12/2013 17:27)   
В сравнении с RC4 он в любом случае безопасней. Единственный минус — скорость.

— Гость (16/12/2013 12:20)   
Вот здесь Configuring Apache, Nginx, and OpenSSL for Forward Secrecy^[link23] человек пишет о том, что RC4 позволяет каким-то образом бороться с BEAT атаками. Как такое получается?

— unknown (16/12/2013 12:23)   
Уязвимость BEAST касалась способа заполнения блока в некоторых режимах шифрования блочных шифров. А RC4 — поточный шифр и у него таких режимов нет.

— Гость (16/12/2013 16:07)   

Unknown, я угадал! ☻

— unknown (16/12/2013 16:53)   
У нас обсуждались схожие темы^[link24], может вы заглядывали на страницу DJB и краем глаза в подсознании сохранили :)

— Гость (17/12/2013 01:11)   

Ну я на эту тему как бы ссылку и привёл. :-) Правда, про румбу там ничего не было, это я точно придумал. Cальса действительно обсуждалась^[link25] на форуме, причём уже не раз^[link26] (это помимо мной/вами приведённой ссылки).