Крипто с открытым ключом и шифрованием с закрытым ключом

Я пытаюсь реализовать на С# следующее:

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

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

Большинство встроенных криптографических библиотек C# с открытым ключом, которые я вижу, хотят связать закрытый ключ с дешифрованием (например, RSACryptoServiceProvider). Я понимаю, почему, так как многие сценарии включают защиту стороны процесса дешифрования, а не шифрования. Существуют ли какие-либо библиотеки C#, которые упрощают защиту процесса шифрования? Я пытался смотреть на Bouncy Castle все утро, но мне трудно заставить его работать даже в базовых сценариях. Документация оставляет желать лучшего...

Опять же, моя главная цель — убедиться, что то, что создало шифрование, обладает закрытым ключом. Также необходимо, чтобы Клиент мог убедиться, что результат Генератора соответствует предоставленной им информации. Если есть альтернативные подходы, которые я упустил, которые могли бы лучше соответствовать доступным библиотекам, я весь в ушах :)


encryption c# key public cryptography
person iddqd    schedule 13.04.2013    source источник
comment
так вы хотите, чтобы Генератор производил подпись?   -  person Filip    schedule 13.04.2013
comment
Это атака с выбранным открытым текстом, написанная повсюду. Криптосистемы с открытым ключом полагаются на владельца закрытого ключа, являющегося объектом, который генерирует сообщение, которое должно быть подписано этим ключом. Если вы хотите, чтобы генератор мог доказать, что он обладает закрытым ключом, связанным с данным открытым ключом, то пусть генератор сгенерирует документ, состоящий из случайных битов, которые он может хэшировать, а затем опубликует хэш, подписанный с закрытым ключом. -ключевой хэш и документ. Затем любой, у кого есть открытый ключ, может проверить, совпадают ли хэш, подписанный хеш и документ.   -  person Eric Lippert    schedule 13.04.2013
comment
Если вам абсолютно необходимо, чтобы клиент, который помнит, должен быть принят генератором за злоумышленника, предоставил документ, то, по крайней мере, генератор должен добавлять случайные биты к документу, затем хешируйте новый документ, а затем зашифруйте хеш. Опять же, генератор может опубликовать измененный документ, хэш и подписанный хэш, а клиент может проверить, что все они совпадают друг с другом. Но делайте это только в случае крайней необходимости. Вы никогда не захотите шифровать документ от имени злоумышленника.   -  person Eric Lippert    schedule 13.04.2013
comment
@iddqd Есть ли причина, по которой вы не хотите использовать обычные цифровые подписи? Например, те, которые предлагает RSACryptoServiceProvider.SignData. Подписи RSA внутренне используют операцию закрытого ключа RSA, но они добавляют соответствующее хеширование и заполнение, которые важны для безопасности. Вы можете подписать, только если знаете закрытый ключ, и можете подтвердить с помощью открытого ключа.   -  person CodesInChaos    schedule 13.04.2013
comment
@Eric Атака с выбранным открытым текстом здесь не подходит. Сам по себе открытый текст я на самом деле не пытаюсь защитить, поэтому на самом деле не имеет большого значения, если кто-то угадает открытый текст, созданный клиентом. Проблема заключается в том, что Клиент знает, что зашифрованный результат получен от Генератора, и что зашифрованный результат получен из ответа, первоначально отправленного Клиентом. Я не пытаюсь обеспечить средство для Генератора и Клиента для обмена секретными данными через шифр.   -  person iddqd    schedule 13.04.2013
comment
Метод подписи отлично работает для Клиента, зная, что Генератор создал ответ/подпись, но я не думаю, что это поможет Клиенту получить зашифрованный ответ и проверить, соответствует ли он исходным данным.   -  person iddqd    schedule 13.04.2013
comment
Уточнение, которое на самом деле не влияет на реализацию, но может помочь понять, что я пытаюсь сделать, заключается в том, что данные, передаваемые от клиента к генератору, представляют собой хешированный идентификатор для этого клиента. Таким образом, Генератор действительно возвращает зашифрованный ответ, который теоретически действителен только для этого конкретного Клиента. Клиент должен взять зашифрованный ответ и каким-то образом сопоставить его со своим собственным идентификатором, чтобы убедиться, что он действительно предназначен для него, а не для другого клиента.   -  person iddqd    schedule 13.04.2013

Ответы (1)


arrow_upward
4
arrow_downward

Ты пишешь:

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

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

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

person Ebbe M. Pedersen    schedule 14.04.2013