Ну ты, блин, семимильными шагами идешь в правильном направлении.
Придраться не к чему, только чуть дополню.
Если коротко, то там предлагается алгоритм, как вычислить k используя приватный ключ и входящий хэш сообщения.
Тут я уточню. Слово "вычислить" - не совсем корректное. Тут правильнее будет сказать "выбрать".
То есть подобрать таким образом, чтобы сторонний человек по-прежнему его бы никак не смог вычислить или подобрать.
Там просто берется дайджест сообщения = 256 бит которые сами являются хэшом каких-то данных
Конкатенируется (то есть дописывается в хвост) приватный ключ. И эти 512 бик хэшируются HMAC-ом и sha256
Или наоборот сперва ключ потом дайджест? Ну почитайте сами. Можно вообще через символ брать то и другое
как зубья у расчески.
Вы спросите почему не хэшировать только sha256? Зачем еще hmac какой-то приплели? Тут я сам не очень
понимаю в чем подвох, но смысл такой, что sha256 - блочный алгоритм хэширования и из-за этого обладающий
проблемами при хэшировании вот таких вот кусков, где одна часть известна. Эту проблему с некоторых пор
даже в биткойне заметили. Асик-буст как раз на этом построен. То есть без hmac у нас падает расчетная сложность
брутфорса. А хорошие криптографы такого не любят.
Короче, число `k` для подписывания можно вычислять любым изъебистым способом. Я, например, не парюсь
и в своих программах беру 128 бит от приватного ключа и 128 бит от дайждеста. Если мой приватный ключ подберут
и сопрут 46 центов с кошелька - я не очень расстроюсь. Но если вы хотите обеспечить в своей программе все по
криптографическому стандарту - юзайте RFC 6979.