Что заставляет ECDH полагаться только на два открытых ключа?

У меня есть основной вопрос об ECDH (эллиптическая кривая Диффи-Хеллмана).

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

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


cryptography elliptic-curve ecdh
person Lolita Gherp    schedule 04.10.2018    source источник
comment
Открытый ключ генерируется из закрытого ключа, но получение закрытого ключа из открытого ключа представляет собой сложную проблему, которая делает схему полезным криптографическим примитивом. Вы путаете термины здесь. Закрытый ключ(и) уникален для стороны и известен только ей. Они обмениваются открытыми ключами и получают общий общий секретный ключ, а не закрытый ключ.   -  person President James K. Polk    schedule 04.10.2018

Ответы (3)


arrow_upward
5
arrow_downward

Обмен ключами ECDH не используется для создания закрытого ключа, а для вычисления общего секрета. Это выполняется каждой стороной, которая сначала создает свою собственную пару открытого/закрытого ключа EC, а затем использует свой собственный закрытый ключ EC и открытый ключ EC другой стороны для выполнения вычисления ECDH, в результате чего обе стороны вычисляют одно и то же значение.

Первым шагом для каждого пользователя является создание пары открытого и закрытого ключей EC. Предположим, что Алиса и Боб генерируют пару ключей. В этом примере закрытый ключ EC Алисы — x, ее открытый ключ EC — xC, закрытый ключ EC Боба — y, а его открытый ключ EC — yC. Затем они используются для получения ключа ECDH.

Затем Алиса использует свой закрытый ключ EC и открытый ключ EC Боба для вычисления x * yC == xyC. Точно так же Боб использует свой закрытый ключ EC и открытый ключ EC Алисы для вычисления y * xC == xyC. Тогда xyC — это общий секрет, созданный алгоритмом ECDH.

person dbush    schedule 04.10.2018
comment
Единственным обменом ключами для ECDH является обмен открытыми ключами. Как только каждая сторона вычисляет один и тот же закрытый ключ, он используется в качестве ключа для совершенно другого алгоритма. Закрытый ключ ECDH никогда не обменивается, потому что в его обмене нет необходимости - ведь он уже есть у обеих сторон - person Lolita Gherp; 04.10.2018
comment
@LolitaGherp Точно. Каждая сторона получает открытый ключ другой стороны и использует его вместе со своим закрытым ключом для вычисления общего секрета. - person dbush; 04.10.2018
comment
Так что вопрос остается. Где безопасность, когда третья сторона может перехватить оба открытых ключа? - person Lolita Gherp; 04.10.2018
comment
@LolitaGherp Смотрите мою правку. Кажется, вы запутались в том, что на самом деле делает ECDH. - person dbush; 04.10.2018
comment
Мне не хватает вашего объяснения, например. Алиса использует свой закрытый ключ и открытый ключ Боба для вычисления .... неверно. Должно быть, Алиса использует свой открытый ключ и открытый ключ Боба для вычисления закрытого ключа. - person Lolita Gherp; 04.10.2018
comment
@LolitaGherp Нет, это не правильно. Каждый пользователь использует свой собственный закрытый ключ и открытый ключ другого пользователя для вычисления общего секрета. Второй абзац в ответе объясняет более подробно. - person dbush; 04.10.2018
comment
Я использую код по адресу docs.microsoft.com/en-us/dotnet/api/ ясно показывает, что каждая сторона генерирует свой собственный открытый ключ, здесь я имею в виду, что закрытый ключ совпадает с общим секретным ключом, закрытый ключ не используется для генерации секретного ключа, потому что оба являются одним и тем же, только два открытых ключа используются в качестве входных данных - person Lolita Gherp; 04.10.2018
comment
@LolitaGherp Этот API скрывает детали ECDH. См. это для получения дополнительной информации. - person dbush; 04.10.2018
comment
Я не могу позволить себе роскошь анализировать сухую математику из-за нехватки времени. Мне нужны реальные образцы кода, чтобы очень быстро разобраться. - person Lolita Gherp; 04.10.2018
comment
@LolitaGherp Дело в том, что обе стороны генерируют пару открытого и закрытого ключей EC, и каждая использует свой закрытый ключ EC и открытый ключ EC другой стороны для обмена ключами ECDH. Код, который вы связали, делает это, даже если он явно не указывает это. - person dbush; 04.10.2018
comment
Код не делает ничего подобного! Каждая сторона выделяет свой собственный алгоритм типа ECDiffieHellmanKeyDerivationFunction, который автоматически предоставляет открытый ключ. Затем они отправляют открытый ключ друг другу. Как только каждая сторона получает other_public_key, она вызывает CngKey.Import(other_public_key), который возвращает CngKey_object, используемый в качестве входных данных для algm.DeriveKeyMaterial(CngKey_object), который возвращает закрытый ключ, также известный как общий секрет. Нет обмена ключами, кроме обмена открытыми ключами. Закрытый ключ не используется для каких-либо вычислений. Закрытый ключ — это конечный результат, используемый в качестве входных данных для другого алгоритма. - person Lolita Gherp; 04.10.2018
comment
@LolitaGherp Первое, что делает код, это ECDiffieHellmanCng alice = new ECDiffieHellmanCng()). Если щелкнуть ссылку этого конструктора, появится сообщение Инициализирует новый экземпляр класса ECDiffieHellmanCng со случайной парой ключей. Таким образом, на самом деле создается пара открытого и закрытого ключей EC. Просто не очевидно, что это происходит. Не путайте закрытый ключ EC с общим секретом ECDH. - person dbush; 04.10.2018
comment
Что касается ECDiffieHellmanKeyDerivationFunction, то он берет необработанный общий секрет из ECDH и выполняет его хеширование для создания фактического используемого общего секрета. Это делается потому, что необработанный общий секрет не имеет достаточной энтропии во всех своих битах, и применение хэша создает эту энтропию. - person dbush; 04.10.2018
comment
Основная проблема здесь заключается в том, что ECDiffieHellmanCng не предоставляет параметры для повторной генерации PublicKey — по-видимому, это ключевой момент, означающий, что невозможно получить другой объект ECDiffieHellmanCng и получить тот же самый PublicKey. Вот почему третья сторона может перехватить два открытых ключа, которыми обмениваются две стороны, и при этом не сможет эмулировать любую из сторон для вычисления закрытого/секретного ключа. Независимо от того, какая пара случайных ключей генерируется внутри, важно то, что доступно извне, то есть один открытый ключ и один закрытый/секретный ключ, сгенерированные из обоих открытых ключей. - person Lolita Gherp; 04.10.2018
comment
@LolitaGherp ECDiffieHellmanCng позволяет вам извлечь ключ как объект CngKey с помощью свойства Key и установить ключ для нового объекта с помощью другого вызова конструктора. Что делает алгоритм безопасным, так это то, что, учитывая правильную кривую, вычислительно невозможно вычислить закрытый ключ EC из открытого ключа EC. - person dbush; 04.10.2018

