Pull to refresh
219
0
Алексей @NeverWalkAloner

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

Send message
Так попробую объяснить. Я не хочу, чтобы даже половину моего секретного ключа, которым я буду шифровать очень важные сведения, генерировали без моего участия, я сам хочу наблюдать и контролировать процесс, чтобы осознавать, что к делу подходит человек осознающий всю ответственность, а не какая-то условная Алиса. А в таком случае MQV незаменим.
Тоже читал об этом. Там все как-то совсем непонятно, вроде как на основании принципов доказуемой стойкости были сделаны выводы о слабости протокола, потом эти выводы были опровергнуты и выяснилось, что HMQV оказался даже слабее самого MQV. Ну и насколько я знаю так на этом все и заглохло.
Да в этом случае использование MQV будет раздражать. И тут проще использовать DH. Но в случае, если две стороны протокола конченные параноики и боятся использовать секрет несколько раз даже с солью? Одним словом всегда есть варианты и в зависимости от ситуации можно выбирать то или иное решение.
Согласен, несколько громоздко. Но ведь и классический DH тоже работает на эфемерных ключах. Так, что в этом плане DH нисколько не лучше.
Вы не правы. l именно равна длине сообщения деленное на два. Посмотрите внимательно, l это всего-навсего степень двойки в получении чисел S и T. Использовать для этой цели большое число размерностью скажем в 80 бит не имеет никакого смысла.
На начальном этапе происходит обмен открытыми ключами, которые должны быть заверены центром сертификации или входят в сеть доверия. Только в таком случае, когда пользователи уверены, что имеют действительные ключи друг друга, имеет смысл применять протокол.
Почему в таком случае не доверить генерацию ключа например Алисе и не отправить его Бобу, зашифрованным его открытым ключом? Потому что Боб опасается, что Алисе будет нужно для каких-либо целей сгенерировать слабый ключ и он не может ей полностью доверять в этом вопросе.
Нельзя потому, что Боб не доверяет, что Алисе хватит компетентности сгенерировать безопасный секретный ключ. Аналогичное относится и в обратном направление, т.е. Алиса не доверяет полностью генерацию Бобу. Поэтому и используют вот такой двусторонний метод.
Согласен Пратчетт эталон жанра.
Только если объективно, эти два первых произведения Пратчетта у него пожалуй самые слабые, т.к. первоначально они задумывались как чистая пародия на весь жанр фэнтези и фирменный пратчеттовский стиль в них еще не прослеживается. Но зато все последующие серии это нечто. Особенно мне нравится ночная стража и философская(дане несколько мрачноватая) серия про Смерть.
PS а автору спасибо, надо будет почитать.
Интересная идея. Тоже хочу поучавствовать.
Вообще в спецификации рекомендуется использовать SHA-1 или RIPEMD-160. Я так понимаю что в случае увеличения размера ключа применяется какая-то хитрая схема наподобие:
H(x)=SHA(<1>||x)||SHA(<2>||x)…
где <1> и <2> части по, например, 32 бита исходного X.
Вот здесь(pdf) подробно написано.
Ни в коем не пытался выставить RSA в плохом свете. Просто хотел показать, что в криптографии порой учитываются даже самые невероятные ситуации. И продумывается защита от их возникновения. А также то, что даже самые сильные алгоритмы в связи с развитием криптографии, как науки, нуждаются в доработках и усовершенствованиях.
PS добавил источники.
Спасибо, исправил.
12 ...
15

Information

Rating
Does not participate
Registered
Activity