Соглашение о ключах Диффи Хеллмана с использованием ключей RSA?

Я хочу, чтобы две стороны согласовали один и тот же секретный ключ, используя свои открытый и закрытый ключи. Я не хочу, чтобы они общались. Я думаю, method(A.privKey, B.pubKey) дает то же число, что и method(B.privKey, A.pubKey)

Мне было интересно, работает ли алгоритм согласования ключей Диффи-Хеллмана в Java, когда вы используете KeyPairGenerator.getInstance("RSA")

Если да, то как я могу это сделать? Или мне нужно использовать KeyPairGenerator.getInstance("DH")?

Я искал в Интернете и не могу найти ответ.


person vrwim    schedule 28.04.2014    source источник


Ответы (2)


Математика, лежащая в основе Diffie-Hellman и RSA, достаточно различается, поэтому ключ RSA не может работать для DH.

Диффи-Хеллман

DH - это обмен ключами, он создает общий ключ из двух пар ключей. Он не шифрует данные напрямую. (Но легко построить шифрование, комбинируя DH с симметричным шифрованием).

Обе стороны договариваются о группе, в простейшем случае, определяемой g и p, где p - безопасное простое число.

Закрытый ключ - это просто число a, соответствующий открытый ключ A - это g^a mod p. Общий ключ может быть вычислен, поскольку возведение в степень коммутативно, поэтому

A^b = (g^a)^b = g^(ab) = (g^b)^a = B^a

Для этого обе пары ключей должны использовать одну и ту же группу. Самый простой способ добиться этого - выбрать одну конкретную группу и жестко закодировать ее в свой протокол / приложение.

ЮАР

RSA шифрует сообщение m открытым ключом, создавая зашифрованный текст c. Таким образом, он использует только одну пару ключей, пару ключей получателя.

Закрытый ключ - это фиксированная экспонента e (обычно 65537) и пара простых чисел p и q.

Соответствующий открытый ключ e и произведение простых чисел n = p * q.

Шифрование происходит путем вычисления c = m^e mod n, которое можно уважать, только если вы знаете p и q, но не если вы знаете только n.

Сравнение

Вы можете создать общий ключ с помощью RSA, сгенерировав случайный ключ в качестве отправителя и зашифровав его с помощью открытого ключа получателя. Это работает для шифрования сообщения получателю без взаимодействия. Но он не аутентифицирует отправителя, поскольку они могут управлять общим ключом. Итак, если вы не можете использовать RSA для достижения неинтерактивной отрицательной аутентификации. Но вы можете подписать сообщение с помощью RSA (но не используйте одну и ту же пару ключей для подписи и шифрования), что даст вам неотвратимую аутентификацию.

person CodesInChaos    schedule 28.04.2014

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

alice -> bob: alice.pub
bob -> alice: bob.pub
alice: a = (alice.priv * bob.pub)
bob: b = (bob.priv * alice.pub)

Вверх и вниз - это обратные клавиши. Это согласованный асимметричный секретный ключ. Алиса может применить a, а Боб - b. Когда они оба применяются, они отменяются. Итак, это соглашение об асимметричном ключе. Если бы мы попытались сделать это с помощью RSA, Алиса или Боб знали бы оба ключа. Но при этом сообщения для Боба определенно создавала Алиса, и наоборот.

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

Это очень похоже на обмен Диффи-Хеллмана в том, что мы согласовываем общий секрет. Разница в том, что когда мы шифруем на другую сторону, даже мы не можем расшифровать его позже.

person Rob    schedule 12.12.2015