Stephan Koch

Thanks. I see the problem and agree that the next major release should enforce only one operation sequence as defined in the spec. It would be good if the wrong...

> Yes, this is certainly something that we could add for the next update to the specification. That would be great, thx! > Based on my understanding of the specifications,...

> The description in https://ascon.iaik.tugraz.at/specification.html and the parameters in the NIST submission have rate _r_ = 64 for both Ascon-Hash and Ascon-HashA. You are right, I have looked into the...

Sounds good, thanks!

Thanks for promoting this PR! Regarding the signature: the parameter ordering of the [original proposal above](https://github.com/ARM-software/psa-api/issues/50#issuecomment-1772551575) is consistent with the ordering in #149 for `psa_import_formatted_key()` and `psa_export_formatted_key()` which is consistent...

I do not have a clean solution but at least a workaround: Setting `device = nrf52840_dk_bsp::hal::target` (the pac) works for me: ``` #[rtic::app(device = nrf52840_dk_bsp::hal::target, monotonic = rtic::cyccnt::CYCCNT)] ``` To...

> The 2024 update to 802.11 is now finalized (late September) - I presume that contains all of the required specification now? [IEEE Std 802.11™-2024 was approved on September 26,...

> Questioning the value in explicitly specifying the hash parameter. > > An implementation that only supports the standard can determine the correct hash function from the cyclic group and...

> > My inclination at this point is to remove the explicit parameterization - because it provides no benefit to the caller of the API, but does incur cost to...

> The effect of the incremental changes to WPA3-SAE (2016 -> 2020 -> 2024) is that there are notionally 3 distinct variants: > > 1. PWE generation by looping, using...