Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto_sign_ed25519_sk_to_curve25519 assertion error #60

Open
hklee93 opened this issue Sep 22, 2021 · 1 comment
Open

crypto_sign_ed25519_sk_to_curve25519 assertion error #60

hklee93 opened this issue Sep 22, 2021 · 1 comment

Comments

@hklee93
Copy link

hklee93 commented Sep 22, 2021

Hi, I'm trying to convert my ed25519 keypair to x25519 keypair, which can be achieved by provided functions

  • sodium.crypto_sign_ed25519_pk_to_curve25519(x25519_public, ed25519_public)
  • sodium.crypto_sign_ed25519_sk_to_curve25519(x25519_secret, ed25519_secret)

Currently I'm generating x25519 keypair buffer with the following functions

{
  publicKey: sodium.sodium_malloc(sodium.crypto_box_PUBLICKEYBYTES),
  secretKey: sodium.sodium_malloc(sodium.crypto_box_SECRETKEYBYTES)
}

I was able to convert public key, but it looks like converting secret key raises the following assertion error.

edSk must be 'crypto_sign_ed25519_SECRETKEYBYTES' long

My ed25519 secret key is 32 bytes, and it looks like crypto_sign_ed25519_SECRETKEYBYTES is 64 bytes. Now what I'm curious is even though it's checking for 64 bytes, it looks like a subsequent call is only using 32 bytes of the buffer

crypto_hash(h, edSk, 32)
  1. Is there a reason the assertion is looking for 64 bytes when only 32 bytes are being used?
  2. Is it safe if I just pad additional 32 bytes to my private key and pass this assertion?
@AiyionPrime
Copy link

I'm new to the topic and have been reading on curves for only about a week now.

One thing I came to learn was the difference between the seed and the secret key.
The seed is 32 bytes of random.
You can create the secretkey from it which is effectively a concatenation of the seed and the resulting public key.
There is the a function to extract the pubkey from the secretkey (taking only the latter 32 bytes of the 64 byte secret.

So if your "ed25519-secret" is 32 bytes long, you likely confused it with the seed.

You should be able to feed it into crypto_sign_seed_keypair, where pk and sk are variables to store the resulting keypair in.

function crypto_sign_seed_keypair (pk, sk, seed) {

This appeared to be a little confusing at first,
but gives major speed advantages once you sign content and have do not really have to calculate the pubkey over and over again.

The answer to the second is no. The forged key would be invalid.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants