Обертывание ключа открытым ключом ECDH?

Question

Предисловие: Я не знаю, правильнее ли задавать этот вопрос здесь или на сайте Crypto. Не стесняйтесь перемещать, удалять или выполнять любые другие действия SE.

---

Меня попросили помочь обновить программное обеспечение для шифрования. Вообще говоря, программное обеспечение уже выполняет следующие шаги, ни один из которых не является особенно необычным. Я упустил обработку ошибок и Provider аргументы для простоты публикации:

1) Создает случайный симметричный секретный ключ для использования с AES-128 (или AES-256, mutatis mutandis ):

KeyGenerator keygen = KeyGenerator.getInstance("AES");
keygen.init (128, a_SecureRandom_instance);
SecretKey sessionKey = keygen.generateKey();

2) Обертывает симметричный секретный ключ в зависимости от того, использует ли пользователь ...
2a) ... открытый ключ RSA из пары ключей:

// OAEP wasn't used in this software for hysterical raisins
Cipher wrapper = Cipher.getInstance("RSA/ECB/PKCS1Padding");
wrapper.init (Cipher.WRAP_MODE, user_RSA_PublicKey);

2b) ... кодовая фраза:

SecretKey stretched = ...passphrase stretched through a PBKDF like bcrypt...;
// I don't remember whether it's specified as "AES" or "AESWrap" here
Cipher wrapper = Cipher.getInstance("AES or AESWrap/ECB/NoPadding");
wrapper.init (Cipher.WRAP_MODE, stretched);

2c) Любой маршрут, ключ сеанса переносится:

byte[] wrapped = wrapper.wrap(sessionKey);

3) Используется ключ сеансачтобы создать Cipher, используя Cipher.ENCRYPT_MODE вместе со случайным IV, а затем через него пропускаются данные. Эта часть довольно стандартная, но я могу опубликовать ее, если вы действительно хотите увидеть CipherInputStream использование. Обернутый сеансовый ключ хранится вместе с зашифрованными данными и кучей HMAC всего, что находится под солнцем.

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

Все это работало в течение некоторого времени. Но, конечно, пары ключей RSA становятся большими и медленными, поэтому они хотели бы поддержать дополнительную возможность для шага № 2 выше, в котором открытые ключи генерируются с использованием алгоритма эллиптической кривой (P384 ECDH - это обычный случай). И вот тут мы запутались.

Кажется, что не существует алгоритма замены JCE / преобразования для эллиптических кривых в вызове Cipher wrapper = Cipher.getInstance("RSA/ECB/PKCS1Padding"). Единственный из перечисленных в документации Java - «ECIES», который (?), Кажется, больше нацелен на согласование ключей от нескольких сторон?

Все API, которые я могу найти для встроенного в JCE Java, или дажепросматривая Bouncy Castle, упоминайте только ключи ECDH в контексте соглашения о ключах и транспорта, где они используются для генерации симметричного секретного ключа вместо переноса существующего.

Я чувствую, что мы что-то здесь упускаем, возможно, из-за плохих предположений. Cipher.wrap() действительно не вариант с ключами ECDH? Или это равно , но нам нужно сделать что-то напуганное, чтобы создать экземпляр ECIES Cipher?

Answer 1

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

DH - это алгоритм согласования ключей , в обоих его классических (он же целое число,Zp, modp или форма конечного поля / FF) и ее форма эллиптической кривой (ECDH). Обратите внимание, что по крайней мере для классического DH необработанное значение соглашения g ^ a ^ b mod n = g ^ b ^ a mod n имеет достаточно математической структуры, и людям не удобно использовать его непосредственно в качестве ключа, поэтому мы проводим его через вывод ключафункция, сокращенно KDF. Мне не ясно, что значения ECDH действительно нуждаются в KDF, по крайней мере, для обычно используемых кривых X9 / NIST, включая P384 (вы можете посмотреть или спросить по crypto.SX, если вам не безразлично), но использование KDF дешево и хорошо зарекомендовало себя, поэтомумы делаем это.

Я никогда не слышал, чтобы кто-нибудь отвечал на вызов (EC) по передаче ключа DH, потому что это определенно НЕТ. Это включено в ключ exchange , термин, созданный для обозначения (полезного) объединения транспорта и соглашения.

Вы можете создать схему шифрования , используя (EC) DH , используя согласованное (и производное) значение в качестве ключа для симметричного шифрования - и это - это (EC) IES. Я не знаю, что заставило вас думать, что IES - это нечто другое. Современная практика заключается в том, что симметричное шифрование должно проходить аутентификацию, а стандартизированные формы IES в качестве отдельной схемы используют шифрование CBC с аутентификацией HMAC, хотя вы могли бы правильно разработать схему, которая вместо этого использует, например, GCM.

Как вы видели, поставщик BouncyCastle предоставляет реализации DH (classic) или EC IES "с {AES, DESEDE} -CBC" (в версиях до 1.56 иногда не использовался -CBC), которые используют KDF2 из P1363aс SHA1, указанным шифром CBC и HMAC-SHA1. «Стандартные» (Sun / Oracle / Open) поставщики этого не делают, но вы можете объединить операцию необработанного соглашения, KDF, а также симметричное шифрование и MAC для получения того же результата.

Это похоже (хотя и отличается в некоторых деталях) на работу CMS-ранее-PKCS7 с классическим DH и ECDH и PGP с ECDH . (PGP не поддерживает классический DH; вместо этого используется шифрование ElGamal в качестве альтернативы RSA.) Не говоря уже о TLS (иногда через 1.2, всегда в 1.3) и SSH, в которых используется классический обмен или обмен DH DH (здесь интерактивный, иобычно эфемерно-эфемерно вместо того, чтобы, по крайней мере, иметь статический приемник) для создания секрета, который получается и используется в качестве ключевого материала для симметричного шифрования с аутентификацией данных