Обновить
224
0.2
Алексей @NeverWalkAloner

Пользователь

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

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

А про самую простую атаку заинтриговали.
Смысл как раз таки в том, что несмотря на насквозь дырявый протокол, уязвимый как к активным, так и к пассивным атакам вам всё равно надо использовать рессурсоемкий брут-форс для взлома. И все это из-за того, что задача изначально была поставлена на невыгодных условиях.
Согласен с автором.
Дуров действительно сморозил какую-то фигню. В криптографии есть такое понятие, как «Ханаанский бальзам», шарлатанское снадобье выдаваемое за абсолютную панацею.
В качестве одного из признаков «Ханаанского бальзама» Брюс Шнайер указывает наличие награды за взлом и пишет следующее:
Объявление приза за взлом системы защиты вовсе не дает гарантии ее невзламываемости, и, как правило, означает, что разработчики не понимают, что следует сделать, чтобы показать, что система хорошо защищена.

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

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

Это подводит нас к началу нашей дискуссии. А именно к тому, что ключ не прошедший аутентификацию(PKI или другой метод) не может служить для аутентификации субьекта.
Почему до безумия? Все правильно написали выше. Без pki ssh лишается смысла. Т.к. любой может прислать вам неизвестный открытый ключ и сказать что это ключ от сервера. Поэтому к асимметричной криптографии нужен дополнительный инструмент аутентификации. Сами по себе ключи не способны ни аутентифицировать вас ни идентифицировать.
Почему сразу бесполезной? Можно использовать в корпоративных сетях, где сервер может выполнять роль Трента.
А про отличие от стандартной PKI с сертификатами. Оно налицо. Процедура аутентификации сокращается до одного шага. Остается только выдача ключа Алисе Трентом. Никаких пересылок сертификатов и их проверок.
Ну так как, объясните каким образом криптография с открытым ключом решает проблему аутентификации без использования PKI?
Добавлять к имени дату рождения например. Проблемы конечно есть но они решаемы. В теории очень красивая система получилась.
Предполагается что Боб хочет написать письмо человеку с именем Алиса. Он не заморачивается насчет ключей. Просто использует ее имя — ID.
Эм… это вы что то путаете. Сама по себе асимметриная криптография не решает ни ту ни другую проблему. А вот PKI да решает проблему аутентификации.
Пожалуйста!:)
Спасибо вам за отзыв. Всегда приятно знать, что твоя работа оказалась кому то полезной.
Я имел в виду вот что. Если в качестве seed использовать каждый раз рэндом тогда последовательность нельзя будет повторить, соответственно для поточных шифров этот вариант не годится.
Да, это хороший вариант если у вас нет необходимости генерировать большие последовательности, как в случаях с поточными шифрами например.
Спасибо за интересную статью.
У меня вопрос появился. Так как при накоплении достаточной энтропии происходит постоянное обновление внутреннего ключа, значит если скормишь один и тот же seed получатся разные последовательности? Получается fortuna нельзя использовать в качестве классического поточного шифра?
Спасибо за замечание. Я в описании псевдокода последний шаг пропустил.
Дьявол кроется в деталях:) Хотя ты прав конечно.
Как там фортуна кстати, не решился еще?
Ну почему же дико? Оттого что этот же список использует другой софт уязвимость не становится менее опасной. Я вообще прошу абстрагироваться от конкретных решений. Android не более чем иллюстрацию того, что пора проститься уже с TLS 1.0.

Информация

В рейтинге
2 734-й
Зарегистрирован
Активность

Специализация

Бэкенд разработчик
Старший
Python
Docker
PostgreSQL
Git
ООП
Английский язык
Django
RabbitMQ
FastAPI
Asyncio