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

StackOverflow https://stackoverflow.com/questions/454048

Вопрос

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

Меняет ли это просто роль общедоступных и закрытых ключей на противоположную?

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

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

Это было полезно?

Решение

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

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

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

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

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

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

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

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

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

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

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

Другие советы

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

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

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

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

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

Итак:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Меняет ли это просто роль общедоступных и закрытых ключей на противоположную?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top