lambdaworks icon indicating copy to clipboard operation
lambdaworks copied to clipboard

Implement Montgomery backend with 32 bits

Open MauroToscano opened this issue 2 years ago • 11 comments
trafficstars

Currently montgomery backend works with limbs of 64 bits. For really small fields, like babybear, it may be useful to have a 32 bits version. This version doesn't need to support multiple limbs, since it's use is limited to this field, but it may be useful to generalize it.

  • [ ] Implement a montgomery backend of 32 bits, with only one u32 as limb.
  • [ ] Add a fuzzer to compare both montgomery backends
  • [ ] Generalize it to be multi limb

We recommend just doing the first task, then generalizing

MauroToscano avatar Sep 04 '23 13:09 MauroToscano

I can take up this!

RajeshRk18 avatar Sep 07 '23 20:09 RajeshRk18

I can take up this!

@RajeshRk18 still working on this?

iammadab avatar Sep 11 '23 14:09 iammadab

I can take up this!

@RajeshRk18 still working on this?

Yeah, wip

RajeshRk18 avatar Sep 11 '23 22:09 RajeshRk18

:wave: Could I take this one?

skaunov avatar Feb 24 '24 08:02 skaunov

:wave: Could I take this one?

It's almost done. Just need to add fuzzer.

RajeshRk18 avatar Feb 24 '24 09:02 RajeshRk18

Am I correct that for generalizing over both word size the only way is to move const fn from impl blocks, as being generic instantly prevents them from working? So minimum boilerplating would be with a trait Word for generic and having macros for const fn (anyway they're associated) which would generate it for the type aliases... And is intricate to balance readibility/maintainability of such solution with wins from having u32 backend?

Just trying to understand this issue better. Sorry if miss/confused something. Would be nice to see correction of my comprehension of this one! :pray:

skaunov avatar Feb 25 '24 23:02 skaunov