Комментарии 27
НЛО прилетело и опубликовало эту надпись здесь
немного непривычно видеть
А за ликбез спасибо, знать-то знал про метод, да как-то всё rsa хватало.
openssl ec -in c:\ec\Client\Client.keyни разу не приходилось openssl под окнами использовать.
А за ликбез спасибо, знать-то знал про метод, да как-то всё rsa хватало.
Вы молодец) Криптография это круто, жаль что толком в ней разбирается мало людей.
А какое сравнение скоростей потокового шифрования?
Вот ТАКИЕ статьи я хочу видеть на хабре, ощущается уровень. Может мне кажется, но раньше таким и был хабр, пока его не засрали и не сделали новостной лентой
Вы защитили нас от НЛО!:)
А на мой взгляд для параноиков безопасности все же лучше использовать белый шум, можно использовать шум от китайского микрофона и т.д. Тут однозначный рандом получим, а не результат какой-либо функции. Ведь функция зачастую занижает конечную ширину ключа. Еще как вариант, использовать слабенькую звуковую карту, у которой выход закинуть на вход (со знакомым так делали, получилось очень хорошо, нужен высокий уровень сигнала или большая чувствительность). Скорость генерации ключей очень высокая, добавив guid к последовательности мы можем гарантировать еще большую уникальность ключа. С другой стороны нет до сих пор звук никто и не пытается использовать и нет готовых полноценных решений.
Проблема одноразовых блокнотов (а вы описали одноразовый блокнот) в том, что
1) ключ=размеру сообщения (каждый байт ключа ксорится с байтом сообщения)
2) Этот ключ надо каким то образом доставить получателю
Зато да, это единственный алгоритм который НЕВОЗМОЖНО взломать при хорошем ГСЧ
Можно конечно записать один шум на две болванки и развести их по континентам, но это ессно гемор.
1) ключ=размеру сообщения (каждый байт ключа ксорится с байтом сообщения)
2) Этот ключ надо каким то образом доставить получателю
Зато да, это единственный алгоритм который НЕВОЗМОЖНО взломать при хорошем ГСЧ
Можно конечно записать один шум на две болванки и развести их по континентам, но это ессно гемор.
Не совсем то, используется то асиметричный алгоритм, просто белым шумом генерируется закрытый ключ. Ключи генерируются пачками на транзакции со стороны сервера, получилось в итоге довольно интересно. Собирали статистику по качеству генерации, вообще повторов каких-либо не обнаруживается, даже коротких последовательностей.
ну кстати нам на курсах криптографии читали, что так и делается. Дядечка с чемоданом, который прикован к руке наручниками перевозит таки кучу носителей с одноразовым блокнотом. Мне тогда эта мысль казалась фантастической, но говорят, у нас в РФ это используется.
Только надо обязательно ПРЕДУПРЕЖДАТЬ, что пока не стоит такое крипто использовать в потенциально публичных сервисах. Потому что, например, не на всех почтовых серверах (особенно в каких-нибудь солидных конторах, где админы работают по принципу 'не сделать бы хуже') стоят достаточно свежие версии OpenSSL, но при этом в настройках у этих серверов написано, что передаче сообщения надо пробовать делать STARTTLS.
В итоге, они видят возможность сделать STARTTLS в представлении сервера, дают такую команду и ломаются при отправке с сообщением о несовместимости. Сообщения к вам не доходят, а отправляющий сервер не пытается отправить сообщение без STARTTLS. Вы не получаете важных писем и очень долго этого не замечаете.
Вот. Так что, для своих внутренних нужд вроде openvpn или там сертефикатов для imap или jabber эллиптические кривые можно использовать, но для всяких публичных сервисов, лучше не стоит.
В итоге, они видят возможность сделать STARTTLS в представлении сервера, дают такую команду и ломаются при отправке с сообщением о несовместимости. Сообщения к вам не доходят, а отправляющий сервер не пытается отправить сообщение без STARTTLS. Вы не получаете важных писем и очень долго этого не замечаете.
Вот. Так что, для своих внутренних нужд вроде openvpn или там сертефикатов для imap или jabber эллиптические кривые можно использовать, но для всяких публичных сервисов, лучше не стоит.
годная и интересная статья. ради таких и читаю хабр :)
Хм.
А что известно про криптостойкость этого самого ECC? Wiki что-то молчит. Были ли вообще какие-то специальные исследования на эту тему?
А что известно про криптостойкость этого самого ECC? Wiki что-то молчит. Были ли вообще какие-то специальные исследования на эту тему?
В русской вики написано, 112 бит — наибольший публично взломанный ключ при нечетной характеристике поля, 109 для характеристики 2. Время — 3.5 мес. и 17 мес. соответственно.
Я как-то ни разу не впечатлён такой стойкостью. А это его ещё не начали серьёзно ломать.
Ну, за 3 года 768-, битный RSA тоже расшифровали. Я думаю сложность расшифровки растет экспоненциально, так со стойкостью, а думаю, всё нормально. Тем более, что рекомендуется выбирать ключи >160 бит и скорость алгоритма, как я понял, намного выше, так что можно без проблем генерировать и длинные ключи.
Хотелось бы также увидеть сравнения по производительности и длине ключа с алгоритмом ГОСТ Р 34.10-2001, также основанным на эллипт. кривых, который для нашей страны является актуальным (тем более в OpenSSL он также присутствует с последних версий, однако не поддерживается стандартным образом в ОС и браузерах).
Также было бы неплохо представить сравнительные графики производительности по генерации ключевой пары, цифровой подписи и проверки, учитывая разные длины ключей и разные объемы подписываемой информации.
Также было бы неплохо представить сравнительные графики производительности по генерации ключевой пары, цифровой подписи и проверки, учитывая разные длины ключей и разные объемы подписываемой информации.
Хм, а не известно, как с поддержкой данного алгоритма у jabber-клиентов?
Если они используют OpenSSL, то вполне возможно, что да. Надо смотреть
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Генерируем цепочку сертификатов с эллиптическими кривыми при помощи OpenSSL