Bouncy Castle Diffie-Hellman KeyAgreement с KDF: Что такое материал ключей пользователя? - PullRequest
Новая
       82

Bouncy Castle Diffie-Hellman KeyAgreement с KDF: Что такое материал ключей пользователя?

0 голосов
/ 26 февраля 2019

В документации Диффи-Хеллмана Bouncy Castle говорится об использовании "материала пользовательского ключа" и KDF при получении эфемерных ключей из статической пары долгосрочных ключей.Нет никакого упоминания о том, как сгенерировать этот материал ключа.

Например, в BCFipsIn100.pdf у них есть этот пример: 

    public static byte[] initiatorAgreementWithKdf(PrivateKey initiatorPrivate, PublicKey recipientPublic, byte[] userKeyingMaterial) throws GeneralSecurityException {
        KeyAgreement agreement = KeyAgreement.getInstance("ECCDHwithSHA384CKDF", "BCFIPS");
        agreement.init(initiatorPrivate, new UserKeyingMaterialSpec(userKeyingMaterial));
        agreement.doPhase(recipientPublic, true);
        SecretKey agreedKey = agreement.generateSecret("AES[256]");
        return agreedKey.getEncoded();
    }

В их примерах используются статические строки для userKeyingMaterial, но makeвообще не упоминается, что это должно быть.

Каковы спецификации для генерации userKeyingMaterial?Может ли это быть одна статическая строка, как в их примерах, или это по сути одноразовый номер?Какая длина?Можно ли обмениваться ими публично, когда стороны обмениваются открытыми ключами?

1 Ответ

0 голосов
/ 27 февраля 2019

Используется как параметр extraInfo в классе DHKDFParameters, который используется для инициализации KDF.KDF может использоваться для получения различных ключей из главного ключа путем смешивания дополнительных байтов помимо общего секрета, вычисленного по алгоритму согласования ключей, в данном случае ECCDH.SHA384KDF, скорее всего, является совместимым с ANS X9.63 KDF, который принимает дополнительную строку октетов Info (для этой строки октетов (например, байтового массива) существуют различные имена, основанные на информации.

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

Обычно это просто статическая строка, называемая меткой. Нет ограничений по длине, и данные могут быть опубликованы публично.secret будет гарантировать, что полученный ключ будет просто передан правым сторонам, если соединение так или иначе аутентифицировано 1010 *, вам необходимо знать, с кем вы выполняете соглашение о ключе, в конце концов.

...