Вход на сайт

МЕДИАМЕТРИКА

Облако тегов

Опубликован прототип бэкдора в генераторе псевдослучайных чисел Dual_EC_DRBG, входившем в стандарт NIST

Аватар пользователя ibm360

Aris Adamantiadis, исследователь безопасности из Бельгии, развивающий проект libssh, опубликовал рабочий прототип приложения, подтверждающего теорию о возможном наличии бэкдора в алгоритме генерации псевдослучайных чисел Dual EC DRBG, до недавних пор входящим в стандарт NIST SP 800-90 и использованном по умолчанию в продуктах Bsafe и RSA Data Protection Manager от компании RSA.

Алгоритм Dual EC DRBG, описывающий способ генерации псевдослучайных чисел на основе методов криптографии по эллиптическим кривым, был разработан и продвинут в состав стандарта Агентством национальной безопасности США (АНБ). Теоретические опасения о возможных проблемах в Dual_EC_DRBG были опубликованы ещё в 2007 году, но всерьёз они насторожили общественность лишь в сентябре 2013 года, после публикации Эдвардом Сноуденом материалов, свидетельствующих о работе АНБ по внедрению бэкдора, кардинально упрощающего предсказание генерируемых через Dual_EC_DRBG последовательностей.

После появления этих сведений компания RSA и Национальный институт стандартов и технологий США (NIST) выпустили рекомендации не использовать Dual_EC_DRBG. В декабре появились новые материалы, указывающие на заключение секретного контракта между АНБ и RSA, размером в 10 млн долларов, подразумевающего применение Dual_EC_DRBG в качестве алгоритма по умолчанию в Bsafe.

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

Aris Adamantiadis сумел успешно продемонстрировать возможность предсказывать выдаваемые на выходе значения, используя лишь одну изменённую константу в Dual_EC_DRBG. Весь код и инструкции, позволяющие повторить эксперимент, опубликованы на GitHub. Параметры генерации констант, указанных в стандарте NIST, остаются известны только АНБ. При этом данные константы обязательны для использования в неизменном виде при прохождении сертификатции по FIPS 140-2.

Оригинал: http://www.opennet.ru/opennews/art.shtml?num=38768

Фонд поддержки авторов AfterShock

Комментарии

Аватар пользователя KMS-64
KMS-64(5 лет 11 месяцев)(11:47:19 / 09-01-2014)

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

Аватар пользователя jerry
jerry(4 года 11 месяцев)(12:07:10 / 09-01-2014)

Этот генератор случайных чисел используется в протоколах зашифрованной связи в интернетах. Пишут, что если злоумышленник

1) мониторит ваш зашифрованный канал

2) знает "секретный ключ", который предусмотрен в алгоритме генератора случайных чисел 

то он может по 32-м байтам этого генератора предсказать следующие "случайные" числа. А следовательно, ваш зашифрованный канал скомпрометирован и вы об этом даже не будете подозревать.

Аватар пользователя PigPog
PigPog(5 лет 10 месяцев)(12:09:45 / 09-01-2014)

Любой пароль имеет отмычку. Дальше фантазируйте сами, к чему это приводит.

Аватар пользователя hardknap
hardknap(5 лет 2 месяца)(16:40:26 / 09-01-2014)

Столь общие утверждения обычно неверны.

Аватар пользователя PigPog
PigPog(5 лет 10 месяцев)(17:09:48 / 09-01-2014)

>А чем это опасно вааще, в изложении для простого быдла?

думаю для такого уровня достаточно общего утверждения. Если не согласны, дайте свое.

Аватар пользователя Bolek
Bolek(5 лет 9 месяцев)(12:10:36 / 09-01-2014)

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

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

Ну, если правда всё сказанное.

Аватар пользователя KMS-64
KMS-64(5 лет 11 месяцев)(12:25:29 / 09-01-2014)

>>Ну, если правда всё сказанное.

Может, это кого-то удивит, но я верю этому абсолютно. Ибо по другому и быть не может. Странно, если бы этого не было.

