Нужна ли мне соль при получении новых ключей с помощью HKDF, если мастер-ключ надежный? Подходит ли глобальная соль?

Допустим, у меня есть главный ключ, и я хочу использовать его для получения новых ключей для шифрования с использованием HKDF. Я немного смущен относительно использования соли, хотя. Я видел другие сообщения об этом здесь, но я до сих пор не совсем понимаю, когда и следует ли мне его использовать.

Сценарий: A создает MasterKey и делится им с B, C, D. A получает разные ключи для B, C и D и шифрует некоторые данные (для каждого из них). Теперь я хочу, чтобы они могли получать одни и те же новые ключи на основе некоторых входных данных, чтобы они могли расшифровывать свои данные.

HKDF(MasterKey, соль: "", информация: "некоторые данные-B", хэш: "SHA256")
HKDF(MasterKey, соль: "", информация: "некоторые данные-C", хэш: "SHA256")
HKDF(MasterKey, соль: "", информация: "некоторые данные-D", хэш: "SHA256")
...

Соль здесь необязательна, но ее использование добавляет «силы». Это полезно только в том случае, если MasterKey слаб?

Если мой MasterKey "достаточно" силен - нужна ли мне соль? Если нет, то что является достаточно сильным? Достаточно ли случайной шестнадцатеричной строки из 32 символов?

Если я все же должен использовать соль, нормально ли, чтобы все B, C и D использовали одну и ту же соль, или они должны быть уникальными (в RFC упоминается, что соль можно использовать повторно, но не совсем понятно, что они означают)?

Соль здесь необязательна, но ее использование добавляет «силы». Это полезно только в том случае, если MasterKey слаб?

Если Мастер-ключ не является равномерно случайным, то шаг извлечения извлекает равномерную случайность из текущей энтропии материала входного ключа (IKM) (ваш пароль или ключ, или ..). Соль способствует усилению HKDF и поддерживает независимую от источника экстракцию, так что два разных IKM дают два разных извлеченных результата. Можно извлечь выгоду из независимого от источника извлечения, даже если у них есть единый случайный ключ с достаточной надежностью.

Если мой MasterKey "достаточно" силен - нужна ли мне соль? Если нет, то что является достаточно сильным? Достаточно ли случайной шестнадцатеричной строки из 32 символов?

Сильный - это не показатель. Если у вас есть однородные случайные биты, вам не нужен шаг извлечения из ХКДФ. Размер бит зависит от того, где вы будете их использовать; 128-битный для AES-128, 256-битный AES-256 и т. д.

Если я все же должен использовать соль, нормально ли, чтобы все B, C и D использовали одну и ту же соль, или они должны быть уникальными (в RFC упоминается, что соль можно использовать повторно, но не совсем понятно, что они означают)?

На самом деле, как только вы получите псевдослучайный ключ (PRK) на этапе извлечения, для получения ключей вам нужно только изменить информационный тег.

Повторное использование соли означает отсутствие независимой от источника добычи, вы расширяете один и тот же PRK на расширить шаг. Вы можете использовать разные PRK для разных пользователей.

Подходит ли глобальная соль?

Шаг расширения использует HMAC с ключом PRK.

HMAC-хэш (PRK, T (0) | информация | 0x01)

HMAC — это PRF, и вы используете глобальную соль, а затем исправляете PRF. Единственная проблема, которую я вижу, это коллизия вывода в долгосрочной перспективе. Хотя можно легко создавать и хранить соли и получать семейство PRF вместо одного, так почему бы не использовать разные соли для каждого пользователя?

Есть два больших раздела в rfc5869

3.1. С солью или без соли

Тем не менее, даже солевое число менее качественного (короче в размера или с ограниченной энтропией) может все же иметь значительное вклад в безопасность выходного ключевого материала; дизайнеры Поэтому рекомендуется указывать значения соли для HKDF, если такие значения могут быть получены приложением.

некоторые приложения могут даже иметь секретное солевое значение, доступное для использования; в таком случае HKDF предоставляет еще более надежную гарантию безопасности.

3.2 Ввод информации в HKDF ... Его основная цель - связать полученный ключевой материал с информацией, специфичной для приложения и контекста. Например, «информация» может содержать номер протокола, идентификаторы алгоритмов, идентификаторы пользователей и т. д. В частности, это может препятствовать получению одного и того же ключевого материала для разных контекстов (когда один и тот же входной ключевой материал (IKM) используется в таких контекстах). разные контексты).

На самом деле это неправильный способ генерации и распространения ключа. Вам следует рассмотреть криптографические решения с открытым ключом, такие как RSA-KEM или ECHE, где результат обоих должен быть передан из KDF перед использованием для шифрования.