В чем разница между шифрованием и подписью в асимметричном шифровании?

Ответ 1

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

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

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

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

Это подписание, это делается с помощью вашего закрытого ключа.

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

Меня волнует только то, что я единственный, кто может их генерировать.

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

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

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

Вам, вероятно, потребуется приобрести сертификат для вашего открытого ключа у коммерческого поставщика, такого как Verisign или Thawte, чтобы люди могли проверить, что никто не подделывал ваше программное обеспечение и не заменял ваш открытый ключ своим.

Ответ 2

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

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

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

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

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

Итак:

• Чтобы сгенерировать подпись, сделать хэш из открытого текста, зашифровать его своим личным ключом, включить его вместе с открытым текстом.
• Чтобы проверить подпись, сделать хэш из открытого текста, дешифровать подпись с открытым ключом отправителя, проверить, что оба хэша одинаковы.

Ответ 3

Да, думайте о подписании данных, как о том, что вы ставите свою собственную восковую печать, которую никто другой не имеет. Это сделано для достижения целостности и непризнания. Шифрование так, чтобы никто не мог видеть данные. Это сделано для достижения конфиденциальности. Смотрите Википедию http://en.wikipedia.org/wiki/Information_security#Key_concepts

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

Ответ 4

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

Шифрование использует открытый ключ приемника для шифрования данных; декодирование выполняется с помощью закрытого ключа.

Итак, использование ключей не отменено (иначе ваш личный ключ больше не будет закрыт!).

Ответ 5

В установлении безопасного общения есть две разные, но тесно связанные проблемы.

1. Зашифруйте данные, чтобы их могли расшифровать и прочитать только уполномоченные лица.
2. Подтвердите личность/аутентификацию отправителя.

Обе эти проблемы могут быть элегантно решены с помощью криптографии с открытым ключом.

I. Шифрование и дешифрование данных

Алиса хочет отправить Бобу сообщение, которое никто не сможет прочитать.

• Алиса шифрует сообщение открытым ключом Боба и пересылает его.
• Боб получает сообщение и расшифровывает его, используя свой закрытый ключ.

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

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

II. Проверка личности отправителя (Аутентификация)

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

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

Есть ли способ, которым Боб может подтвердить, что получаемые им сообщения действительно отправляются Алисой?

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

Ответ 6

Подписание означает, что вы действительно являетесь источником или поручителем для подписанного объекта. Однако каждый может прочитать объект.

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

Ответ 7

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

Ответ 8

В вашем сценарии вы не шифруете значение асимметричного шифрования; Я бы назвал его "encode".

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

Ответ 9

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

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

Что касается используемого алгоритма: это включает простые числа. Я бы сделал поиск в google для лучшего объяснения.

Ответ 10

Я думаю, что есть смешанные сообщения выше. Я пытался добиться того же, что и Simucal, т.е. я хотел создать лицензионный ключ, содержащий важную информацию о том, кто может использовать программное обеспечение, а также между диапазонами дат и т.д. Но я не хочу, чтобы люди могли изменить это информацию для продления срока действия лицензии и т.д. Мой первый подход заключался в использовании асимметричного шифрования, но, несмотря на некоторые из приведенных выше комментариев, кажется, что вы можете шифровать, используя открытый или закрытый ключ, НО ТОЛЬКО расшифровывать его с помощью закрытого ключа. Поэтому в этом случае вам нужно будет хранить закрытый ключ в системе, чтобы он мог декодировать и проверять лицензионный ключ... рендеринг системы довольно небезопасен, потому что любой может генерировать свою собственную измененную информацию о лицензии и шифровать ее с помощью открытый или закрытый ключ (один из которых будет храниться в системных двоичных файлах). Разумеется, такой же риск безопасности прилагается к симметричному шифрованию.

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

Ответ 11

  В чем разница между шифрованием некоторых данных и подписью некоторых данных (с использованием RSA)?

Шифрование сохраняет конфиденциальность сообщения ("некоторые данные"), в то время как подписывание обеспечивает неоспоримость: то есть, только подписавший его объект мог подписать его. Есть также функциональные различия; читать дальше.

Это просто меняет роль открытых и закрытых ключей?

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

Для того же сообщения вы должны использовать закрытый ключ отправителя для подписи и доверенный открытый ключ получателя для шифрования. Обычно используется sign-then-encrypt, иначе злоумышленник может заменить подпись своей собственной. Точно так же вы должны использовать закрытый ключ получателя для расшифровки и доверенный открытый ключ отправителя для проверки.

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

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

Это свойство безотказности, которое может быть достигнуто подписью.

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

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

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

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

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

Шифрование используется для достижения конфиденциальности. В прошлом создание подписи RSA часто считалось "шифрованием с помощью закрытого ключа". Однако операции, как объяснено выше, совершенно разные, и более поздние стандарты отчаянно пытаются разделить шифрование и генерацию подписи.

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

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

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

Предотвратить клонирование/изменение вашего кода вообще намного сложнее, и если вы пойдете этим путем, вы окажетесь на территории DRM.

Полезно ли в этом сценарии подписание?

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

Ответ 12

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

• Никакая сторонняя сторона не может создать лицензионный ключ при декомпиляции приложения
• Содержимое программного ключа не должно быть безопасным.
• Программный ключ не читается человеком.

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

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

Python В документации PyNaCl приведен пример "Цифровой подписи", который будет соответствовать этой цели. http://pynacl.readthedocs.org/en/latest/signing/

и привести проект NaCl к примерам C