Сравнение стойкости SSL и ...
Добрый день!
Будьте добры, растолкуйте, насколько отличаются по криптостойкости решения на SSL и например, такого известного продукта, как PGP?
Конечно, понимаю, что это совершенно различные по способу использования и идеологии продукты, но ведь степени защиты данных, обеспечиваемых их протоколами, можно сравнивать?
И если да, то интересует сравнение криптостойкости современных SSL-3, TLS-1 и т.п. с максимальной длиной ключа (128, 256 и т.д.).
А если нет, то может где то есть данные по криптостойкости семейства протоколов SSL в виде, в котором любят приводить примеры типа "1000 компьютеров мощностью 100 МФлопс будут подобрать в течении 500 световых лет" и т.п.
Вообще, будут интересны любые сведения по стойкости SSL.
Оба протокола, SSL и OpenPGP, разрабатывались профессионалами со знанием дела, так что сравнивать их особого смысла нет. Лучше задумайтесь о надёжности реализаций. К примеру, в одной из версий MS Outlook была уязвимость, позволявшая подменить SSL-сертификат сервера (если пользователь получал почту по защищённому соединению) и остаться незамеченным — программа не выдавала предупреждение.
Да-да, это понятно. И все же – неужели не существует кроме качественной, конкретная количественная оценка криптостойкости SSL/TLS?
Ведь не зря же первое время 40-битный SSL полагался достаточно устойчивым, но жизнь внесла свои коррективы, и в обиход была запущена 128-битная версия. Вот и интересно – долго ли простоит этот бастион?
Не было такого. С середины девяностых (когда был создан SSL) и до 2001 г. экспортные версии браузеров содержали ограниченную версию SSL, где применялся шифр RC4 с 40-битовым ключом (формально, ключ был 128-битовым, но только 40 бит были случайными, а остальные — нулями). Обусловлено это было экспортными ограничениями криптотехнологий из США, а не какими-то техническими причинами. Так, версии браузеров, предназначенные для внутреннего рынка США, поддерживали нормальную длину ключа.
SSL — это параметризуемый протокол, а не алгоритм шифрования. Скажем, его применение с 512-битовым ключом RSA, хэшем MD5 и 40-битовым RC4 будет "несколько" отличаться от варианта с 4096-битовым RSA, SHA-1 и AES-256.
Итак, если я правильно понял, конкретики здесь не ожидается?
Пока вы не конкретизируете вопрос хотя бы на уровень ниже – до алгоритмов, ответить будет трудно...
Это вообще из области рекламы. Ну типа как сравнивают стиральные порошки, которые якобы отстирывают на 20% лучше. Хотя так просто это не сравнить.
В действительности сравнение криптостойкости протоколов очень сложное и в одну цифру или таблицу оно не поместится.
Протокол можно разбить на подпротоколы: шифрования, аутентификации. Уже нужно подумать над формальным описанием того насколько надёжно это сделано.
Затем для каждого подпротокола строится идеальная модель: "оракул". Затем пытаются перепробовать все виды нетривиальных атак, которые дают различитель между реальным протоколом и его оракулом. При том что различитель не позволяет сам по себе ничего вскрыть: это лишь мера вероятности, описывающая отличие между идеальной моделью и её реализацией.
Затем пытаются построить модели (полу) реальных атак. Считают, что на них потребуется столько-то шифртекстов, (известных, подобранных или ещё каких) открытых текстов и прочей информации. Считают сколько шагов нужно в виде операций в битах по сравнению с перебором грубой силой. Результат пишут в виде формулы с большим O.
Подпротоколы состоят ещё из режимов шифрования, заполнения и т.д.
И наконец, те самые алгоритмы уровнем ниже – "атомарные" криптографические примитивы: RSA, DH, AES.
В итоге в серьёзном теоретическом исследовании до таких простых и понятных цифр не доходят, потому что они ничего не значат и только вводят в заблуждение, если затраты на атаку нереально большие.
Вообще слишком конкретное заявление "нашу систему будут ломать n комьютеров за n миллионов лет" в ряде случаев это почти Ханаанский бальзам[link1]
Обычно в таких заявлениях не учитывается экспонентциальное увеличение мощьности компьютеров с течением времени.
Где-то даже видел рассчёты, что при этих условиях оптимальное время взлома любого шифра прямым перебором (при фиксированном бюжджете) – где-то два года. Просто надо начинать считать не сразу, а подождав некоторое время :)
Впрочем, в этих рассчётах не учитывалась инфляция, которая съедает бюджет, выделенный на вычисления...
Вобщем, криптография это ещё и экономика.
%до 2001 г. экспортные версии браузеров содержали ограниченную версию SSL, где применялся шифр RC4 с 40-битовым ключом (формально, ключ был 128-битовым, но только 40 бит были случайными, а остальные — нулями)%
А это уже неприятно :-(
Получается, что нас обманывали, и верить тому, что отображается о длине ключа в About и других местах броузеров нельзя?
Это же вроде подтверждается и статьей "SSL: техника безопасного Web'а", где рекомендуется "укрепить" свой браузер:
http://offline.computerra.ru/1998/244/1259/
И для этого даже создана специальная утилита Fortify: http://www.fortify.net
Прокомментируйте эту информацию, пожалуйста.
По крайней мере для симметричных шифров это абсолютно неверно[link2]
(Не обращайте внимание, что статья из устаревшего перевода, принципы в ней также верны, как и закон Мура и даже больше).
А как говорят "для тех ктов танке" эти ограничения были сняты ещё администрацией пр. США Клинтона, так что современные браузеры и ОС патчить не надо.
Эко загнули-то! У "любого шифра" какая длина ключа, 56 бит? Вот Вам информация[link3] к размышлению по теме.
Там писали (у Эксплорера по крайней мере, Нетскейпом я тогда не пользовался), что это экспортная версия и используется ключ с заниженной стойкостью.
В 98-ом году это было актуально, но сегодня ввиду практического отсутствия экспортных ограничений больше не имеет смысла.
unknown, снова коллизия
хэш-значенийкомментариев? :-)Вы знаете, в таких вещах, как защита информации, все же хотелось бы большей уверенности, что используемый броузер соответствует заявленным характеристикам.
Существует ли независимый метод, программа и т.д. для точного определения, в каком именно крипторежиме работает/законнектился с сайтом используемый браузер?
Вы можете проанализировать исходный код браузера, чтобы убедиться, что он пишет правду о свойствах соединения. :) Или доверять производителю.
А всеобщих методик нет. Впрочем, возможно часть информации можно получить путём анализа траффика при установлении соединения. Я точно не знаю, как это сделано в SSL, но думаю, что-то оттуда вытащить можно.
Броузеров много, и проанализировать их все вы не сможете. Или я ошибаюсь? :-)
Насчет методик сторонними средствами – например, многие сниферы позволяют различить открытый http от закрытого https. Кроме того, в фазе хендшейка SSL-клиент и сервер обмениваются установочной информацией – может, в ней содержатся параметры протокола, который устанавливается?
А просто верить всяким там "About" – вы меня извините.... На заборе тоже бывает кое-что написано
Если прямой перебор будет занимать более двух лет, то имеет смысл подождать до тех пор, пока этот срок не сократиться до двух лет, чем начинать сразу на существующих мощностях, поскольку иначе вас обгонят те, кто начнёт позже на появившихся к тому времени более быстрых (за ту же цену) компьютерах.
Время "два года" получается чисто математически при существующих константах у закона Мура в области производителности.
Не более чем занимательный математический факт.
Пределы же роста вытекают из предположения, что процессор не может быть меньше, чем атом.
А вот помниться кто-то из классиков утверждал, что "электрон так же неисчерпаем, как и атом". Вы твёрдо уверены, что он ошибался? ;)
Будьте так любезны формализовать столь претенциозное заявление. Как гласит одно известное ругательство, "обоснуй".
Эй, эй – господа, вы снова полезли в академические бредни... пардон, дебри, ясное дело, без этого вы не можете :-P
Но не забывайте и об авторе топика, который задал свой чисто прикладной вопрос, и последний заданный из них – какими сторонними надежными средствами можно вычислить установленный протокол (сниферы и т.п.)?
Ждем некоторое время t, после чего решаем задачу за время
g(t)=k*exp(-p*t)
где k – объём задачи, p – "коэффициент Мура"
Пусть t0 есть то значение t при котором совокупное время
f(t)= t+g(t)
достигает своего минимума
тогда время собственно счёта (без ожидания)
g(t0)
не зависит от объёма задачи k и равно 1/p
ОБОСНОВАНИЕ
Производная
f'(t)=1-k*p*exp(-p*t)
равна 0 при
t0=ln(1/kp)/-p
время счёта g(t0) = 1/p и не зависит от k
Пусть удвоение производительности происходит за полтора года
g(1.5)=g(0)/2
k*exp(-p*1.5)=k/2
(k сокращается!)
exp(-1.5*p)=1/2
-1.5*p=-ln(2)
1/p=1.5/ln2= 2,164042561334... ~ 2 года
Ч. Т. Обосновать :)
Ни фига себе! :-O Вот это математики...
k – объём задачи? Т.е. ключ? Так он же тоже экспоненциальная величина.
Сегодня можно подобрать ключ скажем 64 бит: 2^64, когда доступные мощности возрастут в два раза, то можно подобрать ключ размером 2^^65 бит,
когда доступные мощности возрастут ещё в 2^64 раз 18446744073709551616, то можно подобрать 128 битный ключ, а для 2^256 ключа уже ограничения по энергии работы космические.
Да вообще-то это не выходит за рамки школьного курса, во всяком случае, когда я учился.
Ну так вышепреведённое утверждение основано на законе Мура. Если это основание пошатнётся, утверждение перестанет быть верным. А в ближайшие десяток – другой лет из него может быть даже можно будет извлеч и кой-какую практическую пользу :)
Есть понятие сложности задачи: линейная O(n), полиноминальная O(n^t) и экспоненциальная O(t^(2^n)) в нашем случае: t- некая константа выполнения, n-длина ключа. Поиск ключа – экспоненциальная задача, её так просто не сократить. Закон Мура не победит "О большое".
Я надеюсь, наш великий математик видит, что время необходимого ожидания всё равно пропорционально размеру ключа :)
Если минимальный квант энергии = 1 электрон-вольт, может ли кто-то получить в нашей вселенной 2^256 электрон-вольт? Энергии солнца не хватит!
Квантовые компьютеры позволяют сократить время до O(t^(2^(n/2))) для симметричных алгоритмов и полностью взламывают существующие ассиметричные, но это уже совсем отдельная тема.
Касательно SSL-траффика: зачем его снифать и реверс-инжинерить протокол? Если исходники закрыты, то это ничего не даст, может там случайные числа неверно получаются или идёт утечка битов ключа.
Из всего этого можно всего лишь определить, когда именно нужно начинать взлом. Кстати, не скажете ли нам, сколько нужно ждать, чтобы сломать за указанное вами время, например, 128-битный ключ. Считайте, что у вас есть ресурсы, позволяющие вам сейчас взломать 64-битный за один год. Коэффициент Мура оставьте прежним.
2unknown Ну с этим без исходников не поборешься. Хотя я что-то не могу так сразу представить, как можно в браузере сделать утечку сеансового ключа.
Почему? Закон Мура также экспонентциален.
лучше сказать "оптимальное время ожидания"
Кто знает, какие бездны могут открыться на субатомных уровнях? Хотя конечно это уже совсем отдельная тема.
Если считать, что удвоение производительности происходит каждые полтора года это означает
полтора года на один дополнительный бит ключа, т.е.
(128-64)*1.5=96 лет. :)
Вообще-то да, скрытые каналы действительно малоактуальны: сеанс связи в реальном времени и ключ эфемерный. Если и удасться незаметно передать часть битов от ключа, то небольшую. Кроме того браузеры обычно работают на готовой библиотеке openssl, вероятность получить там что-то лишнее мала.
Вообще, изначально впрос был gpg vs ssl, но тут зависит от области применения.
SSL для онлайн протоколов, OpenPGP – для почты, сообщений, мессанджеров.
Системы сертификатов против сети доверия и т.д.
http://www.keylength.com
Да всё верно, по некоторым оценкам даже через 30 лет. Только перебор ключа – это последнее что будут делать для взлома системы.