Refresh election-guard package

[msprotz]

Election Guard recently started using the Montgomery form API.

[polubelova]

Thanks!

Is it ok that GenericField is not specialized by the length of bignums as it was done for Bignum4096 and Bignum256 (for both 32-bit and 64-bit versions)?

[msprotz]

My understanding is that this is likely going to have no noticeable performance impact. If I hear back otherwise, I'll send another PR for more specialization.

There is one unfortunate outcome of generating the code for Election Guard in MSVC-compatible mode. Consider this array declaration: https://github.com/project-everest/hacl-star/blob/master/dist/gcc-compatible/Hacl_GenericField64.c#L386

This is a VLA array, i.e. an array of variable-length allocated on the stack (len1 is not known at compile-time). Normally (gcc & clang), this is supported, and the behavior is that the array is "freed" at the end of its scope. In this case, the array becomes freed at the end of the loop body (C11 6.2.4§7). So all is good and the stack doesn't explode.

However, MSVC chose not to support VLA. This means that krml cannot emit VLAs for MSVC-compatible code. In this case, krml emits a call to alloca, which unfortunately does not free the underlying resource until the whole function returns. (So, the stack grows for each loop iteration.)

This is quite an unpleasant side-effect, and I feel like we have encountered this before. One solution is to hoist this allocation out of the loop by pre-allocating it. I don't know how much work that would be, though.