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

Add a method to deserialize SecretKeyFactory from an externally created bytestring #57

Closed
fjarri opened this issue Jun 23, 2021 · 2 comments · Fixed by #64
Closed

Add a method to deserialize SecretKeyFactory from an externally created bytestring #57

fjarri opened this issue Jun 23, 2021 · 2 comments · Fixed by #64
Labels
API Related to public API enhancement New feature or request
Milestone

Comments

@fjarri
Copy link
Contributor

fjarri commented Jun 23, 2021

This is useful for the cases where one wants to derive SecretKeyFactory deterministically. One could use from_bytes() (because any 64 bytes will lead to a valid SKF), but it is better to make it a separate explicit method, to emphasize that the bytes did not come from an earlier SKF serialization. SecretKeyFactory.from_secure_random_bytes()? We will also need to expose the required bytestring length somehow.

@fjarri fjarri added the API Related to public API label Jun 23, 2021
@fjarri fjarri added this to the v1.0.0 milestone Jun 23, 2021
@fjarri fjarri added the enhancement New feature or request label Jun 23, 2021
@cygnusv
Copy link
Member

cygnusv commented Jul 6, 2021

In the context of umbral, 32 byte long input seeds are sufficient, assuming they have high entropy. What I'm not sure is how to support longer input seeds.

@fjarri
Copy link
Contributor Author

fjarri commented Jul 6, 2021

For now we can limit the seeds to 32 bytes, possibly allowing larger seeds in the future - this won't break backward compatibility. For larger inputs, could we just use an HKDF?

One thing that I am not sure about: if we require high-entropy bytes (and pass them directly to the constructor), should we call it "seed"? To me, that implies that it can be something like a password, too. Should we emphasize the high-entropy requirement in the method name? Like from_secure_random_bytes() above, or something along these lines?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Related to public API enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants