Можно ли использовать асимметричное шифрование с двумя закрытыми ключами?

Question

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

• Сторона A имеет открытый и закрытый ключ
• Сторона B шифрует данные с помощью открытого ключа A
• Партия А расшифровывает материал с помощью своего закрытого ключа

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

• Сторона A имеет закрытый ключ
• Сторона B имеет закрытый ключ (который является открытым ключом стороны A)
• Сторона B зашифровывает данные своим закрытым ключом
• Сторона A расшифровывает данные своим закрытым ключом

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

Это все еще асимметричное шифрование или я должен искать другие методы?

Answer 1

Сторона Возможность шифрования сообщений с использованием открытого ключа абсолютно не проблема .

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

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

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

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

Answer 2

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

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

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

Это гарантирует, что 1. только вы можете отправить им лицензию и 2. только они могут ее расшифровать.

Answer 3

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

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

• Если ваша группа B (Bob) шифрует несколько сообщений одним и тем же открытым ключом, злоумышленник, который читает эти (зашифрованные) сообщения, может без особых усилий получить ваш открытый ключ.Злоумышленник не получает открытые тексты или закрытый ключ, но открытый ключ всегда становится действительно «открытым».
• Для A (Алиса) даже можно создать открытый ключ из закрытого ключа,без шифрования любого сообщения общедоступным.

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

В этомВ этом случае вы должны объединить две пары ключей: одну из B, чтобы подписать / проверить сообщение (чтобы убедиться, что сообщение было отправлено B), и одну из A, чтобы зашифровать / расшифровать сообщение (чтобы убедиться, что только A может его прочитать).

Answer 4

Вы можете взглянуть на лицензирование Rhino: http://hibernatingrhinos.com/open-source/rhino-licensing/introduction

Answer 5

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

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

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

Answer 6

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

Answer 7

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

alice -> bob: alice.pub bob -> alice: bob.pub alice: r = random.secret() alice -> bob: ( r * (alice.priv * bob.pub) ) bob: r = ( (r * (alice.priv * bob.pub)) * (bob.priv * alice.pub) )

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

У меня естьникогда не видел, чтобы кто-нибудь смешивал пары ключей, как это, но я проверил это, написав код.Мне пришлось сделать что-то необычное, потому что, как правило, применение закрытого ключа к сообщению предназначено для «подписания».Но подписание обычно хэширует секрет и применяет закрытый ключ к хешу его;что-то мы не хотим.Таким образом, в моем коде, как только у меня были компоненты RSA (D, E, N), извлеченные в числа произвольной точности ... то есть: расшифровать, зашифровать, модуль ... Я просто сделал:

wormholeSend(me,you,msg) = (((me ^ {me_D}) \% me_N) ^ {you_E}) \% you_N

То, что делает его немного сложным, заключается в том, что E (показатель шифрования) на самом деле является предсказуемым значением, но модуль N находится в открытом ключе (E, N).D является частным для каждой стороны.Здесь нужно быть осторожным, потому что у нас с тобой другой модуль N.

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