<jeffro256> Nope

<jeffro256> It probably should at some point

<jeffro256> It creates complete results AFAICT. I test scalar-point multiplication by doing scalar-point multiplications on Ed25519, then converting them to X25519 since they are birationally equivalent

<jeffro256> So it at least gets those values right, as well as the RFC 7748 test vectors

<jeffro256> And scalar-point multiplication over X25519 is basically the only operation Carrot cares about. An audit would probably have results limited to perhaps side channel attacks, or memory sanitization

<jeffro256> But iy should probably be done eventually

<jeffro256> Key generation doesn't even happen on mx25519

did implement unclamped scalar mult as well and they match on edge cases

that said, I am unhappy about "unclamped" naming, given the input is still clamped for arbitrary input bytes

input scalar needs to be mod l compared to other methods that do apply modulo reduction to it first, otherwise the top bit is dropped

this is not relevant for our inputs (the scalars will never have that bit set), but it's not a totally "unclamped" mul

<jeffro256> Are you talking about your library or mx25519?

<jeffro256> The _unclamped refers to the operation, not the key

<jeffro256> Because if the key is pre-clamped, and the operation doesn't ignore bit 254, then all operations act like they're clamped

<jeffro256> Re: mx25518 audits:

<jeffro256> I haven't tested ARM (Linux & MacOS ABIs) as throughly simply because I don't have an ARM machine. That may yield some useful results

I can test on Mac soon

<jpk68:matrix.org> If there's some test suite you have for it, I can test on ARM Linux as well

We have github CI now that builds on ARM

jeffro256: I refer to the MSB, which is always cleared, vs the other option of doing modulo reduction on it

should be documented that behavior (topmost bit clearing, 255) is done at least, or as a precondition. In case anyone else uses it

Unclamping bit 255 would require an additional ladder step.

yeah, so it should just be documented as a behavior (which is not that clear with the _unclamped) name

for the test vectors, scalar a046e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4 * point e6db6867583030db3594c1a424b15f7c726624ec26b3353b10a903a6d0ab1c4c is the same as

a046e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449a44 * the point above (note last byte has top bit removed)

where even the tweaked rfc 7748 has that bit ignored/unprocessed/forced unset (depending what you want to call it)

no input we send should afaik have that bit set for monero carrot usecases, but if it's being upstreamed that should be documented or someone might expect that bit to also be used when it's not