Аватар пользователя nictrace
nictrace(5 лет 10 месяцев)(12:04:41 / 09-01-2014)

да, пара слов о назначении NIST не помешала бы...

Аватар пользователя Diogenes Sinopeus
Diogenes Sinopeus(5 лет 11 месяцев)(12:14:34 / 09-01-2014)
Ну rsa это вроде pgp, ну и мало ли какие системы авторизации. короче - шифры какието рознообразные. коварные анб их читать могут оказывается. ужосужос, они могут узнать мои пароли. а я бы никогда бы не догадался, думал они лохи, которых никто из программистов не слушает. ан нет, не лохи, оказывается их "ненавязчиво попросили" оставить анб возможность почитать. и удивительно - частный программист послушал какуюто анб.
Аватар пользователя mr.Iceman
mr.Iceman(5 лет 10 месяцев)(00:52:01 / 10-01-2014)

> rsa это вроде pgp

pgp ранних версий использовало алгоритмы rsa, этио правда.

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

Аватар пользователя Rashad_rus
Rashad_rus(5 лет 10 месяцев)(12:08:21 / 09-01-2014)

Тупой XOR с иттерационным сдвигом, ключиком длинной в пару мегабайт с использованием нестандартного CRC и привет! Стандартизация в сфере защиты информации - ловушка для лохов. А верить крупному производителю криптоалгоритмов - все-равно, что отдавать кредитку с пин-кодом мошеннику.

Аватар пользователя jerry
jerry(4 года 11 месяцев)(12:14:34 / 09-01-2014)

Ключ придется менять при отправке каждого сообщения, это жутко неудобно при синхронизации ключа среди участников переписки.

Аватар пользователя nictrace
nictrace(5 лет 10 месяцев)(12:17:04 / 09-01-2014)

а для этого есть протокол DUKPT

Аватар пользователя jerry
jerry(4 года 11 месяцев)(12:24:18 / 09-01-2014)

Который тоже использует стандартные криптоалгоритмы? В чем тогда профит от использования чистого XOR и отказа от навязанных нам шпионами алгоритмов шифрования?

Если отказываться, то от всех подозрительных вещей.

Аватар пользователя nictrace
nictrace(5 лет 10 месяцев)(12:27:17 / 09-01-2014)

есть еще ГОСТ 28147-89 :)

Аватар пользователя mr.Iceman
mr.Iceman(5 лет 10 месяцев)(00:57:42 / 10-01-2014)

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

Аватар пользователя tiriet
tiriet(4 года 9 месяцев)(13:10:33 / 09-01-2014)

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

кроме того- как именно вы будете менять ключ? генерировать ГПСЧ? или паять хардварный генератор энтропии? и после генерации ключа как его передать Бобу? и как убедиться, что это именно Боб? а не Билл. и как сделать так, чтобы этот ключ нельзя было перехватить в процессе передачи или выдрать из переданных данных усилием мысли?

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

Аватар пользователя jerry
jerry(4 года 11 месяцев)(13:18:20 / 09-01-2014)

Я вообще-то выше раскритиковал неудобства XOR. Но вы преувеличиваете его проблемы. Если (чисто теоретически) решить задачу обмена паролями, то XOR - идеальный шифр. особенно если ключ по длине равен сообщению. В таком разе вы, даже зная часть текста, не сможете вытащить остальное содержимое, при условии, что ключ состоит не из текста из книги, а создан генераторм псевдослучайных чисел.

Ну и ключ придется менять при каждом новом сообщении, что таит в себе непродолимые проблемы.

Аватар пользователя tiriet
tiriet(4 года 9 месяцев)(13:54:57 / 09-01-2014)

ну, насколько я знаю- RSA как раз и есть теоретическое решение задачи обмена паролями. а XOR банальнейшим образом нестоек к MITM, и это полный и бесповоротный.

кроме того, заявленная то дыра как раз и заключается в том, что все стойко и прекрасно (даже к МИТМу), пока не выяснилось, что ГСПЧ немножко неслучайный.

