Comments 29
Интересно, почему во многих англоязычных описаниях алгоритмов и вообще многого используются имена Алиса и Боб? Меня это с детства волнует :) Кто ввёл эту традицию?
UFO just landed and posted this here
Объясните подробнее как данный метод предотвращает от атаки man in the middle?
Насколько я понял то на начальном этапе происходит обмен ключами, и если мы перехватили передачу ключей, подменили их на свои то получается всё та же атака man in the middle…
Насколько я понял то на начальном этапе происходит обмен ключами, и если мы перехватили передачу ключей, подменили их на свои то получается всё та же атака man in the middle…
Т.к. используются private keys, которых нет у злоумышленника…
На начальном этапе происходит обмен открытыми ключами, которые должны быть заверены центром сертификации или входят в сеть доверия. Только в таком случае, когда пользователи уверены, что имеют действительные ключи друг друга, имеет смысл применять протокол.
Почему в таком случае не доверить генерацию ключа например Алисе и не отправить его Бобу, зашифрованным его открытым ключом? Потому что Боб опасается, что Алисе будет нужно для каких-либо целей сгенерировать слабый ключ и он не может ей полностью доверять в этом вопросе.
Почему в таком случае не доверить генерацию ключа например Алисе и не отправить его Бобу, зашифрованным его открытым ключом? Потому что Боб опасается, что Алисе будет нужно для каких-либо целей сгенерировать слабый ключ и он не может ей полностью доверять в этом вопросе.
Большое спасибо, только сегодня с этим MQV ковырялся в BouncyCastle) теперь понятно что к чему.
А вот вопрос такой: почему нельзя Алисе просто сгенерировать случайное число, зашифровать его открытым ключом Боба, и они вместе будут использовать это число в качестве ключа. Ну. Или напополам разделить эту генерацию. Зачем вот такой вот нетривиальный протокол?
Нельзя потому, что Боб не доверяет, что Алисе хватит компетентности сгенерировать безопасный секретный ключ. Аналогичное относится и в обратном направление, т.е. Алиса не доверяет полностью генерацию Бобу. Поэтому и используют вот такой двусторонний метод.
А что мешает Алисе и Бобу сгенерировать по половинке ключа, сконкатенировать/сложить побитово/ещё как-то их преобразовать и получить общий ключ?
Просто… DH он же чем хорош? Криптоканал устанавливается без всякой априорных знаний о переписывающихся. Не надо никакх открытых и закрытых ключей. Но когда они уже есть, то зачем придумывать ещё один протокол, если секретами для потокового шифрования можно обмениваться при помощи уже существующей инфраструктуры из ассиметричных алгоритмов? Ведь, чем больше кода учавствует в работе, тем вероятность сбоя и потери секретности выше.
Поэтому и возникает мой вопрос, чем таки MQV лучше простого обмена случайными числами по ассиметричному криптоканалу?
Поэтому и возникает мой вопрос, чем таки MQV лучше простого обмена случайными числами по ассиметричному криптоканалу?
Так попробую объяснить. Я не хочу, чтобы даже половину моего секретного ключа, которым я буду шифровать очень важные сведения, генерировали без моего участия, я сам хочу наблюдать и контролировать процесс, чтобы осознавать, что к делу подходит человек осознающий всю ответственность, а не какая-то условная Алиса. А в таком случае MQV незаменим.
Тогда отсюда вытекают следующие вопросы. Как Боб получит ключ? Что это за ключ, если ни один параметр не будет секретным? Хорошо, предположим первых вопросов нет, тогда не могу понять, а зачем Алиса будет вообще что-то генерировать, если это никуда не передается? :)
PS: Новый топик для Дик — Крипто алгоритм — сделай сам!
PS: Новый топик для Дик — Крипто алгоритм — сделай сам!
Так эмс… Ключ распространяется по защищённому ассиметричным алгоритмом каналу. А насчёт секретных параметров не понял… Речь же идёт о ключе для симметричного алгоритма, он у Боба и Алисы должен быть одинаковым.
Ну так если канал защищенный, то ключ можно передавать и в явном виде! :) DH (и MQV) — это же алгоритм обмена ключами, не более!
Ну. А для работы MQV тоже надо обменятся открытыми ключами. Так зачем? Если мы говорим, что есть возможность обменяться открытыми ключами, ну так сразу и обмениваться ECDSA-ключами… Зачем ещё какой-то алгоритм включать в процесс общения? Ведь, больше кода — больше дыр.
Бррр… Давайте вместе разберемся, для согласования параметров криптосистемы используется алгоритм реализующий метод экспоненциального ключевого обмена DH, для того чтобы исключить атак man-in-the-middle используется цифровая подпись DSA, RSA или реализация DSA для эллиптических кривых, ключи цифровой подписи только производят верификацию подписи, ничего не шифруют, для шифрации используются ключ, который был получен сторонами в результате DH. Вот, где-то как-то в первом приближении.
Спасибо автору за труд. Единственное, что l не равна длине сообщения деленное на два, а сопоставимо с ней.
Для этой штуки надо каждый раз еще генерировать т.н. эфемерные дополнительные ключи, с помощью которых, произведя вычисления с основными ключами, и получается общий секрет. Как то не очень хорошо получается. В обычной ситуации мне достаточно знать открытый ключ собеседника, а тут еще и дополнительный обмен эфемерными ключами надо устраивать…
Согласен, несколько громоздко. Но ведь и классический DH тоже работает на эфемерных ключах. Так, что в этом плане DH нисколько не лучше.
Если и у меня и у собеседника УЖЕ есть открытые ключи друг друга о которых мы достоверно знаем, что они пренадлежат нам, то мы безо всяких эфемерных ключей с помощью ECDH можем посчитать общий секрет по всем известной формуле и использовать его сколь угодно долго. Не обязательно же каждый раз разный секрет юзать, для этого соль придумали.
Я вот к чему. Если рассмотреть немгновенную систему обмена информацией, в которой «адресом» является хэш от открытого ключа, вычисляемый «на лету», то мы не сможем с помощью MQV отправить сообщение адресату, открытый ключ которого у нас есть. Так как нам надо еще от него сессионный открытый ключ получить (и свой передать). А с обычным ECDH мы считаем в одну строчку общий секрет, шифруем им мессагу и отправляем будучи уверенными что оно расшифруется без проблем.
Я вот к чему. Если рассмотреть немгновенную систему обмена информацией, в которой «адресом» является хэш от открытого ключа, вычисляемый «на лету», то мы не сможем с помощью MQV отправить сообщение адресату, открытый ключ которого у нас есть. Так как нам надо еще от него сессионный открытый ключ получить (и свой передать). А с обычным ECDH мы считаем в одну строчку общий секрет, шифруем им мессагу и отправляем будучи уверенными что оно расшифруется без проблем.
Да в этом случае использование MQV будет раздражать. И тут проще использовать DH. Но в случае, если две стороны протокола конченные параноики и боятся использовать секрет несколько раз даже с солью? Одним словом всегда есть варианты и в зависимости от ситуации можно выбирать то или иное решение.
Ага, например использовать ECDH для доставки «оффлайновых» сообщений, а MQV для варианта, когда собеседник на том конце сокета.
Кстати, там что то про атаки на него было, я не очень разобрал. Оно в первоначальной реализации было вроде как с дырой, и потом его аж 2 раза апдейтили. Первый раз до HMQV, а потом до FHMQV. Не зря «ECMQV has been dropped from the National Security Agency's Suite B set of cryptographic standards.»
Кстати, там что то про атаки на него было, я не очень разобрал. Оно в первоначальной реализации было вроде как с дырой, и потом его аж 2 раза апдейтили. Первый раз до HMQV, а потом до FHMQV. Не зря «ECMQV has been dropped from the National Security Agency's Suite B set of cryptographic standards.»
Sign up to leave a comment.
Протокол MQV — старый добрый Диффи-Хеллман, но не совсем