Асимметричное аутентифицированное шифрование
Я хочу защитить свои данные от изменения или чтения посторонними лицами. В поисках я обнаружил, что Authenticated Encryption (AE) — это решение.
Я знаю, что могу делать AE в Crypto ++, используя любой из CCM, GCM или EAX. Но я заметил, что они используют один и тот же ключ для шифрования и дешифрования данных. Я не хочу этого, я бы предпочел использовать асимметричные ключи для шифрования и дешифрования моих данных.
Если я подпишу данные с использованием асимметричного алгоритма, а затем зашифрую их с помощью симметричного алгоритма, я достигну того, чего хочу (что должно быть безопасно, так как Съел метод, верно?).
Но прежде чем я это сделаю, есть ли крипто-библиотеки, которые делают то, что я уже хочу?
Решение
Я знаю, что могу сделать Шифрование с проверкой подлинности … используя … CCM, GCM или EAX. Но я заметил, что они используют один и тот же ключ для шифрования и дешифрования данных. Я не хочу этого, я бы предпочел использовать асимметричные ключи для шифрования и дешифрования моих данных.
Все известные мне схемы будут использовать симметричный шифр для шифрования больших объемов данных. Симметричный шифр может быть блочным или потоковым шифром.
Я также видел несколько неправильных приложений RSA, где RSA работает в режиме ECB. То есть данные «группируются» или «блокируются», и затем RSA применяется к каждому блоку. Справочник по прикладной криптографии особо предупреждает против этого.
Лучшее, что вы, вероятно, собираетесь сделать, это Схема интегрированного шифрования эллиптической кривой (ECIES) или же Дискретная логарифмическая интегрированная система шифрования (DLIES). Оба доступны в Crypto ++. Оба используют криптографию с открытым ключом (асимметричную).
ECIES и DLIES объединяют механизм инкапсуляции ключей (KEM) с механизмом инкапсуляции данных (DEM). Система независимо выводит симметричный ключ шифрования и ключ MAC из общего секрета. Сначала данные шифруются симметричным шифром, а затем текст шифра MAC-адресом по схеме аутентификации. Наконец, общий секрет зашифрован в открытой части пары открытый / закрытый ключ. Выходом функции шифрования является кортеж {K,C,T}, где K это зашифрованный общий секрет, C это зашифрованный текст, и T это тег аутентификации.
Есть некоторый отказ от «общего секрета», поскольку он фактически является результатом применения функции Соглашения о ключах и впоследствии переваривается с помощью KDF. Он использует статический открытый ключ и пару эфемерных ключей. Лицо, выполняющее расшифровку, использует свой открытый ключ для выполнения другой половины обмена ключами, чтобы получить «общий секрет».
KEM и DEM избегают заполнения, поэтому оракулы заполнения не являются проблемой. Вот почему KDF используется для переваривания большого «общего секрета» под KEM. Исключение заполнения значительно упрощает доказательства безопасности системы. Из-за доказательств безопасности, ECIES и DLIES IND-CCA2, что является одним из самых сильных вы можете достичь.
Если я подписываю данные, используя асимметричный алгоритм, а затем шифрую их, используя симметричный алгоритм …
Вот некоторые связанные чтения … Во-первых, это Хьюго Кравчик Порядок шифрования и аутентификации для защиты связи. Во-вторых, Дон Дэвис Дефектный знак & Шифрование в S / MIME, PKCS # 7, MOSS, PEM, PGP и XML.
Актуальность здесь: статья Кравчика посвящена криптографии с симметричным ключом и стилю аутентифицированного шифрования Encrypt-then-Authenticate (и тому, как выполнять аутентифицированное шифрование). Статья Дэвиса посвящена асимметричной криптографии и разрыву между подписанием и шифрованием (и как это исправить).
Но прежде чем я это сделаю, есть ли крипто-библиотеки, которые делают то, что я уже хочу?
Да (но это зависит от того, что вы хотите сделать). Я знаю только о Crypto ++, который предоставляет ECIES, DLIES и набор PSSR.
Надувной замок — второе место, потому что он дает ECIES, но не DLIES. Я не уверен, сколько PSSRs это обеспечивает.
Crypto ++, Bouncy Castle, OpenSSL (и другие) предоставляют PSSR. У вас не должно возникнуть проблем с поиском библиотеки с помощью PSSR.
Другие решения
Возможно, вы могли бы рассмотреть решение на основе OpenPGP. Это обеспечит вас желаемой функциональностью и позволит масштабировать для поддержки произвольных размеров данных, в отличие от решения, основанного исключительно на асимметричном шифровании (без транспортного ключа).
Существует несколько реализаций с открытым исходным кодом. BouncyCastle предлагает один, но я не уверен, что у них есть реализация C ++.
GPGME (GnuPG Made Easy). Это высокоуровневая библиотека шифрования на C, лицензированная LGPL.