Closed skaht closed 4 years ago
SECRET_KEY = "1a8b1ff05ded48e18bf50166c664ab023ea70003d78d9e41f5758a91d850f8d2"
This is 32 bytes, while crypto_sign_SECRETBYTES
is 64.
Your secret is actually the seed. In order to create an actual keypair from the seed, use crypto_sign_seed_keypair()
.
Your assistance is greatly appreciated:-)
I'm using SLIP 10 technology as the basis to synthesize the private keys. So I'm discovering by trial-and-error the hidden libsodium state that needs to be properly set to initialize libsodium's private keys to properly synthesize associated public keys, and to fully initialize libsodium's private keys to perform signature operations.
Added the following to the code above to fix the issue identified:
After "unsigned char sk[crypto_sign_ed25519_SECRETKEYBYTES] = { 0 };" :
unsigned char seed[crypto_sign_SEEDBYTES]; unsigned char ed25519_pk[crypto_sign_ed25519_PUBLICKEYBYTES];
After " sodium_hex2bin( sk, sizeof(sk), (const char*)hex_secret_key, message_length, NULL, NULL, NULL ); // converts hex secret key to binary sk":
crypto_sign_ed25519_sk_to_seed( seed, sk ); crypto_sign_seed_keypair( ed25519_pk, sk, seed );
The following code was whittled down from code that was unreliable at generating results to a test vector documented in an IETF draft. The reliability of generating matching results was a function of the source code and was independent upon the compiler (e.g., using clang++ or g++) and the distribution of the code (e.g., using Homebrew or compiling straight from https://github.com/jedisct1/libsodium/tree/stable). An independent 3rd party replicated the same issue within their development environment.
Any assistance for trouble shooting the following standalone code will be greatly appreciated.
cat sign_isolate_D.cpp
If executes properly, the results will be:
% ./sign
Actual results for executing the code above:
% ./sign1
Note that the R components of the signatures match, but the S components differ.