00:48:02 <br-m> <jeffro256> Nope 
00:48:21 <br-m> <jeffro256> It probably should at some point 
00:50:01 <br-m> <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 
00:50:32 <br-m> <jeffro256> So it at least gets those values right, as well as the RFC 7748 test vectors
00:51:54 <br-m> <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 
00:52:08 <br-m> <jeffro256> But iy should probably be done eventually 
00:52:43 <br-m> <jeffro256> Key generation doesn't even happen on mx25519
08:02:54 <DataHoarder> did implement unclamped scalar mult as well and they match on edge cases
08:03:41 <DataHoarder> that said, I am unhappy about "unclamped" naming, given the input is still clamped for arbitrary input bytes
08:04:33 <DataHoarder> 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
08:05:02 <DataHoarder> this is not relevant for our inputs (the scalars will never have that bit set), but it's not a totally "unclamped" mul
18:09:37 <br-m> <jeffro256> Are you talking about your library or mx25519? 
18:09:55 <br-m> <jeffro256> The _unclamped refers to the operation, not the key 
18:10:31 <br-m> <jeffro256> Because if the key is pre-clamped, and the operation doesn't ignore bit 254, then all operations act like they're clamped 
18:34:56 <br-m> <jeffro256> Re: mx25518 audits:
18:34:56 <br-m> <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   
19:16:59 <selsta> I can test on Mac soon
19:17:57 <br-m> <jpk68:matrix.org> If there's some test suite you have for it, I can test on ARM Linux as well
19:24:15 <tevador> We have github CI now that builds on ARM
20:28:03 <DataHoarder> jeffro256: I refer to the MSB, which is always cleared, vs the other option of doing modulo reduction on it
20:29:07 <DataHoarder> should be documented that behavior (topmost bit clearing, 255) is done at least, or as a precondition. In case anyone else uses it
20:30:59 <tevador> Unclamping bit 255 would require an additional ladder step.
20:35:54 <DataHoarder> yeah, so it should just be documented as a behavior (which is not that clear with the _unclamped) name
20:36:36 <DataHoarder> for the test vectors, scalar a046e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4 * point e6db6867583030db3594c1a424b15f7c726624ec26b3353b10a903a6d0ab1c4c is the same as
20:36:53 <DataHoarder> a046e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449a44 * the point above (note last byte has top bit removed)
20:38:48 <DataHoarder> where even the tweaked rfc 7748 has that bit ignored/unprocessed/forced unset (depending what you want to call it)
20:39:54 <DataHoarder> 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