так. на всякий случай. mitm- man in the middle - человек посередине, атака с использованием промежуточного узла, Алиса хочет передать письмо Бобу, но посередине сидит Кейн, и прикидывается Бобом для Алисы, и Алисой для Боба- таким образом, читает всю их переписку, а они думают, что общаются друг с другом без посредника.

Аватар пользователя joho
joho(4 года 2 месяца)(14:08:54 / 09-01-2014)

Проблема, указанная в статье не касается алгоритма шифрации. Затык в генерации ключей.

Когда устанавливается соединение - тот же SSL - ключи генерируются случайным образом. Возможно вам известно, и RSA и DH - оба алгоритма фактически проводят математические вычисления - умножение, возведение в степень, взятие остатка по модулю с огромными числами. Например, ключ 1024 бита, ныне используемый как минимальный в RSA, это примерно число в 300 десятичных разрядов.

Из за громоздкости вычислений алшоритмы крайне медленные. Поэтому шифровать ими постоянно возможно, но накладно. Именно поэтому RSA используется только для шифрации одноразового случайного пароля, который передаётся партнёру. И этот одноразовый - короткий (16 или 32 байта ныне) - пароль используется в симметричных быстрых алгоритмах - таких как AES, и он будет одинаков с обоих сторон

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

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

Аватар пользователя tiriet
tiriet(4 года 9 месяцев)(14:32:55 / 09-01-2014)

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

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

Аватар пользователя jamaze
jamaze(5 лет 10 месяцев)(14:49:31 / 09-01-2014)

Эээ, а ваш сжатый фильм - это разве не генератор псевдослучайных чисел? С очень предсказуемыми следующими числами?

Аватар пользователя joho
joho(4 года 2 месяца)(14:53:00 / 09-01-2014)

Нет.

Данная схема даёт гарантированный белый шум.

Разница лишь в том, что этот шум можно воспроизвести байт в байт на другом конце линии.

Аватар пользователя jamaze
jamaze(5 лет 10 месяцев)(16:38:32 / 09-01-2014)

Это и называется генератором псевдослучайных чисел.

Берите любой - от простейшего xn+1=(A*xn+B) mod C до генератора Мерсена - они все генерируют "белый шум" (случайная величина с равномерным распределением), который можно воспроизвести на другом конце один в один с помощью установки тех же начальных значений.

Аватар пользователя jerry
jerry(4 года 11 месяцев)(14:09:15 / 09-01-2014)

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

Аватар пользователя tiriet
tiriet(4 года 9 месяцев)(14:34:27 / 09-01-2014)

гениально! а как сделать так, чтобы Кейн не узнал алгоритм, по которому мы выбираем ключ и входные параметры этого алгоритма, но при этом обеспечить этой информацией Боба?

Аватар пользователя jerry
jerry(4 года 11 месяцев)(14:43:30 / 09-01-2014)

В этом и главный минус шифрования XOR-ом - синхронизация ключей. 

Аватар пользователя joho
joho(4 года 2 месяца)(14:49:56 / 09-01-2014)

Смешные вы ребята

Вот попробуйте безопасно передать мне ключ. Есть варианты? Уточню, мне, а не кому нибудь другому :o)

Жызнь в ынтернете накладывает свой отпечаток

Какой бы способ вы не изобретали, вы упрётесь в идентификацию меня. Либо самостоятельную, либо посредством какой либо организации - третьего лица, которой вы наивно поверите. Например, центра сертификации. Или паспортному столу.

В реальной жизни передача закрытого ключа может выполнятся только лично. Без любой возможности для MitM. В этом раскладе ни длинна ключа ни прочие прибамбасы роли не играют.

Аватар пользователя jerry
jerry(4 года 11 месяцев)(15:07:42 / 09-01-2014)

Вы, кажется, не читаете, а сразу отвечаете. Интернет и вас не пощадил.

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

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

