-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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
x/crypto/ed25519: use array pointers for keys #24376
Comments
The older crypto packages were written with the assumption that #395 would be resolved. However, that hasn't happened and using array pointers is kind of a pain without out. Ed25519 is newer and so uses a different convention. If anything, unless #395 is going to be fixed, I'd suggest converting the older packages to taking slices rather than converting |
Could you give me a hint what the problem with array pointers for keys is? It seems to me that the lack of a fix for #395 is an argument against slices (since conversion to slice via [:] is simple, but the opposite impossible). I understand if you want to keep the API stable for this one, but for future additions I don't see the redeeming features of key slices. Keys with variable size are a completely different situation of course. |
I think the discussion on #395 covers it pretty well: if you're throwing bytes around in Go, you're probably using I agree about the benefits of array pointers which is why I initially used them, but it was in the expectation of being able to cast from slices to array pointers to avoid that clunkiness. |
(p.s. to be clear: if adding signature support to the |
Thanks I see your point now. I'm not sure sacrificing the more elegant and safe interface is worth the potential convenience here, but that's obviously a matter of opinion. Maybe the crypto package should just provided a set of conversion functions that use unsafe:
That would be about as convenient (and safe) as a proper fix to #395. But I guess that's a separate issue. |
Most other packages in crypto seem to use array pointers (
*[n]byte
) for keys instead of slices where the size is known. ed25519 uses[]byte
for both private and public keys.Since #395 is still unresolved there no way to retrieve array pointers in a safe way, which makes mixing these conventions especially useful (resolving #24350 will likely use ed25519.GenerateKey, but should probably array pointers to remain consistent with it's friends at nacl/*).
/cc @agl
The text was updated successfully, but these errors were encountered: