Как открытый ключ проверяет подпись?

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

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

Ответ 1

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

Цифровая подпись в самом простом описании - это хеш (SHA1, MD5 и т.д.) Данных (файла, сообщения и т.д.), Которые впоследствии шифруются с помощью закрытого ключа подписавшего. Поскольку это то, что имеет (или должно иметь) только тот, кто подписал, именно отсюда и возникает доверие. КАЖДЫЙ имеет (или должен иметь) доступ к открытому ключу подписавшего.

Итак, чтобы проверить цифровую подпись, получатель

  1. Вычисляет хэш из тех же данных (файл, сообщение и т.д.),
  2. Расшифровывает цифровую подпись, используя ключ PUBLIC отправителя, и
  3. Сравнивает 2 значения хеша.

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

Надеюсь, это поможет!

Ответ 2

Клавиши работают обратно:

Шифрование с открытым ключом, дешифрование с помощью закрытого ключа (шифрование):

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  [email protected]<.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

Ответ 3

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

Есть несколько способов проверить, что сообщение пришло от ожидаемого отправителя. Например:

Отправитель отправляет:

  1. Сообщение

  2. Хеш сообщения зашифрован с помощью их закрытого ключа

Получатель:

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

Если они не идентичны, это означает, что сообщение было подделано или подписано каким-то другим ключом, а не тем, который мы думали...

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

Отправитель отправляет:

  1. Сообщение
  2. Принимает известный хэш сообщения, затем шифрует его с помощью закрытого ключа.

Получатель:

  1. Расшифровывает (2) и получает хеш-значение
  2. Хэширует сообщение (1) с тем же хешем, который использовался отправителем
  3. Сравнивает два хэша, чтобы убедиться, что они совпадают

Это снова гарантирует, что сообщение не было подделано и получено от ожидаемого отправителя.

Ответ 4

Я подумал, что смогу дать дополнительное объяснение любому, кто ищет что-то более интуитивно-показательное.

Большая часть этой путаницы возникает из-за именования "открытых ключей" и "закрытых ключей" как таковых, потому что то, как эти вещи на самом деле работают, напрямую расходится с тем, как понимается "ключ".

Взять, к примеру, шифрование. Это можно представить так:

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

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

Однако для отправки цифровых подписей роли несколько поменялись местами:

  • Сторона, которая хочет подписать сообщения, является единственной, кто имеет доступ к разблокированным блокировкам (т.е. частная блокировка)
  • Все стороны, которые хотят проверить подпись, имеют возможность получить ключ (то есть открытый ключ)
  • Затем подписывающее лицо создает два идентичных сообщения: одно, которое может прочитать каждый, и одно, которое сопровождает его, но которое они блокируют одной из своих личных блокировок.
  • Затем, когда получатель получает сообщение, он может прочитать его, а затем использовать открытый ключ, чтобы разблокировать заблокированное сообщение и сравнить два сообщения. Если сообщения совпадают, то они знают, что:

    1. Открытое сообщение не было подделано во время путешествия и,

    2. Сообщение должно быть от человека, который имеет соответствующую блокировку для своего открытого ключа.

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

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

Ответ 5

Hy All,

Любая ссылка, как создать подпись с закрытым ключом? либо в php, nodejs, rails, либо в java-ссылке.

С Уважением,