Аватар пользователя joho
joho(4 года 2 месяца)(15:32:57 / 09-01-2014)

что то дискуссия в тупик зашла

Я утверждаю, что условия интернета не позволяют передать ключ партнёру со 100% гарантией независимо от алгоритма. Конкретному человеку вы можете передать ключ только лично. Кому отдали, у того  он и есть. В противном случае вы будете опираться на систему опознания кого то другого и зависеть от её качества.

Я утверждаю, что при личной передаче ключа ключ может быть любой. Например, тыщу терабайт, если это необходимо и полезно. Ключ, переданный лично может скрывать в себе любой механизм генерации, упрощая способ его применения.

Я утверждаю, что ключ, содержащий белый шум, полученный из какого либо источника - в том числе, предложенного мной - можно использовать тривиально - например XOR-ить, без ущерба для качества закрытия канала. Белый шум (+) текст даст белый шум и никакого варианта раскрытия сделать не выйдет. XOR является симметричным методом, и в указанном сценарии ( http://aftershock.news/?q=comment/708942#comment-708942 ) не имеет никаких отличий от любого другого симметричного метода.

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

И все эти темы не имеют отношения к теме статьи, кстати говоря

Аватар пользователя jerry
jerry(4 года 11 месяцев)(16:09:19 / 09-01-2014)

Это все понятно. Речь шла о невозможности использования шифрования XOR-ом в реальной жизни. Ограничений на передачу ключей я никаких не ставил, передавайте их лично на дискетке в чемодане, это все равно теоретическая задача.

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

Аватар пользователя joho
joho(4 года 2 месяца)(16:25:54 / 09-01-2014)

по поводу передачи "из рук в руки"

Слышали ли вы, что когда чуваки получили исходники win nt 2k в рамках подписки MSDN , в подсистеме криптозащиты был обнаружен ключик с комментарием "ключ АНБ", которому винда доверяла в части установки обновлений и проверки подписи на файликах?

Сллышали ли вы, что примерно лет 7 назад некие чуваки увели сертификаты микрософта и подписывали им разное маллваре?

Слышали ли вы, что mail ru, распространяя свой мессенджер, пару лет назад подписывало своим ключом все партнёрские программы, что привело к раздаче вредоносного софта, подписанного их сертификатом?

Таких ситуаций - уйма. Когда вы читаете почту на GMAIL, и видете замочек с проверенного сертификата, знаете ли вы, кто, когда и при каких условиях поставил вам на компьютер сертификат центра сертификации, авторизовавшего гуглопочту? Вы разрешали это? Он пришёл к вам из доверенного места, вы проверяли? Читали ли вы список документов, который требует данный центр сертификации при выдаче сертификата? Он вас удовлетворяет? Вы точно знаете, что сертификат по прежнему не украден у гугла? Что службы безопасности не договорились с центром сертификации и не получили свой вариант доступа к вашим данным? Знаете ли вы, что америкосы просят своих не возить смартфоны в Сочи на олимпиаду, ибо весь трафик там будет вскрыт и все пароли выявлены ФСБ?

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

Поэтому схема "из рук в руки" - единственный вариант, где хоть что то можно обещать.

Аватар пользователя nictrace
nictrace(5 лет 10 месяцев)(16:28:52 / 09-01-2014)

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

Аватар пользователя jerry
jerry(4 года 11 месяцев)(16:35:08 / 09-01-2014)

Вы говорите какими-то очевидными лозунгами, но все мимо темы данной подветки - удобство/неудобство шифрования XOR. Неподъемной проблемой которого как раз и является синхронизация и передача ключей.

Аватар пользователя joho
joho(4 года 2 месяца)(16:44:10 / 09-01-2014)

окей

Мы определились с разногласием

XOR я вляется базовой процедурой микширования.

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

Так вот, XOR - это база для подмены.

Читаем: http://ru.wikipedia.org/wiki/Advanced_Encryption_Standard

Аватар пользователя jerry
jerry(4 года 11 месяцев)(17:04:31 / 09-01-2014)

Речь шла о чистом XOR без использования стандартных алгоритмов как о панацее.

Аватар пользователя joho
joho(4 года 2 месяца)(17:31:16 / 09-01-2014)

Никто не писал слово "панацея".

Я описал алгоритм, которого достаточно и который нисколько не хуже для организации канала точка-точка чем прочие здесь обсуждаемые.

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

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

Аватар пользователя jerry
jerry(4 года 11 месяцев)(17:54:12 / 09-01-2014)

Вы про использование фильма в качестве ключа? Это решает проблему обмена ключом, однако вам надо сверить часы - а именно: какой фильм вы используете, с какого адреса начинаете брать ключ и как часто вы его будете "сдвигать". Время от времени вам придется синхронизировать его (письмо собеседником не прочитано или не дошло). Это снижает эффективность вашей защиты.

А если вы по ошибке отправите два письма, зашифрованные одним ключом, то это будет подарком для злоумышленника.

Рабочее решение, но очень шаткое и неудобное.

Аватар пользователя joho
joho(4 года 2 месяца)(22:59:56 / 09-01-2014)

Мы ходим по кругу. Как я говорил выше, всё это передаётся при личной встрече.

Аватар пользователя ВладимирХ
ВладимирХ(4 года 11 месяцев)(15:36:03 / 09-01-2014)

Вот попробуйте безопасно передать мне ключ. Есть варианты? Уточню, мне, а не кому нибудь другому :o)