arrow_upward
4
arrow_downward

ECDH не полагается только на открытые ключи; это только единственные компоненты, которые необходимо отправить. Вместо этого он зависит от двух пар открытый/закрытый ключ, сгенерированных обеими сторонами. Хитрость в соглашении о ключах Диффи-Хеллмана (DH) заключается в том, что вычисляется общий секрет с учетом закрытого ключа и открытого ключа другой стороны. Этот общий секрет идентичен с обеих сторон, если и только если используются правильные закрытый и открытый ключи.

Открытый и закрытый ключи пары связываются во время создания пары ключей; открытый ключ DH рассчитывается из базовой точки кривой и закрытого ключа. Эта конкретная связь между ключами требуется для вычисления одного и того же общего секрета. Для успешного выполнения этого вычисления также требуется, чтобы оба ключа использовали одни и те же параметры домена; другими словами, открытые ключи должны быть на одной кривой.

Разумеется, третья сторона/противник может скопировать открытый ключ любой из сторон. Однако это не поможет злоумышленнику, поскольку у него нет доступа ни к одному из сопровождающих закрытых ключей. Таким образом, никакая другая сторона, кроме тех, кто участвует в соглашении о ключах, не сможет вычислить один и тот же общий секрет; вам нужен один из закрытых ключей, чтобы сделать это.

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

SSL/TLS, например, в основном использует эфемерные (временные) ключи; Принимается любой открытый ключ ECDH. Это означает, что такая форма DH не предлагает аутентификацию вовлеченных сторон. Таким образом, атака «человек посередине» (MitM) возможна, если не используются другие меры аутентификации. TLS для использования в браузерах использует для этого сертификаты сервера/подпись сервера.

Но эта часть дает ответ на вопрос, который вы (пока) не задавали.

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

person Maarten Bodewes    schedule 04.10.2018
comment
Мой главный вопрос здесь заключается в том, как сторона S1 со своим собственным открытым ключом PK1 может получить открытый ключ PK2 от стороны S2 и использовать оба ключа для получения секретного ключа, который никакая другая сторона S3 не может сгенерировать, имея те же ключи PK1 и ПК2. Предположим, сторона S3 действует как сторона S1. Единственная проблема состоит в том, чтобы сгенерировать PK1, чтобы он мог вводить PK2. Вопрос в том, что такого безопасного в ECDH, что сторона S3 не может предложить параметры для генерации PK1 и тривиального ввода PK2. PK1 составляет всего 140 байт, алгоритм ECDH общедоступен, все входные параметры определены публично, даже фактические значения неизвестны. - person Lolita Gherp; 05.10.2018
comment
Вы не используете оба открытых ключа для получения секретного ключа. Вы используете свой закрытый ключ DH и открытый ключ DH другой стороны. Закрытый ключ неизвестен третьей стороне (S3). Только параметры DH (кривая) должны быть одинаковыми с обеих сторон. И общий секрет, конечно. - person Maarten Bodewes; 05.10.2018

arrow_upward
0
arrow_downward

Я почти уверен, что ключи ECDH генерируются между закрытым ключом одной стороны и открытым ключом другой стороны.

скажем, две стороны — Боб и Алиса, тогда, согласно схеме ECDH, это верно.

ECDH(bob_private_key, alice_public_key) == ECDH(bob_public_key, alice_private_key)

из-за чего никто, кроме Алисы и Боба, не может сгенерировать один и тот же ключ.

проверьте здесь реализацию в python, https://stackoverflow.com/a/52506717/1619003

@Maarten объяснил, что могло вас смутить, разницу между секретным ключом и закрытым ключом.

person GraphicalDot    schedule 04.10.2018
comment
Закрытый ключ ECDH может быть сгенерирован только из двух открытых ключей ECDH, а не наоборот. Когда у вас есть закрытый ключ ECDH, вы можете использовать его в качестве входных данных для совершенно другого алгоритма, такого как симметричный алгоритм. - person Lolita Gherp; 04.10.2018
comment
Понятия не имею, что вы здесь объясняете, я никогда ничего не говорил о создании пар открытого/закрытого ключей EC. - person GraphicalDot; 04.10.2018