Можно зашифровать с закрытым ключом/, дешифруют с открытым ключом?
Я слышал в JAX в этом году, что «lambads не поддерживают рекурсию». Под этим утверждением подразумевается, что «это» внутри лямбда всегда относится к окружающему классу.
Но мне удалось определить - по крайней мере, как я понимаю термин «рекурсия» - рекурсивная лямбда и он выглядит следующим образом:
interface FacInterface {
int fac(int i);
}
public class Recursion {
static FacInterface f;
public static void main(String[] args)
{
int j = (args.length == 1) ? new Integer(args[0]) : 10;
f = (i) -> { if ( i == 1) return 1;
else return i*f.fac( i-1 ); };
System.out.println( j+ "! = " + f.fac(j));
}
}
Сохраните это внутри файла «Recursion.java» и с двумя командами «javac Recursion.java» и «java Recursion» это сработало для меня.
Clou должен поддерживать интерфейс, который лямбда должна реализовать как переменная поля в окружающем классе. Лямбда может ссылаться на это поле, и поле не будет неявным окончательным.
5 ответов
Вы должны использовать какую-либо схему цифровых сигнатур или какой-то другой механизм, который предназначен для решения проблемы целостности вашего сценария.
Самого шифрования недостаточно. Откуда вы знаете, что дешифрованный messege - это то, что должно быть? Расшифровка файла cookie, зашифрованного с помощью правильного ключа, безусловно, даст «правильный» файл cookie, но что произойдет, если вы расшифруете файл cookie, зашифрованный с помощью неправильного ключа? или просто какие-то бессмысленные данные? ну, вы можете просто получить печенье, которое выглядит действительным! (временные метки находятся в диапазоне, который вы считаете допустимым, имя пользователя допустимо, случайное число ... э-э ... число и т. д.).
В большинстве асимметричных алгоритмов шифрования, которые я знаю, нет встроенной проверки. Это означает, что дешифрование сообщения с неправильным ключом не «провалится» - оно даст вам только неверный открытый текст, который вы должны отличать от действительного открытого текста. Именно здесь возникает честность, чаще всего - с использованием цифровых подписей.
Кстати, RSA давно изучен и имеет несколько «уловок», поэтому, если вы планируете реализовать его с нуля, вам лучше заранее прочитать, как избежать создания «относительно легко ломающихся» ключей.
Открытые ключи по определению являются открытыми. Если вы шифруете с помощью закрытого ключа и расшифровываете с помощью открытого ключа, это не безопасно для посторонних глаз. Все это говорит: «эти данные поступают от лица X, у которого есть закрытый ключ X», и любой может проверить это, потому что другая половина ключа является открытой.
Что может помешать кому-то, кому вы не доверяете, разместить открытый ключ X на сервере, которому вы не доверяете?
Если вам нужна безопасная линия связи между двумя сервера, вам нужно, чтобы все эти доверенные серверы имели свои собственные пары открытого и закрытого ключей, мы скажем пару ключей Y для одного такого сервера.
Сервер X может затем зашифровать сообщение с помощью закрытого ключа X и открытого ключа Y. Это говорит о том, что «сервер X отправил сообщение, которое мог прочитать только Y, и Y мог проверить, что оно было от X».
( И это сообщение должно содержать недолговечный симметричный ключ, потому что шифрование с открытым ключом очень трудоемко.)
Это то, что делает SSL. Он использует криптографию с открытым ключом для установки сеансового ключа.
Как говорится, используйте библиотеку. Этот материал легко испортить.
Я предполагаю, что вы доверяете «доверенным партнерам» в расшифровке и проверке файлов cookie, но не хотите, чтобы они могли создавать свои собственные файлы cookie? Если это не проблема, вы можете использовать гораздо более простую систему: разослать секретный ключ всем сторонам и использовать его как для шифрования куки-файла, так и для его создания HMAC. Нет необходимости в криптографии с открытым ключом, не нужно использовать несколько ключей.
В криптографии вы - то, что вы знаете. В вашем сценарии у вас есть центральный орган, который может выдавать ваши файлы cookie, и вы хотите, чтобы никакая другая организация не могла сделать то же самое. Поэтому центральный орган должен "знать" некоторые частные данные. Кроме того, вы хотите, чтобы "доверенные веб-серверы" могли получить доступ к содержимому файлов cookie, и вы не хотите, чтобы кто-то мог прочитать эти файлы. Таким образом, "доверенные веб-серверы" также должны иметь свои собственные частные данные.
Обычный способ заключается в том, что орган власти применяет цифровую подпись к файлам cookie, а сами файлы cookie шифруются ключом, известным доверенным веб-серверам. То, о чем вы думаете, выглядит так:
- Есть модуль RSA n и две обычные экспоненты RSA d и e (такие, что ed = 1 по модулю p-1 и q-1, где n=pq). Центральный орган знает d, доверенные веб-серверы знают e, модуль n является открытым.
- Cookie обрабатывается центральным органом путем вставки в целое число c по модулю n и вычисления s = c^d mod n.
- Доверенные веб-серверы получают доступ к данным cookie, вычисляя c = s^e mod n.
Хотя такая схема может работать, я вижу в ней следующие проблемы:
- Для базовой безопасности e должно быть большим. В обычных описаниях RSA, e - это публичная экспонента и она мала (например, e = 3). Маленькая экспонента не представляет проблемы, когда она публичная, но поскольку вы не хотите, чтобы содержимое cookie было доступно третьим лицам, вы должны сделать e достаточно большим, чтобы противостоять исчерпывающему поиску. В то же время, доверенные веб-серверы не должны знать p и q, только n. Это означает, что доверенные веб-серверы должны будут вычислять числа с большим модулем и большой экспонентой, не зная коэффициентов модуля. Это кажется незначительным моментом, но он дисквалифицирует многие библиотеки для реализации RSA. Вы будете "сами по себе", с большими целыми числами (и всеми проблемами реализации, известными как "утечки через побочные каналы").
- Устойчивость подписей RSA и устойчивость шифрования RSA были хорошо изучены, но не вместе. Так получилось, что набивка очень важна, и вы не можете использовать одну и ту же схему набивки для шифрования и для подписей. Здесь нужна схема набивки, которая будет хороша и для подписи, и для шифрования. Криптографы обычно считают, что хорошая безопасность достигается, когда сотни обученных криптографов рассматривали схему в течение нескольких лет и не нашли ни одного вопиющего недостатка (или исправили все недостатки, которые были найдены). Приготовленные в домашних условиях схемы почти всегда не достигают безопасности.
- Если секрет знают многие, то это уже не секрет. Здесь, если все веб-серверы знают e, то вы не можете отозвать привилегии доверенного веб-сервера без выбора нового e и сообщения нового значения всем оставшимся доверенным веб-серверам. Такая проблема возникнет и с общим симметричным ключом.
Проблема обеспечения конфиденциальности и проверяемой целостности в одном и том же типе в настоящее время изучается. Вы можете поискать signcryption. Установленного стандарта пока нет.
В основном, я думаю, вы будете более счастливы с более классическим дизайном, с цифровыми подписями, используемыми только для подписания, и (симметричным или асимметричным) шифрованием для части конфиденциальности. Это позволит вам использовать существующие библиотеки с минимально возможным самодельным кодом.
Для части подписи вы можете использовать DSA или ECDSA: они дают гораздо более короткие подписи (обычно 320 бит для подписи DSA по безопасности эквивалентны 1024-битной подписи RSA). С точки зрения центрального органа, ECDSA также обеспечивает более высокую производительность: на моем компьютере, используя одно ядро, OpenSSL выдает более 6500 подписей ECDSA в секунду (в кривой P-192 NIST) и "только" 1145 подписей RSA в секунду (с 1024-битным ключом). Подписи ECDSA состоят из двух 192-битных целых чисел, т.е. 384 бита для кодирования, в то время как подписи RSA имеют длину 1024 бита. ECDSA в P-192 считается по крайней мере таким же сильным, а возможно и более сильным, чем RSA-1024.
Нейт Лоусон объясняет здесь и здесь , почему вы не можете безопасно использовать открытый ключ в качестве близко- держал секретный ключ дешифрования (это тонкий момент и ошибка, которую совершали многие другие до вас, так что не расстраивайтесь!).
Просто используйте свой открытый ключ для подписи для проверки подлинности и отдельный симметричный ключ для секретности.
Я прочитал достаточно об интересных атаках на системы с открытым ключом, и на RSA в частности, что я полностью согласен с этим выводом:
Криптосистемы с открытым ключом и RSA в частности чрезвычайно уязвимы. Не используйте их иначе, чем они были разработаны.
(Это означает: шифрование открытым ключом, подпись закрытым ключом, и все остальное играет с огнем.)
Приложение:
Если вам интересно уменьшить размер получаемых файлов cookie, вам следует подумать об использовании ECDSA, а не RSA для создания подписей - подписи ECDSA значительно меньше, чем подписи RSA с эквивалентным фактором безопасности.