А Вы про двухключевые схемы слышали?

Аватар пользователя joho
joho(4 года 2 месяца)(15:40:39 / 09-01-2014)

слышал, вы не поверите

Аватар пользователя ВладимирХ
ВладимирХ(4 года 11 месяцев)(15:50:22 / 09-01-2014)

Тогда уточните, какие именно проблемы передаччи ключа Вы имеете в виду?

1. Ненадежность двухключевых схем в принципе

2. Невозможность надежной идентификации (подмена идентификатора) абонента 

3. Еще что-то

Аватар пользователя joho
joho(4 года 2 месяца)(16:03:44 / 09-01-2014)
Аватар пользователя ВладимирХ
ВладимирХ(4 года 11 месяцев)(16:23:32 / 09-01-2014)

Коротко резюме, как я Вас понял

Двухключевая схема ненадежна в принципе

Все-таки, есть надежда, что увеличение длины ключей с ростом вычислительных мощностей увеличивает отношение (сложность шифрования)/(сложность взлома), даже если NP=P. Т.е. надеемся, что степень полинома достаточно велика.

Вы не видите, кому передаете ключ, поэтому там вместо "Алисы" может оказаться "Давид" :)

Здесь вопрос - кто, вообще, тот абонент, с которым Вы решили организовать закрытый канал?

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

Аватар пользователя joho
joho(4 года 2 месяца)(16:34:59 / 09-01-2014)

Двухключевая схема. Не совсем в кассу, но вполне чуть позже мы сможем прочитать что то вроде этого http://habrahabr.ru/post/200858/

Вопрос ЭЦП тоже не так прост, как кажется. Вот например, про коллизии в MD5 http://ru.wikipedia.org/wiki/MD5

Вполне возможно, что через пару лет мы прочитаем про коллизии в SHA-X

И, конечно, подпись так же требует предачи ключа по доверенному каналу-способу. Лучший вариант - личная передача.

Аватар пользователя ВладимирХ
ВладимирХ(4 года 11 месяцев)(16:50:42 / 09-01-2014)

Двухключевая схема. Не совсем в кассу, но вполне чуть позже мы сможем прочитать что то вроде этогоhttp://habrahabr.ru/post/200858/

Согласен, но обратите внимание, что требуется подбор параметров. Мораль сей басни - гослицензия - не гарантия от бэкдоров, но есть надежда, что этот бекдор доступен только лицензирующему, а не каждой свинье :)

Вопрос ЭЦП тоже не так прост, как кажется. Вот например, про коллизии в MD5 http://ru.wikipedia.org/wiki/MD5

