Яка різниця між шифруванням та підписом в асиметричному шифруванні?


296

Чим відрізняється шифрування деяких даних від підписання деяких даних (за допомогою RSA)?

Чи просто повертається роль публічно-приватних ключів?

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

Чи підписання корисно в цьому сценарії?

Відповіді:


440

Під час шифрування ви використовуєте їх відкритий ключ для написання повідомлення, а вони використовують його приватний ключ для його читання.

Підписуючи, ви використовуєте свій приватний ключ, щоб написати підпис повідомлення, і вони використовують ваш відкритий ключ, щоб перевірити, чи справді це ваш.

Я хочу використовувати свій приватний ключ для генерування повідомлень, щоб тільки я міг бути відправником.

Я хочу, щоб мій відкритий ключ використовувався для читання повідомлень, і мені байдуже, хто їх читає

Це підпис , це робиться за допомогою приватного ключа.

Я хочу мати можливість зашифрувати певну інформацію та використовувати її як ключ продукту для мого програмного забезпечення.

Мені байдуже лише те, що я єдиний, хто може їх створити.

Якщо вам потрібно це знати лише собі, вам не потрібно возитися з ключами, щоб це зробити. Ви можете просто генерувати випадкові дані та зберігати їх у базі даних.

Але якщо ви хочете, щоб люди знали, що ключі справді ваші, вам потрібно генерувати випадкові дані, зберігати в ньому базу даних та підписувати її своїм ключем.

Я хотів би включити свій відкритий ключ у своє програмне забезпечення для розшифрування / зчитування підпису ключа.

Можливо, вам потрібно буде придбати сертифікат на ваш відкритий ключ у комерційного постачальника, наприклад Verisign або Thawte, щоб люди могли перевірити, що ніхто не підробляв ваше програмне забезпечення та замінили ваш відкритий ключ на їхній.


7
Технічно кажучи, коли ви говорите, що приватний ключ використовується для написання підпису повідомлення, ви говорите, що хеш повідомлення шифрується моїм приватним ключем?
Енді Ібанез

4
@AndyIbanez: те, що зашифроване ( дайджест ), може також включати часову позначку і трохи випадкової солі, але так, це суть цього.
Quassnoi

7
@Quassnoi Насправді, коли ми кажемо "підписати приватним ключем", це означає не "шифрувати", а натомість означає "розшифрувати". Підписати повідомлення грубо кажучи - це те саме, що розшифрувати приватним ключем, а в приймачі шифрувати відкритим ключем, таким чином хеш стане таким самим і його можна порівняти.
Джонні Віллер

5
@JohnnyWiller: як зазначено нижче @slim, математичне ядро ​​є однаковим як для функцій шифрування, так і для дешифрування. Вони не є окремими функціями, це одна і та ж функція f(key, message), така щоf(private, f(public, message)) === f(public, f(private, message)) === message
Quassnoi

2
@Honey ні, це не так. Генерація пари ключів безкоштовна. Вартість пов'язана з тим, щоб інші вважали, що підпис справді ваш. Для цього у вас є власний відкритий ключ, який ви раніше генерували безкоштовно, підписаний органом, який може або не може стягувати з вас гроші.
Quassnoi

143

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

Отже, досить просто побачити, як можна зашифрувати повідомлення за допомогою відкритого ключа одержувача , щоб отримувач міг розшифрувати його своїм приватним ключем.

Підпис є доказом того, що підписант має приватний ключ, який відповідає деякому відкритому ключу. Для цього достатньо буде зашифрувати повідомлення приватним ключем відправника та включити зашифровану версію поряд із версією простого тексту. Щоб перевірити відправника, розшифруйте зашифровану версію та переконайтеся, що вона є такою ж, як відкритий текст.

Звичайно, це означає, що ваше повідомлення не є секретним. Розшифрувати його може кожен, оскільки відкритий ключ добре відомий. Але коли вони це роблять, вони довели, що творець шифротексту має відповідний приватний ключ.

Однак це означає подвоєння розміру вашої передачі - простого тексту та шифротексту разом (якщо ви хочете, щоб люди, які не зацікавлені у підтвердженні підпису, читали повідомлення). Отже, замість цього, як правило, підпис створюється шляхом створення хешу простого тексту. Важливо, що підроблені хеші неможливо створити, тому використовуються криптографічні алгоритми хешу, такі як SHA-2.

