Есть ли серьезные проблемы с этим методом генерации симметричных ключей? - PullRequest
Новая
       18

Есть ли серьезные проблемы с этим методом генерации симметричных ключей?

1 голос
/ 28 марта 2011

Я использую технику, заимствованную из книги Брюса Шнайера и Нильса Фергюсона, под названием Практическая криптография .По сути, это сводится к следующему:

Боб делает это:

pubk_A = открытый ключ Алисы

entropy = байты криптографического качества PRNG

encrypted_entropy = RSA_Encrypt pubk_A (энтропия)

hashed_entropy = SHA2-512 (энтропия)

encrypt_key BA = hashed_entropy [0:32]
encrypt_nonce BA = hashed_entropy [32:48]
hmac_key BA = hashed_entropy [48:64]

Боб затем отправляет encrypted_entropy Алисе.

Затем Алиса делает это:

privk_A = закрытый ключ Алисы

entropy = RSA_Decrypt privk_A (encrypted_entropy)

hashed_entropy = SHA2-512 (entropy)

encrypt_key BA = hashed_entropy [0:32]
encrypt_nonce BA = hashed_entropy [32:48]
hmac_key BA = hashed_entropy [48:64]

Это прекрасно работает для генерации ключей, которыеможет быть использованобщаться от Боба до Алисы.Но мне нужны ключи, которые я могу использовать в обоих направлениях.Я думал об изменении алгоритма следующим образом:

Боб делает это с энтропией:

pubk_B = открытый ключ Боба

hashed_entropy BA = SHA2-512 ( SHA2-256 (pubk_A) + энтропия

encrypt_key BA = hashed_entropy [0:32]
encrypt_nonce BA = hashed_entropy [32:48]
hmac_key BA = hashed_entropy [48:64]

hashed_entropy AB = SHA2-512 ( SHA2-256 (pubk_B) + энтропия

encrypt_key AB = hashed_entropy [0:32]
encrypt_nonce AB = hashed_entropy [32:48]
hmac_key AB = hashed_entropy [48:64]

Алиса может сделать то же самое на своей стороне после получения энтропии путем расшифровкиencrypted_entropy.

Как видите, теперь есть два набора ключей: один используется для связи от Боба к Алисе, а другой для связи от Алисы к Бобу.

Есть личто-то не так сэто что?Какие риски безопасности я принимаю?Является ли безопасность системы меньшей или большей, чем если бы у меня просто была небольшая настройка одной стороны?Есть ли лучший способ справиться с этой проблемой без добавления циклов?

1 Ответ

1 голос
/ 28 марта 2011

У Алисы и Боба не должно быть проблем с общим ключом для двунаправленной связи. На самом деле это очень похоже на общий секретный ключ SSL / TLS . Единственное соображение заключается в том, что вы не можете использовать одну и ту же комбинацию iv+master key с любым пакетом. Также этот iv должен быть случайным .

Одним из улучшений, которое можно внести в этот протокол Шнайера / Фергюсона, является использование режима cmac , что устранит необходимость в hmac_key. Это уменьшит полосу пропускания, используемую при квитировании и использовании процессора для каждого пакета.

С точки зрения вашего варианта этого протокола. Вы все еще должны полагаться на передачу encrypted_entropy = RSA_Encryptpubk_A(entropy). Это важный шаг, потому что вам нужно иметь общий секрет. Использование известного значения pubk_A в генерации ключей меня беспокоит. Помните, что следует предположить, что любой открытый ключ известен злоумышленнику. Использование sha256 не делает это значение более случайным или более сложным для грубой силы. Таким образом, число предположений, которые должен сделать атакующий, эквивалентно для этих трех вычислений: sha512(sha256(pubk_A)+entropy), sha512(pubk_A+entropy), sha512(entropy). Это означает, что это пустая трата ресурсов, потому что вы не получаете преимущество над нападающим.

...