ed25519 закрытые ключи по определению имеют длину 32 бита. Из раздела 5.1.5 RFC8032:
Закрытый ключ состоит из 32 октетов (256 битов, соответствующих b) из
криптографически защищенных случайных данных. См. [RFC4086] для обсуждения случайности.
Я не знаю, откуда у вас 64 символа в вашем вопросе выше. Я мог бы ожидать, что вы смотрите на закодированную длину - но это также не имеет смысла.
Если я сделаю это:
openssl genpkey -algorithm ed25519 -out private.pem
Тогда я получу закрытый ключ в кодировке PEM, который длиной 119 байт. Это кодируется в соответствии с разделом 7 RFC8410. Вы можете посмотреть содержимое следующим образом:
openssl asn1parse -in private.pem
0:d=0 hl=2 l= 46 cons: SEQUENCE
2:d=1 hl=2 l= 1 prim: INTEGER :00
5:d=1 hl=2 l= 5 cons: SEQUENCE
7:d=2 hl=2 l= 3 prim: OBJECT :ED25519
12:d=1 hl=2 l= 34 prim: OCTET STRING [HEX DUMP]:0420F897797B25D84588192CE39F0E6311954034CB80F6D8CD648A3BCBFC2346A83E
Фактический необработанный закрытый ключ сам кодируется как СТРОКА ОКТЕТА внутри СТРОКА ОКТЕТА, показанная выше (в соответствии с RF C 8410). Как вы можете видеть выше, эта строка октетов начинается со смещения 12 с длиной заголовка 2, поэтому сами данные имеют смещение 14:
openssl asn1parse -in private.pem -offset 14
0:d=0 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:F897797B25D84588192CE39F0E6311954034CB80F6D8CD648A3BCBFC2346A83E
, которая показывает закрытый ключ длиной 32 байта в виде ожидается.
Некоторые программы могут хранить ключи в разных форматах, несовместимых с RFC8410 (например, храня закрытый ключ и ключ publi c вместе), поэтому, если вы загрузили этот ключ во что-то другое, это может привести к объясните, откуда идет 64. Вы не можете использовать OpenSSL для генерации этих форматов.
Однако суть в том, что закрытые ключи ed25519 всегда 32-битные, и вы не можете их изменить. Это фундаментальное свойство алгоритма.