Тому:

  • Щоб створити підпис, зробіть хеш з простого тексту, зашифруйте його своїм приватним ключем, додайте його поряд із відкритим текстом.
  • Щоб перевірити підпис, зробіть хеш із простого тексту, розшифруйте підпис відкритим ключем відправника, перевірте, чи обидва хеші однакові.

8
@headcode це стосується лише асиметричних ключів. Симетричні ключі не бувають парами.
струнка

3
Насправді це стосується лише ключів RSA. Наприклад, за допомогою ключів ECDSA можна тривіально генерувати відкритий ключ із приватного ключа, а приватний ключ - скалярний, тоді як відкритий ключ - координатна.
Девід Шварц

5
Як можна розшифрувати повідомлення за допомогою ПУБЛІЧНИХ ключів? Чи не розшифровані повідомлення лише приватними ключами?
daremkd

3
5 джерел, що суперечать цій відповіді 1 , 2 , 3 , 4 , 5
колись

6
Не довільно, кого ви називаєте державним та приватним. Ви можете створити відкритий ключ із приватного ключа, але ви не можете створити приватний ключ із відкритого ключа. Хіба це не велика різниця?
Грег Шміт

23

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

  1. Шифруйте дані, щоб розшифрувати та прочитати їх можуть лише уповноважені особи.
  2. Перевірте особу / автентифікацію відправника.

Обидві ці проблеми можна елегантно вирішити за допомогою криптографії відкритого ключа.

I. Шифрування та дешифрування даних

Аліса хоче надіслати повідомлення Бобу, яке ніхто не повинен мати змогу прочитати.

  • Аліса зашифровує повідомлення за допомогою відкритого ключа Боба та надсилає його наново.
  • Боб отримує повідомлення та розшифровує його за допомогою свого приватного ключа.

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

Тому якщо ви хочете надіслати мені повідомлення, ви повинні знати і використовувати мій відкритий ключ, який я вам надаю, і тільки я зможу розшифрувати повідомлення, оскільки я єдиний, хто має доступ до відповідного приватного ключа.

II. Підтвердження особи відправника (автентифікація)

Аліса хоче знову надіслати повідомлення Бобу. Проблема шифрування даних вирішується за допомогою вищевказаного методу.

Але що робити, якщо я сиджу між Алісою та Боб, представляючи себе як «Аліса» Боб і надсилаючи власне повідомлення Бобу замість того, щоб пересилати повідомлення, надіслане Алісою. Хоча я не можу розшифрувати та прочитати оригінальне повідомлення, надіслане Алісою (для цього потрібен доступ до приватного ключа Боба), я викрадаю всю розмову між ними.

Чи є спосіб, яким Боб може підтвердити, що повідомлення, які він отримує, насправді надсилає Аліса?

  • Аліса підписує повідомлення своїм приватним ключем і надсилає його. (На практиці те, що підписується, - хеш повідомлення, наприклад, SHA-256 або SHA-512.)
  • Боб отримує його та перевіряє за допомогою відкритого ключа Аліси. Оскільки відкритий ключ Аліси успішно перевірив повідомлення, Боб може зробити висновок, що повідомлення було підписане Алісою.

1
Отже, підписуючи повідомлення, чи підписуєте ви власне повідомлення чи зашифроване повідомлення?
FrostyStraw

21

Так, подумайте про підписання даних як надання власного воскового штампу, якого ніхто інший не має. Це робиться для досягнення цілісності та неприйняття . Шифрування настільки, що ніхто більше не може бачити дані. Це робиться для досягнення конфіденційності . Дивіться wikipedia http://en.wikipedia.org/wiki/Information_security#Key_concepts

Підпис - це хеш вашого повідомлення, підписаний за допомогою вашого приватного ключа.


16

Підписання створює "хеш" з вашим приватним ключем, який може бути підтверджений вашим відкритим ключем. Текст надсилається чітко.

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

Отже, використання клавіш не змінюється (інакше ваш приватний ключ більше не буде приватним!).


У звичайному асиметричному шифруванні шифрування здійснюється за допомогою відкритого ключа одержувачів, а не вашого приватного ключа.
mmcdole

Скучили , що це питання було конкретно про RSA , де використання ключів буде скасовано , і де він не ставить під загрозу закритий ключ.
Девід Шварц

8

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


1
Чи веб-браузери не шифрують довільні дані під час використання SSL?
Ян Варбуртон

2
@IanWarburton: Але вони не використовують для цього асиметричне шифрування. Фактичні передачі даних використовують симетричне шифрування за допомогою випадково згенерованого ключа сеансу.
Майкл Боргвардт

