Expose blst internals #6829
Expose blst internals #6829
Conversation
| Sec: TSecretKey<Sig, Pub> + Clone, | ||
| { | ||
| /// Instantiates `Self` from a `point`. | ||
| /// Takes a reference, as moves might accidentally leave behind key material |
There was a problem hiding this comment.
Can you elaborate on this? Is it because zeroize only happens on drop, and a move is implemented as a memcpy without a drop?
There was a problem hiding this comment.
Exactly.
Cloning here ensures that we have two owned blst::min_pk::SecretKey, which will be zeroed each on drop. Moving may or may not do a memcpy (up to rustc to inline or do other optimisations), and may cause data to be left behind.
See also: https://docs.rs/zeroize/latest/zeroize/index.html#stackheap-zeroing-notes
There was a problem hiding this comment.
I suspect there are other places we've run afoul of this. Good to know.
I wonder how invasive it would be to use Pin on secret keys. Might be an exploration for another day
michaelsproul
added
crypto
|
@mergify dequeue |
|
This pull request has been removed from the queue for the following reason: Pull request #6829 has been dequeued by a You should look at the reason for the failure and decide if the pull request needs to be fixed or if you want to requeue it. If you want to requeue this pull request, you need to post a comment with the text: |
✅ The pull request has been removed from the queue
|
|
CI will fail until we merge: |
|
@mergify requeue |
✅ The queue state of this pull request has been cleaned. It can be re-embarked automatically |
Add several functions to
Generic*inbls, in cases where access to the underlyingblsttypes is needed.This will be needed in Anchor.