Adding Ascon to cryptolib

[0x67757300]

Hello

I'm just wondering if there are any plans to include Ascon to cryptolib.

If not, would there be any objections against it? I can write the code.

[andrewleech]

That does look like an interesting library.
Do you have a particular use case in mind?

For example libhydrogen is used in STM32 mboot to provide a lightweight, "hard to misuse" symmetric encryption and asymmetric authentication.

I always thought it might be handy to expose it in cryptolib too but haven't found a use case to make it worth adding the code / flash usage.

There's not much harm in adding things that are disabled by default, they can be enabled for a build when needed.

Alternatively I see there's a reference python implementation, that could possibly be ported and added to micropython-lib, though presumably the speed will be significantly worse than C.

[0x67757300]

I always find my self in constant need of streaming encryption in my projects. Oops.

It's pretty easy and safe to do that with Ascon. A lot safer than using, say, RC4.

libhydrogen is awesome. However, it has its own specification. I think it would be nice to have a NIST specification.

Ascon was designed as a replacement for AES in embed. And, after winning LWC, it officially is.

If AES is in cryptolib, I don't see any reason not to include Ascon as well. Especially for boards that don't have hardware for AES, since Ascon is very efficient in software.

[andrewleech]

I always find my self in constant need of streaming encryption in my projects. Oops.

Haha, nothing wrong with that. It would be interesting to hear some examples!

I haven't personally been very involved in the crypto tech space so NIST standards/specifications don't mean much to me in terms of choosing algorithms.
That being said it seems clear a lot of effort was put into that process to select it as an embedded crypto of choice.

They're in the process on standardizing it now... do you know how stable the reference implementations are?

[0x67757300]

Yeah, it might be better to wait for the final spec.

For now, I'm gonna write some benchmarks between the Python, C and ARMv6-M optimized implementations for the RP2 port.