1
@IanWarburton: Ні, тому що обидва не обираються зловмисником. Небезпека полягає в шифруванні або підписанні чогось, що безпосередньо надається зловмисником, оскільки це може дуже навмисно створено, щоб розкрити інформацію про ваш приватний ключ, або навіть створити підписи, які здаються дійсними для того, що ви не мали наміру підписувати. Детальна інформація про те, як працює остання справа для RSA, знаходиться тут: crypto.stackexchange.com/questions/35644/…
Майкл Боргвардт

2
@IanWarburton: саме тому RSA вимагає прокладки, тому ви ніколи не шифруєте лише вибране повідомлення: en.wikipedia.org/wiki/… - але це дійсно операції, що включають приватний ключ (наприклад, підписання), які особливо вразливі від обраного введення.
Майкл Боргвардт

1
@IanWarburton Я не фахівець з криптографії, але, як я розумію, це не повинно викликати проблем.
Майкл Боргвардт

8

Підписання вказує, що ви справді є джерелом або ваучером для підписаного об'єкта. Хоча кожен може прочитати об’єкт.

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


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

5

Чим відрізняється шифрування деяких даних від підписання деяких даних (за допомогою RSA)?

Шифрування зберігає конфіденційність повідомлення ("деякі дані"), тоді як підписання забезпечує неповернення: тобто підписати його міг лише суб'єкт, який його підписав. Існують і функціональні відмінності; читати далі.

Чи просто повертається роль публічно-приватних ключів?

Абсолютно ні. Використання одних і тих же приватних ключів для підписання та розшифрування (або, аналогічно, одних і тих же відкритих ключів для перевірки та шифрування ) насувається, оскільки не слід змішувати цілі. Це не стільки математична проблема (RSA все ще має бути захищеною), але проблема з управлінням ключами , де, наприклад, ключ підпису повинен мати коротший термін роботи і містити більше захисту перед його використанням.

Для цього ж повідомлення слід використовувати приватний ключ відправника для підписання, а одержувачі - довірений відкритий ключ для шифрування. Зазвичай шифрування «знак-то-то» використовується, інакше супротивник може замінити підпис своїм. Так само ви повинні використовувати приватний ключ одержувача для розшифровки та надійний відкритий ключ відправника для перевірки.

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

Наприклад, я хочу використовувати свій приватний ключ для генерування повідомлень, щоб тільки я міг бути відправником.

Це властивість неповернення, яку можна досягти підписанням.

Я хочу, щоб мій відкритий ключ використовувався для читання повідомлень, і мені байдуже, хто їх читає.

Публічний ключ слід вважати відомим усім. Якщо ви хочете, щоб усі читали повідомлення, то ви просто не шифруєте їх.

Підпис, як правило, не впливатиме на зміст повідомлення. Повідомлення вважається окремим від підписів. Офіційно такі підписи відомі як "підписи з додатком", де в додатку є повідомлення. Це трохи дивне ім'я, оскільки повідомлення вважається важливішим, ніж підпис над ним, але так. Лише небагато підписів пропонують (часткове) відновлення повідомлення; вони більше не використовуються і зазвичай вважаються застарілими.

Зауважте, що протоколи підпису, такі як CMS, можуть розгорнути формат контейнера, що включає в себе і повідомлення, і підпис. У такому випадку вам потрібно спочатку дістати з контейнера повідомлення - все ще незашифроване - як розпакування файлу з простого архіву .zip. Тож повідомлення може бути прихованим від перегляду і не може бути безпосередньо використане в такому випадку.

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

Шифрування використовується для досягнення конфіденційності. У минулому покоління підписів RSA часто вважалося "шифруванням приватним ключем". Однак операції зовсім інші, як пояснено вище, і пізніші стандарти відчайдушно намагаються розділити шифрування та генерацію підписів.

Я хотів би включити свій відкритий ключ у своє програмне забезпечення для розшифрування / зчитування підпису ключа. Мені байдуже, хто може читати дані в ключі, мені байдуже лише те, що я єдиний перевіряється, хто може їх генерувати.

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

Наприклад, є Microsoft Authenticode. Магазини додатків, такі як магазин iStore та Android, можуть або не можуть використовувати підписи коду, але вони гарантують, що ваша програма не клонована або принаймні не клонована в магазині. Криптографія - це не завжди рішення.

