I propose we have a recurring bi-weekly meeting Tuesday at 16:00 UTC, 12:00 Eastern, 09:00 Pacific starting next Tuesday, 30 August. Does that work?
https://meet.google.com/moe-zwuu-hag
Hi @Richard Zak I would be interested in attending the meeting. Anyone else?
Changing to start on 06 September to avoid conflict with Wasi Community meetings.
Google Calendar link: https://calendar.google.com/event?action=TEMPLATE&tmeid=MzdlaGNzdDczM2Y4NmtrOHVscHJrNXJpNWNfMjAyMjA5MDZUMTYwMDAwWiByaWNoYXJkLnpha0Bwcm9maWFuLmNvbQ&tmsrc=richard.zak%40profian.com&scp=ALL
@Richard Zak the event link doesn't work for me, can you invite me?
@Frank Denis, @Richard Zak, @Nathaniel McCallum: I would like to invite a couple of fellow Intel team members to the wasi-crypto meeting on January 24th. Is that meeting still going to happen and can I have a few minutes on the agenda to introduce them?
Sure, can you list or send me their emails? I'd like to start having emails so that I can cancel if needed (like for holidays) instead of people not showing up. richard@profian.com
Hi Andrew! Of course, you're welcome to join! I'll be traveling on January 24th and won't be able to join, though. But maybe we can do it next week?
Some points from today's call:
@Frank Denis was asking if we could add those notes to the wasi-crypo repository's meeting minutes?
Do we have a meeting today?
Maybe people are trying to join, but I'm not the meeting organizer, I think Nathaniel was. But when he's not around, nobody can join.
Regarding the last meeting.
1) Sure, having benchmarks would be useful, especially to measure the overhead of wasm+wasi over native implementations, or compare wasmedge vs wasmtime and identify bottlenecks.
2) AES-GCM would indeed benefit from this, so the key schedule doesn't have to be recomputed every time. But for all other AEADs, this is not the case; the key and the IV are mixed into the initial state at the same time. symmetric_state_options_set(state_handle, "nonce", new_nonce)
could be used to reset the state with a new nonce. The downside is that for all ciphers, we'll have to keep a copy of the secret key until the state is destroyed, just in case, even with ciphers having the nice property of not allowing key recovery on state leakage.
Or maybe introduce a symmetric_state_reset()
call that takes the key handle in addition to the IV.
That sounds like a better approach; the key can still be destroyed if the app doesn't intend to reuse it immediately.
For AES-GCM, implementations would still need to keep a reference to the handle, in order to check that it's the same key as in symmetric_state_open()
.
it adds some implementation complexity, but it should be fine.
3) This is awesome. Maybe work with the wasmedge folks since their implementation is in C++?
wasi-crypto meeting now, feel free to join if you're around!
@Frank Denis, I missed this but wanted to attend! My fault: when I saw https://github.com/WebAssembly/wasi-crypto/issues/73 I fumbled around with the links and couldn't figure out how to import it into my calendar but that should be fixed now. I see a meeting on April 4th that I will try to attend. There are a couple others from Intel that may be interested as well.
No biggie. I'm gonna post the minutes for that meeting.
Last updated: Dec 23 2024 at 12:05 UTC