Вполне возможно, что через пару лет мы прочитаем про коллизии в SHA-X

Коллизии хешфункций только часть проблемы с ЭЦП. ЭЦП - это намного больше, чем хешфункция.

И, конечно, подпись так же требует предачи ключа по доверенному каналу-способу. Лучший вариант - личная передача.

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

А при личной встрече тоже может оказаться двойник ;)

Аватар пользователя mr.Iceman
mr.Iceman(5 лет 10 месяцев)(01:33:39 / 10-01-2014)

Вы, коллеги, дружно забываете, что не вся информация одинаково секретна. И обеспечивать супер-пупер надежное шифрование необходимо весьма редко. Мне представляется, что для наших, "бытовых" целей существующие алгоритмы шифрования и существующие-же методы аутентификации визави вполне надежны (я имею ввиду определенные специализированные коммерческие продукты, а не попсу типа реализации SSL/TLS в современных интернет-броузерах). Доступ к интересущей информации любой отечественной организации всегда можно получить с помощью "маски-шоу" и единственного подстегивающего удара по яйцам главного сисадмина сети. Доступ к информации частного лица - просто ласково протерев жало паяльника вазелином и мечтательно-застенчиво улыбнувшись.

Поэтому не стоит особо заморачиваться насчет потенциальной ненадежности алгоритмов. Она существует, она известна, но на данный момент она достаточно маловероятна, чтобы имело смысл потенциально рисковать, получая все удобства электронной передачи информации. По мере развития теории криптографии и роста можностей вычислительной техники, алгоритмы шифрования и методы передачи закрытой информации будут усложняться и совершенствоваться, это очевидно. Но не стоит впадать в параною. Любая информацию имеет свою цену. Из пушки по воробьям не стреляют. Как-то так.

Аватар пользователя ВладимирХ
ВладимирХ(4 года 11 месяцев)(06:58:01 / 10-01-2014)

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

Любая информацию имеет свою цену. Из пушки по воробьям не стреляют. Как-то так.

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

1. Твоей инфой реально интересуются

2. Узнали они то-то и то-то, а это осталось невыданным.

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

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

Короче, читайте Ассанжа.

Аватар пользователя tiriet
tiriet(4 года 9 месяцев)(12:57:00 / 09-01-2014)

криптограф? а наличие в потоке данных известных кусков? заголовки запросов например, не позволяют ли случайно послушав несколько мегабайт твоего трафика выцепить таки "ключик"? и главная проблема- как Алиса передаст двухмегабайтный ключ Бобу? как она согласует с ним этот волшебный XOR со сдвигом и как Боб потом прочтет сообщение.

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

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

Аватар пользователя joho
joho(4 года 2 месяца)(13:47:27 / 09-01-2014)

ээх

Ладно, вот вам надёжный алгоритм

Берётся кинушка. Например, SNATCH в переводе Гоблина на DVD. Хороший фильмец, кстати.

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

Кинушка шифруется любым современным алгоритмом. Можно и не свременным - хоть DES - лишь бы _реально шифровал_.

В результате на обоих берегах океана имеем две одинаковые последовательности незамутнённых случайных данных размером в несколько гигабайт.

В дальнейшем - просто XOR-им наше сообщение с этим потоком - с любого обговорённого места. Желательно без повторов уже испльзованных участков.

Использование вместо DVD кинушек на  Blue Ray увеличивает объём данных почти в 10 раз, т.е. можно в 10 раз реже менять основу для работы, что уменьшает суету.

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

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

Аватар пользователя tiriet
tiriet(4 года 9 месяцев)(14:04:38 / 09-01-2014)

