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

NaCl: add default parameter for optional random generated sk #668

Closed
wants to merge 1 commit into from

Conversation

anonimal
Copy link
Contributor

This is useful for implementations who can't afford to clobber the
existing sk buffer or who are limited by their existing interface
(e.g., they must re-use the privkey).

This is needed for monero-project/kovri#909.

@noloader I know, altering the interface is heresy. I welcome your feedback.

This is useful for implementations who can't afford to clobber the
existing sk buffer or who are limited by their existing interface
(e.g., they *must* re-use the privkey).
@anonimal
Copy link
Contributor Author

anonimal commented Jul 3, 2018

ping @noloader

noloader added a commit that referenced this pull request Jul 17, 2018
This should allow users to convert a ed25519 seret key to a public key without rolling their own code
@noloader
Copy link
Collaborator

noloader commented Jul 17, 2018

@anonimal,

Sorry about the late reply here.

We added a new functions called crypto_sign_sk2pk. It should accomplish what you need without changing the API. Doxygen docs at crypto_sign_sk2pk(). The important part is:

crypto_sign_sk2pk() creates an ed25519 public key from an existing 32-byte secret key. The function does not backfill the tail bytes of the secret key with the calculated public key.

That means the check-in differs from the pull request by not back-filling the public key into the tail of the secret key. If you want the public key concatenated with the secret key then perform a memcpy after crypto_sign_sk2pk(). It also means your sk buffer must be at least 64-bytes in size (which I was not clear if it was the case).

Also see Commit d8946df8eb34 and Kovri | PR 909.

@noloader noloader closed this Jul 17, 2018
@anonimal
Copy link
Contributor Author

Thank you so much @noloader !

Very important note: this is not for the Java I2P library as noted in Doxygen. This is entirely a Kovri request, and kovri has no java I2P interoperability (as in, we don't use their libraries in any way). They also do not use crypto++ in any way. We are also not associated with their project in any way outside of the open specifications that they provide.

Should I open a pull request?

@anonimal
Copy link
Contributor Author

Sorry, we're nearing a release so my stress level is to the max and I overlooked what you meant.

no java I2P interoperability

We are interoperable, but I think it's important to note that this is a specification requirement and not a library one because A) we may continue to use this function if/when we don't use I2P (or choose not to interop with Java I2P) and B) because the function itself is a cool tool which, IMHO, can also be applied elsewhere.

anonimal added a commit to anonimal/kovri that referenced this pull request Jul 19, 2018
weidai11/cryptopp#668

The fix is useful for implementations whose interface can't clobber
the existing sk buffer (or *must* re-use the privkey). We require both.

Thanks to noloader for the assistance. Referencing monero-project#909.
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

Successfully merging this pull request may close these issues.

2 participants