Чому шифрування RSA стало популярним для обміну ключами?


16

Це м'яке питання. Я не знаю багато про криптографію або її історію, але здається, що для RSA загальним використанням є обмін ключами, шифруючи симетричний ключ для надсилання більш тривалого повідомлення (наприклад, опис iMessage тут ). Хіба це не те, для чого потрібен обмін ключами Діффі-Гелмана, який є старшим (і мені здається, простішим)? Дивлячись на Вікіпедію, вони також були запатентовані, тому це не було б відповідальним за вибір.

Щоб було зрозуміло, я не запитую, чи теоретично важливо, щоб криптографія відкритого ключа була можливою. Я запитую, чому це стало стандартним методом на практиці для здійснення обміну ключами. (Некриптографу DH виглядає простіше у виконанні, а також не пов'язаний з деталями використовуваної групи.)



3
RSA також може використовуватися для захищеної передачі ключів у випадках, коли інтерактивний протокол обміну ключами, наприклад DH, неможливий, наприклад, коли доступна лише одностороння зв'язок або коли тривалість зв'язку в оборотному режимі надмірна. Використовуйте випадки, коли зашифроване повідомлення електронної пошти сприяє подібним підходам, оскільки комп'ютер приймача може не бути підключений до Інтернету в той момент, коли ви хочете надіслати повідомлення, тому не може брати участь в інтерактивному обміні ключами.
Кевін Кеткарт

Ви запитуєте, чому він став популярним для обміну ключами або взагалі?
OrangeDog

@KevinCathcart DH не обов'язково інтерактивний. Відправник може створити пару ключів одноразового використання та надіслати відкритий ключ уздовж повідомлення. Цей підхід є основою шифрування ECIES / DLIES та ElGamal. Він має невеликий розмір накладних витрат (128 байт для 1024-бітної клавіші).
CodesInChaos,

@CodesInChaos: Але жоден з них не є алгоритмами обміну ключами. Після того, як ви перейшли від обміну ключами до повноцінної криптографії відкритого ключа, вибір основної важкої для зворотної проблеми проблеми не впливає на такі оперативні проблеми, як забезпечення того, що відправник має копію відкритого ключа одержувача. Я зрозумів, що питання задається "Чому ми часто використовуємо криптовалюту з відкритим ключем для обміну ключами, а не просто алгоритм обміну ключами, який часто простіший?". Очевидно, що в основному будь-який алгоритм відкритого ключа може бути використаний для встановлення загальної таємниці за неінтерактивним каналом.
Кевін Кеткарт

Відповіді:


14

Сильних технічних причин немає. Ми могли б використовувати Diffie-Hellman (з відповідними підписами) так само, як і RSA.

То чому RSA? Наскільки я можу сказати, домінували нетехнічні історичні причини. RSA була запатентована, а за нею стояла компанія, що займається маркетингом та адвокацією для RSA. Також були хороші бібліотеки, і RSA було легко зрозуміти і знайоме розробникам. З цієї причини було обрано RSA, і коли він став популярним вибором, він залишився таким шляхом через інерцію.

Цього дня головним рушієм, який спричинив збільшення використання Diffie-Hellman, є прагнення до ідеальної таємниці вперед, що легко досягти за допомогою Diffie-Hellman, але повільніше з RSA.

Між іншим: це обмін ключами Diffie-Hellman, а не обмін секретами Diffie-Hellman. Таємний обмін - це зовсім інше.


2
Я думав, патенти є більшою причиною уникати RSA?
користувач1686

@гравності, яка залежить від того, як поводиться патентний власник; і покоління тому власники технічного патенту взагалі не ганьбили себе через масштабні та тривалі закони, настільки, наскільки це відбувалося під час війн смартфонів чи масових патентів малих компаній.
Дан вигадує Firelight

10

У Diffie-Hellman відсутня важлива особливість: аутентифікація. Ви знаєте, що ділитеся секретом з кимось, але ви не можете знати, чи це одержувач, чи чоловік у середині. З RSA у вас можуть бути кілька надійних сторін, які зберігають відкриті ключі. Якщо ви хочете підключитися до свого банку, ви можете попросити довірену сторону (скажімо Verisign) щодо відкритого ключа банку, оскільки у вас вже є відкритий ключ довіреної сторони на вашому комп’ютері. Тому ви знаєте, що ділитеся секретом зі своїм банком.

З Diffie-Hellman, коли ви створюєте секрет у своєму банку, ви можете насправді створити секрет із людиною посередині (MITM), яка також створить його з вашим банком, і він просто повинен перевести з одного ключа шифрування на інший залишається невидимим (при цьому зможе прочитати все спілкування).


Звичайно, ви можете використовувати RSA для аутентифікації, а потім обміну ключами DH.
OrangeDog

4
pк=гскмогp

@kasperd: Я здивований, що в ньому стільки голосів.
Луї

1
Ви можете використовувати довгострокові ключі Diffie-Hellman для аутентифікації (дивіться на CurveCP для прикладу протоколу), або ви можете комбінувати DH з підписами DSA / Schnorr / ElGamal (які поділяють багато основної математики з DH), як і ви можете поєднати шифрування RSA з підписами RSA.
CodesInChaos,

-2

Як згадувалося раніше, алгоритм RSA не є набагато кращим, ніж Діффі-Хеллман, останньому просто не вистачає автентичності, і обидва алгоритми залежать від труднощів у пошуку дискретних логарифмів, настільки безпечних, що вони обоє досить схожі.


2
Дякую за внесок. Однак усе, що ви говорите, вже висвітлено в інших відповідях. Ми хотіли б, щоб ви відповідали на запитання, на які ще немає гарних відповідей, а не дублювати існуючі відповіді. Крім того, RSA залежить від складності проблеми факторингу (і строго кажучи про проблему RSA), а не від дискретного логарифму як такого, тоді як Diffie-Hellman - це більш класична дискретна система, заснована на журналі (строго кажучи, вона покладається на припущення DDH ).
DW

-3

У цьому є темна сторона, яку неможливо не помітити.
Справа в тому, що ОДА кооперовано АНБ.
АНБ посадив задній проріз у циліндрі Еліптична крива, який він постачав до РДА.
http://www.intelligence-world.org/nsa-infiltrated-rsa-security-more-deeply-than-thought-study/


1
Ця відповідь є некогерентною. Криптографія еліптичної кривої відрізняється від RSA. Таким чином, задній простір криптовалюти в еліптичній кривій не загрожує RSA. Ця відповідь просто неправильна - немає такої темної сторони.
DW
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.