Як відкритий ключ перевіряє підпис?


173

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

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


3
Приємне запитання. :)
Сурай Джайн

Я не хотів додавати це як відповідь і ризикувати виникненням полум'я, але якщо ви використовуєте слово "як" насправді означає "як я перевіряю підпис", тоді одна можливість - завантажити gpg4win. Після встановлення ви можете клацнути файл правою кнопкою миші та перевірити його. Це набір продуктів, які інтегруються в оболонку Windows. Однією з таких утиліт є Kleopatra, яка шукатиме сертифікати в Інтернеті, щоб зробити перевірку.
Ньюклік

Відповіді:


210

Ваше розуміння "шифрування відкритих ключів, розшифрування приватних ключів" є правильним ... для даних / повідомлень ВИКОРИСТАННЯ. Для цифрових підписів - це зворотній бік. Цифровим підписом ви намагаєтесь довести, що підписаний вами документ походить від вас. Для цього вам потрібно скористатися чимось, що у вас є лише: приватним ключем.

Цифровий підпис у його найпростішому описі - це хеш (SHA1, MD5 тощо) даних (файл, повідомлення тощо), який згодом шифрується приватним ключем підписувача. Оскільки це лише те, що підписав (або повинен мати), саме звідки походить довіра. КОЖНІЙ має (або повинен мати) доступ до відкритого ключа підписувача.

Отже, для перевірки цифрового підпису одержувач

  1. Обчислює хеш однакових даних (файл, повідомлення тощо),
  2. Розшифровує цифровий підпис за допомогою кнопки PUBLIC відправника та
  3. Порівняє 2 значення хеша.

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

Сподіваюся, що це допомагає!


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

63
Клавіші працюють обернено один до одного. Зашифровано щось із вашим відкритим ключем? Розшифруйте його за допомогою приватного ключа. І навпаки, якщо ви щось зашифрували своїм приватним ключем, ви розшифруєте це разом із загальнодоступним. Така природа асиметричної криптографії.
Shadowman

20
Симетричний просто означає, що той самий ключ використовується для шифрування / дешифрування. Асиметричний означає, що один ключ шифрує, а інший ключ розшифровує (а також, що зворотна також вірна).
gtrig

8
@Jodimoro, Технічно повідомлення НЕ "секретно", якщо воно зашифроване приватним ключем. Якщо він зашифрований приватним ключем, будь-хто із загальнодоступним "відкритим" ключем може розшифрувати повідомлення.
RayLoveless

4
@Jodimoro Єдина причина, за якою хеш шифрується приватним ключем у підпис, - це переконатися, що хеш не змінено ... а не для того, щоб він був "секретним".
RayLoveless

73

Клавіші працюють зворотно:

Шифрування відкритого ключа, розшифрування приватного ключа (шифрування):

openssl rsautl -encrypt -inkey public.pem -pubin -in message.txt -out message.ssl
openssl rsautl -decrypt -inkey private.pem       -in message.ssl -out message.txt

Шифрування приватного ключа, розшифрування відкритого ключа (підписання):

openssl rsautl -sign -inkey private.pem       -in message.txt -out message.ssl
openssl rsautl       -inkey public.pem -pubin -in message.ssl -out message.txt

Нижче наводиться приклад сценарію для перевірки всього цього потоку openssl.

#!/bin/sh
# Create message to be encrypted
echo "Creating message file"
echo "---------------------"
echo "My secret message" > message.txt
echo "done\n"

# Create asymmetric keypair
echo "Creating asymmetric key pair"
echo "----------------------------"
openssl genrsa -out private.pem 1024
openssl rsa -in private.pem -out public.pem -pubout
echo "done\n"

# Encrypt with public & decrypt with private
echo "Public key encrypts and private key decrypts"
echo "--------------------------------------------"
openssl rsautl -encrypt -inkey public.pem -pubin -in message.txt         -out message_enc_pub.ssl
openssl rsautl -decrypt -inkey private.pem       -in message_enc_pub.ssl -out message_pub.txt
xxd message_enc_pub.ssl # Print the binary contents of the encrypted message
cat message_pub.txt # Print the decrypted message
echo "done\n"

# Encrypt with private & decrypt with public
echo "Private key encrypts and public key decrypts"
echo "--------------------------------------------"
openssl rsautl -sign    -inkey private.pem -in message.txt          -out message_enc_priv.ssl
openssl rsautl -inkey public.pem -pubin    -in message_enc_priv.ssl -out message_priv.txt
xxd message_enc_priv.ssl
cat message_priv.txt
echo "done\n"

Цей скрипт виводить наступне:

Creating message file
---------------------
done

Creating asymmetric key pair
----------------------------
Generating RSA private key, 1024 bit long modulus
...........++++++
....++++++
e is 65537 (0x10001)
writing RSA key
done

Public key encrypts and private key decrypts
--------------------------------------------
00000000: 31c0 f70d 7ed2 088d 9675 801c fb9b 4f95  1...~....u....O.
00000010: c936 8cd0 0cc4 9159 33c4 9625 d752 5b77  .6.....Y3..%.R[w
00000020: 5bfc 988d 19fe d790 b633 191f 50cf 1bf7  [........3..P...
00000030: 34c0 7788 efa2 4967 848f 99e2 a442 91b9  4.w...Ig.....B..
00000040: 5fc7 6c79 40ea d0bc 6cd4 3c9a 488e 9913  _.ly@...l.<.H...
00000050: 387f f7d6 b8e6 5eba 0771 371c c4f0 8c7f  8.....^..q7.....
00000060: 8c87 39a9 0c4c 22ab 13ed c117 c718 92e6  ..9..L".........
00000070: 3d5b 8534 7187 cc2d 2f94 0743 1fcb d890  =[.4q..-/..C....
My secret message
done

Private key encrypts and public key decrypts
--------------------------------------------
00000000: 6955 cdd0 66e4 3696 76e1 a328 ac67 4ca3  iU..f.6.v..(.gL.
00000010: d6bb 5896 b6fe 68f1 55f1 437a 831c fee9  ..X...h.U.Cz....
00000020: 133a a7e9 005b 3fc5 88f7 5210 cdbb 2cba  .:...[?...R...,.
00000030: 29f1 d52d 3131 a88b 78e5 333e 90cf 3531  )..-11..x.3>..51
00000040: 08c3 3df8 b76e 41f2 a84a c7fb 0c5b c3b2  ..=..nA..J...[..
00000050: 9d3b ed4a b6ad 89bc 9ebc 9154 da48 6f2d  .;.J.......T.Ho-
00000060: 5d8e b686 635f b6a4 8774 a621 5558 7172  ]...c_...t.!UXqr
00000070: fbd3 0c35 df0f 6a16 aa84 f5da 5d5e 5336  ...5..j.....]^S6
My secret message
done

2
Дякуємо, що додали сценарій - безумовно, допомогли зрозуміти речі.
Пат

Велике спасибі, мені завжди легше розібратися з ecample
Simon Simon

16

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

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

Відправник надсилає:

  1. Повідомлення

  2. Хеш повідомлення зашифрований їх приватним ключем

Одержувач:

  1. Розшифровує підпис (2) відкритим ключем, щоб отримати повідомлення, імовірно, те саме повідомлення, що й (1), але ми поки не знаємо. Зараз у нас є два повідомлення, які нам потрібно підтвердити, що вони однакові. Тож для цього ми зашифруємо їх як нашим відкритим ключем, так і порівняємо два хеши. Так ми будемо….
  2. Зашифруйте оригінальне повідомлення (1) відкритим ключем, щоб отримати хеш
  3. Зашифруйте розшифроване повідомлення (3), щоб отримати другий хеш, і порівняйте з (4), щоб переконатися, що вони однакові.

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

Іншим прикладом може бути відправник для використання загального хешу, який одержувач також може знати. Наприклад:

Відправник надсилає:

  1. Повідомлення
  2. Бере відомий хеш повідомлення, а потім шифрує хеш приватним ключем

Одержувач:

  1. Розшифровує (2) і отримує хеш-значення
  2. Містить повідомлення (1) з тим самим хешем, який використовував відправник
  3. Порівняє два хеші, щоб переконатися, що вони збігаються

Це ще раз гарантує, що повідомлення не було підроблене, і воно від очікуваного відправника.


6

Якщо мені довелося переформулювати ваше питання з того, наскільки я його розумію, ви запитуєте наступне:

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

Інші відповіді вже пояснили , як асиметричні засоби шифрування , що ви можете або :

  1. Шифруйте відкритим ключем, розшифруйте відповідним приватним ключем (псевдокод нижче)
var msg = 'secret message';

var encryptedMessage = encrypt(pub_key, msg);

var decryptedMessage = decrypt(priv_key, encryptedMessage);

print(msg == decryptedMessage == 'secret message'); // True
  1. Шифруйте приватним ключем, розшифруйте відповідним відкритим ключем (псевдокод нижче)
var msg = 'secret message';

var encryptedMessage = encrypt(priv_key, msg);

var decryptedMessage = decrypt(pub_key, encryptedMessage); // HOW DOES THIS WORK???

print(msg == decryptedMessage == 'secret message'); // True

Ми знаємо, що і приклад №1 і №2 працюють. Приклад №1 має інтуїтивний сенс, тоді як приклад №2 задає оригінальне запитання .

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

  1. Відкритий ключ можна математично генерувати з приватного ключа
  2. Приватний ключ не може бути математично згенерований із відкритого ключа (наприклад, "функція" "
  3. Приватний ключ може бути перевірений відкритим ключем

Для більшості умови №1 та №2 мають сенс, а як щодо №3?

Тут у вас є два варіанти:

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

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


Ваші 3 умови все це пояснюють. Я щойно прочитав цю терміну "еліптична крива" і я був схожим на wtf
Саймон

5

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

Значна частина цієї плутанини пов'язана з називанням "відкритих ключів" та "приватних ключів" як таких, оскільки те, як ці речі фактично працюють, прямо не входить у відповідність тому, як розуміється "ключ".

Візьмемо, наприклад, шифрування. Можна вважати, що це працює так:

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

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

Однак для надсилання цифрових підписів ролі дещо змінюються:

  • Сторона, яка хоче підписати повідомлення, є єдиною, яка має доступ до розблокованих замків (тобто приватного блокування)
  • Сторони, які хочуть перевірити підпис, мають можливість отримати ключ (тобто відкритий ключ)
  • Тоді те, що підписує, це створити два однакових повідомлення: те, яке кожен може прочитати, і одне, яке супроводжує його, але яке вони блокують одним із своїх приватних замків.
  • Потім, коли одержувач отримує повідомлення, він може його прочитати, а потім використовувати відкритий ключ, щоб розблокувати заблоковане повідомлення та порівняти два повідомлення. Якщо повідомлення однакові, вони знають, що:

    1. Розблоковане повідомлення не було підроблене під час подорожей,

    2. Повідомлення повинно бути від людини, яка має відповідний замок для їх відкритого ключа.

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

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


4
Зміна "ключа" на "розблокований замок" просто додає плутанині.
Маркіз Лорн

@EJP Я не змінюю ключ на "розблокований замок". Це змінено на "замок". "Розблокований заблокований" використовується лише для того, щоб виразити використання товару. Цікаво, це ваша думка, і якщо у вас є багаторічний досвід роботи в криптовалюті, це, швидше за все, дуже упереджене, оскільки існуючі терміни - це те, як ви виросли, щоб зрозуміти технологію. Чому ви не даєте людям, які тільки починають, визначати, чи корисна аналогія чи ні?
взуття

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

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

0

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

Трюк тут - приховати приватний ключ у функції. В цьому випадку,(p-1)*(q-1).

Вважайте p приватним ключем, а e - відкритим ключем. 'p' інкапсульовано в іншій функції, щоб зробити це прихованим.

E.g., `d = (p-1)(q-1); d * e = 1` (d is the inverse of e - public key)

Дані надіслані = [зашифровані (хеш), повідомлення] = [m ^ d, повідомлення]; де m - повідомлення Припустимо, "Дані надіслані" = y Для перевірки цілісності знайдемо y ^ e, щоб отримати m. З тих пір m ^(d*e) = m ^1 = m.

Сподіваюся, це допомагає! :)

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