Уникнути клонування / зміни коду взагалі набагато складніше, і ви б надійно знаходилися на території DRM, якщо підете цим шляхом.

Чи підписання корисно в цьому сценарії?

Так, абсолютно. Це, безумовно, може переконатися, що повідомлення були підписані лише вами, якщо є довіра до відкритого ключа. Якщо це може бути корисно для автентифікації вашого коду програми / інтегрованого відкритого ключа, повністю залежить від середовища, в якому ви очікуєте запустити код.


"У минулому покоління підписів RSA часто вважалося" шифруванням з приватним ключем ". Однак операції зовсім інші, як пояснено вище, і пізніші стандарти відчайдушно намагаються розділити шифрування та генерацію підписів". - це мені незрозуміло. Або KeyPair може бути pk або sk, і те, що одна шифрує, інше може розшифрувати. Якщо ми з цим погоджуємось, то як можна стверджувати, що підписання та шифрування відрізняються будь-яким значущим чином? Обидва шифрувати, а потім можна розшифрувати лише за допомогою іншого ключа. Я бачив посилання на функції підписання, це пов’язано?
Морган

Єдине, що мені відомо про функцію підписання, - це хешування повідомлення перед шифруванням.
Морган

4

У вашому сценарії ви не шифруєте значення асиметричного шифрування; Я вважаю за краще це "кодувати".

Таким чином, ви кодуєте свої дані в деяке двійкове представлення, а потім підписуєтесь своїм приватним ключем. Якщо ви не можете підтвердити підпис за допомогою свого відкритого ключа, ви знаєте, що підписані дані не створюються вашим приватним ключем. ("перевірка" означає, що непідписані дані не мають значення)


2

Функціонально ви використовуєте шифрування відкритого / приватного ключа, щоб переконатися, що лише отримувач може прочитати ваше повідомлення. Повідомлення шифрується за допомогою відкритого ключа приймача та розшифровується за допомогою приватного ключа приймача.

Підписом можна скористатись, щоб отримувач дізнався, що ви створили повідомлення, і воно не змінилося під час передачі. Підпис повідомлення здійснюється за допомогою власного приватного ключа. Одержувач може використовувати ваш відкритий ключ, щоб перевірити, чи не було підроблено повідомлення.

Що стосується використовуваного алгоритму: він включає в себе односторонню функцію, див., Наприклад, wikipedia . Одним із перших таких алгоритмів використовують великі прості числа, але з того часу було винайдено більше односторонніх функцій.

Шукайте "Боб", "Аліса" та "Меллорі", щоб знайти статті введення в Інтернеті.


Чи можете ви прокоментувати мій випадок використання? Я хочу використовувати приватний ключ для шифрування та відкритий ключ, щоб дозволити розшифрувати будь-кого та кожного.
mmcdole

1
Неправда, що все асиметричне шифрування базується на простих числах, це лише найвідоміший приклад (RSA); існують і інші методи, такі як криптографія еліптичної кривої.
Майкл Боргвардт

"Повідомлення шифрується, а потім шифрується за допомогою відкритого ключа приймача." Це речення просто не має сенсу, або, принаймні, воно потребує подальшого пояснення. "зашифровано, потім зашифровано" ???
Маартен

Ти забув Трент! :)
Доджо

1

Відповідаючи на це запитання у змісті, що запитуючим було намір використовувати рішення для ліцензування програмного забезпечення, такі вимоги:

  1. Жоден третій учасник не може видавати ліцензійний ключ після розгортання програми
  2. Вміст програмного ключа не повинен бути захищеним
  3. Програмний ключ не читабельний для людини

Цифровий підпис вирішить цю проблему, оскільки необроблені дані, що робить ключ, можуть бути підписані приватним ключем, що робить його не читабельним для людини, але може бути розшифровано при зворотному проектуванні. Але приватний ключ безпечний, це означає, що ніхто не зможе зробити ліцензії на ваше програмне забезпечення (в чому справа).

Пам’ятайте, що ви не можете перешкодити кваліфікованій особі зняти блоки програмного забезпечення на вашому виробі. Тож якщо їм доведеться зламати кожну версію, яка випускається. Але ви дійсно не хочете, щоб вони могли генерувати нові ключі для вашого продукту, якими можна ділитися для всіх версій.

Python Документація PyNaCl має приклад "Цифрового підпису", який буде відповідати меті. http://pynacl.readthedocs.org/en/latest/signing/

та навести проект NaCl на приклади C

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.