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 async API and crypto traits #141

Open
jessa0 opened this issue Oct 10, 2022 · 1 comment
Open

Add async API and crypto traits #141

jessa0 opened this issue Oct 10, 2022 · 1 comment

Comments

@jessa0
Copy link
Contributor

jessa0 commented Oct 10, 2022

I've been starting to think about how to add support for async crypto engines to snow (like crypto coprocessors, or in my case, the Web Crypto API). The Web Crypto API is particularly difficult to work with together with snow, as one cannot simply spawn another thread to drive snow synchronously since the wasm32-unknown-unknown target doesn't support threading, and Web Workers are a pain to work with.

Adding this support seems difficult to do cleanly in a DRY way, as every function in snow which uses cryptography (which is a lot of them) would need to be made async, and awaits added appropriately. In fact, most of what snow's code does is drive crypto, so having separate copy-paste implementations for a separate async API, for example, would make maintenance pretty painful and error-prone.

Another technique I've seen for supporting both sync and async APIs is using macros like in the redis crate, but personally heavy use of macros is something I'd want to avoid. One good takeaway from the redis API, however, is that snow could add an optional async API by having HandshakeState/TransportState implement new AsyncHandshake/AsyncTransport traits which the user can choose to use if desired.

Another technique found in the mongodb crate is to write the implementation using async/await and have the sync API use some implementation of the block_on function from one of the async runtimes to wait on the Futures returned from the async implementation. In snow's case, assuming the CryptoResolver trait were made to return Futures, block_on could be added to the trait as well so that, if it knows that it returns all synchronous crypto implementations, its block_on implementation could be as dead simple as polling a Future once using noop_waker.

I'm still looking into more techniques for supporting parallel sync & async APIs, but I'd love to hear thoughts on whether any of this seems worthwhile / viable to support in snow.

@jessa0
Copy link
Contributor Author

jessa0 commented Oct 12, 2022

One thing to note about adding AsyncCipher, AsyncDh, and AsyncHash traits is that, unless we add a R: CryptoResolver generic parameter to snow's structs instead of storing a trait object (which is required to have all associated types specified), we have to return Pin<Box<dyn Future>> from any async trait methods, which would add an allocation and deallocation to every crypto operation.

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

1 participant