Вы просто чуть-чуть завуалировали проблему обмена ключами :-) и сделали ключи очень большими. DES реально шифрует, но это симметричный алгоритм, и для передачи данных необходим обмен ключами. а это- ПРОБЛЕМА! в публичных сетях. Я- такибыть Алиса, а ты- Боб. и как мне убедиться- что ты- это Боб, и что ключ, который я сейчас пошлю тебе "две сорванных башни".ави с хешем 0000 шифрованный DES с ключом 12345678 я пошлю именно тебе- вот прямо сейчас, прямо тут, а не какому-то злому Пореченкову из АНБ? и ты- как ты щас убедишься, что это все тебе пишет Алиса, а не Пореченков из АНБ? и мы плавно приплываем к RSA ;)

Аватар пользователя joho
joho(4 года 2 месяца)(14:17:05 / 09-01-2014)

Путаем алгоритм криптографии, передачу ключей и генератор случайных чисел.

DES или любой другой алгоритм (например, архиватор 7z) нужен исключительно для подавления структур синхронизации в потоке фильма и превращении его в рандомный поток. Кстати, 7z предпочтительней в жизни, ибо проще объяснить полиции что я тупой и архивирую фильмы, чем я зачем то его зашифровал

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

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

Аватар пользователя jamaze
jamaze(5 лет 10 месяцев)(14:31:49 / 09-01-2014)

То, что вы предлагаете - это самое начало криптографии. Когда ключ длиннее данных - тогда таки да, взломать его невозможно. Но тем не менее, это симметричное шифрование. И вам таки надо передавать "названия фильма и его базовых параметров, позволяющих однозначно этот фильм найти" - а это и есть ключ. Его передача перехватывается - и всё.

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

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

Аватар пользователя joho
joho(4 года 2 месяца)(14:37:17 / 09-01-2014)
Аватар пользователя ВладимирХ
ВладимирХ(4 года 11 месяцев)(13:33:04 / 09-01-2014)

Тупой XOR с иттерационным сдвигом, ключиком длинной в пару мегабайт с использованием нестандартного CRC и привет! Стандартизация в сфере защиты информации - ловушка для лохов. А верить крупному производителю криптоалгоритмов - все-равно, что отдавать кредитку с пин-кодом мошеннику.

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

Аватар пользователя tiriet
tiriet(4 года 9 месяцев)(13:35:43 / 09-01-2014)

пример можете привести?

Аватар пользователя ВладимирХ
ВладимирХ(4 года 11 месяцев)(14:18:09 / 09-01-2014)

Не могу. Сами думайте

Аватар пользователя hardknap
hardknap(5 лет 2 месяца)(16:44:23 / 09-01-2014)

ГОСТ и AES

Аватар пользователя Dark Side
Dark Side(5 лет 3 месяца)(14:25:08 / 09-01-2014)

Вас не смущает тот факт что так никто не делает ))))) У этого метода есть свои проблемы.

Аватар пользователя Ван Ю Шин
Ван Ю Шин(4 года 5 месяцев)(12:26:43 / 09-01-2014)

Занесение разработчику паяльника чемодани с зеленью - решает проблему затрат на квантовые компьютеры для взлома шифров.

Аватар пользователя tiriet
tiriet(4 года 9 месяцев)(13:13:44 / 09-01-2014)

ну, надо еще так занести, чтобы только через десять лет после явного указания места дыры ее смог кто-то найти. это не такое простое дело :)

Аватар пользователя jerry
jerry(4 года 11 месяцев)(13:19:48 / 09-01-2014)

Дыру обнаружили еще в 2007-м, почти сразу.

Аватар пользователя tiriet
tiriet(4 года 9 месяцев)(13:36:42 / 09-01-2014)

в 2007 же только пошумели, что она там может быть- но подробно атаки или способа ее реализации не было. или я не прав?

Аватар пользователя jerry
jerry(4 года 11 месяцев)(13:43:28 / 09-01-2014)

Ну, судя по ссылке сверху, обнаружили подвох и объявили, что это скорее всего бэкдор, ну без последствий, конечно. Но выявили это дело оперативно.

Аватар пользователя tiriet
tiriet(4 года 9 месяцев)(13:46:06 / 09-01-2014)

так и я о том же- тогда объявли, что это "скорее всего", но доказывать не стали, а сейчас показали- как именно это можно использовать- подбираем константы так-то и так-то и вуаля, ГПСЧ становится неслучайным и шифр ломается, то есть, уже не скорее всего, а точно и даже понятно, как работает- то есть, доказали, и доказали только сейчас. 

Аватар пользователя Добрая Машина Пропаганды

Вообще-то, доказывать стойкость алгоритма должны были его создатели. В соответствии с принципом презумпции виновности.

Но они не доказали. А остальные поверили им на слово, несмотря на наличие неразрешённых сомнений.

Очевидно, кто-то настоял на подобном нарушении процедур верификации.

Аватар пользователя tiriet
tiriet(4 года 9 месяцев)(14:48:14 / 09-01-2014)

милейший, вы как себе представляете доказательство стойкости криптоалгортма? вы его себе вообще хоть как-то представляете?

DES стойкий только потому, что пока никто не придумал алгортма, как его быстро поломать. есть алгоритмы как его поломать медленно, а быстро- нету. RSA и Диффи-Хелманы по той же причине. AES, Serpent, кэтчак и другие- аналогично. про кэтчак правда есть теоремка, доказанная- что его результат невозможно отличить от случайной последовательности при некоторых условиях, это типа укрепляет веру в его стойкость. кроме того, не надо путать стойкость алгоритма как такового и стойкость его конкретной реализации :-). в конце концов- все они ключи в памяти хранят, в незашифрованном виде :-). и ломаются все жестко- в системник заливается пять литров жидкого азота и отрубается питалово- после чего быстро вынимаются планки памяти, пихаются в "картридер" и все ее содержимое сливается на жесткий диск, где уже неспешно разбирается побайтно. на физическую часть уходит 30 секунд, за это время при низкой температуре заряды в памяти рассосаться не успевают и удается сделать полный дамп. как-то так. :-).

Аватар пользователя jamaze
jamaze(5 лет 10 месяцев)(14:23:34 / 09-01-2014)

Так вот зачем в ГОСТе криптография на эллиптических кривых с параметрами, подобранными ФСБ-шниками.

Аватар пользователя Dark Side
Dark Side(5 лет 3 месяца)(14:29:49 / 09-01-2014)

Все коммерческие и часть закрытых шифров с секретными теоремами. Нигде в мире нельзя получить лицензию на настоящий криптостойкий шифр. Например вы нигде не найдете шифров на полиномах высоких разрядов в полях Галуа.  Табу. Хотя есть алгоритмы и сильнее.

Аватар пользователя joho
joho(4 года 2 месяца)(14:33:44 / 09-01-2014)

Ещё раз

Путаем генератор случайных чисел (тема статьи), алгоритм шифрации и (иногда) обмен ключами

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

Аватар пользователя Dark Side
Dark Side(5 лет 3 месяца)(14:52:15 / 09-01-2014)

Никто и не путает. Задача шифрования это порождение хаоса или бесконечной непериодической последовательности чисел. В любом частном случае некоторого подмножества такой последовательности. Задача ГПСЧ это создание бесконечной непериодической последовательностей чисел. Это ровно одно и тоже. Включая теорему о абсолютно криптостойком шифре. Который в пределе есть ГПСЧ.

Аватар пользователя jamaze
jamaze(5 лет 10 месяцев)(16:42:03 / 09-01-2014)

Для ГПСЧ нужно начальное значение. Которое есть ключ.

Т.е. весь абсолютно криптостойкий шифр сводится в реальности к банальному симметричному шифру. Который есть прошлый век.

Аватар пользователя hardknap
hardknap(5 лет 2 месяца)(16:47:48 / 09-01-2014)

Вам приснилось, что одно и то же. А выше диалог пары тех, кто слышит звон, да не знает где он. Рассуждают о высоких материях со знаниями первокурсника. Очень глупо выглядит.

Лидеры обсуждений

за 4 часаза суткиза неделю

Лидеры просмотров

за неделюза месяцза год

СМИ

Загрузка...