Comments 8
А как с ГОСТ-ами быть?
Просто sha наменить на stribog или еще что-то?
Есть какие-то отечественные аналоги?
Российский стандарт описывает принципиально такую же схему, но в качестве хэш-функции используется Стрибог. Более подробно с отечественным стандартом можете ознакомится здесь: tc26.ru/standard/rs/Р%2050.1.113-2016.pdf
Но что поделать, если существующие ключи не обладают достаточной длиной для их безопасного использования в выбранных нами алгоритмах?
А можно поподробнее узнать почему вы решили что в итоге увеличивается криптостойкость?
Вот например чтобы усложнить атаку Брутфорсом (атаку полным перебором) увеличивают стоимость расчета одного ключа. Например вот таким кодом можно в 100 тысяч раз увеличить сложность перебора (т.е. фактически увеличивается длина ключа примерно на 16 бит):
Пример кода:
function GetPrivateKeyFromStr(Str)
{
var StrHex=sha3_str(Str);
for(var i=0;i<100000;i++)
StrHex=sha3_str(StrHex);
return StrHex;
}
Таким образом злоумышленнику каждый вариант ключа требуется сначала 100 тысяч раз пропустить через хэш, а только потом приступить к самой проверке о правильности приватного ключа
а электричество мама оплачивать будет?
А можно поподробнее узнать почему вы решили что в итоге увеличивается криптостойкость?
Это утверждение из стандарта NIST, который можно найти по ссылке [3]:
As long as the key-derivation key is kept secret, the derived keys may be used in the same manner as randomly generated keys.
Если даже исходный ключ случайный (что случается не всегда), то его стойкость не превосходит стойкость сгенерированного ключа, который точно случайный.
И я не очень понял, как приведенный Вами пример позволяет усилить защиту от полного перебора, ведь выходное значение у хэш-функции будет постоянной длины. У нас же останется такая же размерность ключа, который был на первой итерации её использования? Тогда и число возможных ключей такое же останется.
Sign up to leave a comment.
HKDF: как получать новые ключи и при чем тут хэш-функции