curve25519-dalek: add batch montgomery conversion

[apoelstra]

This is useful for vanitygenning curve25519 keys. Unsure of other usecases.

[tarcieri]

Seems like this could be implemented in an alloc-free manner using const generic arrays, although that would limit the input type to an array

[apoelstra]

Seems like this could be implemented in an alloc-free manner using const generic arrays, although that would limit the input type to an array

Agreed. It seems like it but it's a bit tricky. In the libsecp code we take an outptr for the result and during computation we abuse that as scratch space.

But here our output is a bunch of MontgomeryPoints which I think are big enough to abuse as scratch space, but internally they have a [u8; 32] and our scratch space consists of Scalars and I was worried that the conversions might cost some time.

I can give it a shot later today.

[apoelstra]

Oh, I realize that in your suggestion I don't need to reuse space; I can have multiple on-stack arrays of the appropriate length.

But if I do reuse space, then I could implement this by taking a &[Edwards] and &mut [Montgomery] and assert_eqing that their lengths match. This is un-Rustic but lets the user reuse a buffer and avoids any allocations.

[tarcieri]

Using const generics would allow you to return a same-sized array and avoids the runtime panic conditions

[apoelstra]

If I use const generics I see a slight slowdown with a batch size of 128, as well as blowing up the user's stack space (and limiting the API). I don't know that this is worth making the function work in a no-alloc context.

If I try to implement the outptr solution where the user passes a &mut [MontgomeryPoint], with safe code I see a massive slowdown due to the conversion costs when temporarily storing FieldElements in the slice.