Можно ли зашифровать секретным ключом/расшифровать с помощью открытого ключа?

[Отказ от ответственности: я знаю, если вы знаете что-нибудь о крипто, вы, вероятно, собираетесь рассказать мне, почему я делаю это неправильно - я сделал достаточно Google, чтобы понять, что это типичный ответ.]

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

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

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

О, и указатели на реализацию будут приветствоваться, хотя можно найти основы для Google, если есть какие-либо "gotchas", которые были бы полезны!

Ответ 1

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

Само шифрование недостаточно. Как вы узнали, что дешифрованный месиво - это то, что должно быть? Расшифровка файла cookie, зашифрованного с помощью правильного ключа, обязательно предоставит "действительный" файл cookie, но что произойдет, когда вы расшифруете файл cookie, зашифрованный с помощью неправильного ключа? или просто какие-то бессмысленные данные? ну, вы можете просто получить cookie, который выглядит действительным! (отметки времени находятся в диапазоне, который вы считаете действительным, имя пользователя является законным, случайное число -... uh... число и т.д.).

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

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

Ответ 2

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

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

Я достаточно читал о интересных атаках на системы открытых ключей и, в частности, RSA, что я абсолютно согласен с этим заключением:

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

(Это означает: шифрование открытым ключом, знаком с закрытым ключом и все, что играется с огнем.)

Добавление:

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

Ответ 3

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

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

Существует модуль RSA n и два обычных показателя RSA d и e (такие, что ed = 1 по модулю p-1 и q-1, где n = pq). Центральный орган знает d, доверенные веб-серверы знают e, модуль n является общедоступным.
Куки обрабатываются центральным органом, дополняя его целым числом по модулю n и вычисляя s = c ^ d mod n.
Доверенные веб-серверы получают доступ к данным cookie, вычисляя c = s ^ e mod n.

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

Для обеспечения базовой безопасности e должен быть большим. В обычных описаниях RSA e является публичным показателем и мал (например, e = 3). Маленький экспонент не является проблемой, когда он является общедоступным, но поскольку вы не хотите, чтобы содержимое cookie было доступно третьим лицам, вы должны сделать достаточно большим, чтобы противостоять исчерпывающему поиску. В то же время доверенные веб-серверы не должны знать p и q, только n. Это означает, что доверенным веб-серверам необходимо будет вычислять вещи с большим модулем и большим показателем и не зная коэффициентов модуля. Это кажется незначительным моментом, но он дисквалифицирует многие библиотеки реализации RSA. Вы будете "сами по себе", с большими целыми числами (и всеми проблемами реализации, известными как "утечки бокового канала" ).
Сопротивление RSA-сигнатур и сопротивление шифрования RSA хорошо изучены, но не вместе. Так получилось, что прокладка имеет важное значение, и вы не используете ту же схему дополнений для шифрования и для подписей. Здесь вам нужна схема прокладки, которая будет хороша как для сигнатуры, так и для шифрования. Криптографы обычно считают, что хорошая безопасность достигается, когда сотни подготовленных криптографов рассматривают схему в течение нескольких лет и не обнаружили вопиющей слабости (или исправлены любые недостатки). Домашние схемы почти всегда не обеспечивают безопасность.
Если многие знают секрет, то это уже не секрет. Здесь, если все веб-серверы знают e, вы не можете отменить привилегии доверенного веб-сервера, не выбирая новое e и не передавая новое значение всем остальным доверенным веб-серверам. У вас тоже будет проблема с общим симметричным ключом.

В настоящее время изучается проблема обеспечения конфиденциальности и проверяемой целостности того же типа. Вы можете найти signcryption. Пока еще нет установленного стандарта.

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

Для части подписи вы можете использовать DSA или ECDSA: они дают гораздо более короткие подписи (обычно 320 бит для DSA-подписи безопасности, эквивалентной 1024-битной RSA-сигнатуре). С точки зрения центральной власти ECDSA также обеспечивает лучшую производительность: на моем ПК с использованием одного ядра OpenSSL сокращает более 6500 подписей ECDSA в секунду (в кривых NIST P-192) и "только" 1145 подписей RSA на каждый второй (с 1024-битным ключом). Подписи ECDSA состоят из двух 192-битных целых чисел, то есть 384 бит для кодирования, тогда как RSA-сигнатуры имеют длину 1024 бит. ECDSA в P-192 считается как минимум сильным и, вероятно, более сильным, чем RSA-1024.

Ответ 4

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

Что остановить кого-то, кому вы не доверяете, ставить открытый ключ X на сервер, которому вы не доверяете?

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

Затем сервер X может шифровать сообщение с помощью закрытого ключа X и открытого ключа Y. Это говорит о том, что "сервер X отправил сообщение, которое только Y мог прочитать, а Y мог проверить, что оно было от X".

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

Это то, что делает SSL. Он использует криптографию открытого ключа для настройки сеансового ключа.

При этом используйте библиотеку. Этот материал легко заглушить.

Ответ 5

Ответ на ваш вопрос "будет ли акт расшифровки доказательством того, что он был сгенерирован с помощью закрытого ключа" , ответ "да", если получатель может выполнить простую проверку данных. Скажем, у вас есть "Имя пользователя: John, timestamp: <number> , expiry: dd/mm/yyyy". Теперь, если для дешифрования используется неправильный открытый ключ, вероятность того, что вы получите "Имя пользователя: < some letters > , timestamp: < only numbers > , expiry:??/??/????" равна нулю. Вы можете проверить правильное выражение (регулярное выражение), например "Имя пользователя: [a-zA-Z] +, отметка времени: [0-9] +, истечение срока действия:...." и сбросить его с проверки. Вы даже можете проверить, находится ли день между 1 и 31, месяц между 1 и 12, но вы не сможете его использовать, поскольку регулярное выражение обычно терпит неудачу при "имени пользователя:", если используется неправильный открытый ключ. Если проверка прошла успешно, вам все равно нужно проверить временную метку и убедиться, что у вас нет повторной атаки.

Однако рассмотрим следующее:

Скрипт открытого ключа RSA не предназначен для массового шифрования структурированных данных, так как он может быть использован злоумышленником. public key crypto обычно используется двумя способами: 1) для безопасной транспортировки симметричного ключа (который по определению не имеет структуры), который будет использоваться при массовом шифровании; это делается путем шифрования симметричного ключа с использованием открытого ключа и 2) цифровой подписи документа путем шифрования не документа, а хеша документа (опять-таки чего-то, у которого нет структуры) с использованием закрытого ключа. В вашем случае вы шифруете cookie, который имеет определенную структуру.
Вы зависите от открытого ключа, который не попадает в руки не того человека или организации.
шифрование с открытым ключом примерно в 1000 раз медленнее, чем симметричное шифрование ключа. Это не может быть фактором в вашем случае.

Если вы все еще хотите использовать этот подход и можете распространять открытый ключ только для "доверенных партнеров", вы должны создать случайный ключ сеанса (т.е. симметричный ключ), зашифровать его с помощью закрытого ключа и отправить всех получателей, имеющих открытый ключ. Затем вы шифруете файл cookie с помощью ключа сеанса. Вы можете периодически менять сеанс. Более часто вы также можете изменить открытый ключ: вы можете создать новую пару открытого/закрытого ключа и зашифровать открытый ключ с помощью ключа сеанса и отправить его всем получателям.

Ответ 6

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

Ответ 7

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