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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В вашем сценарии вы не шифруете в смысле асимметричного шифрования; Я бы предпочел назвать это «кодировать».

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

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

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

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

Ищите «Боб», «Алиса» и «Мэллори», чтобы найти вводные статьи в Интернете.

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

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

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

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

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

и, конечно, NaCl проект на C примеры