<boog900> I think the spy nodes may have finally updated their software, there are no spy nodes under digitalocean & there are nodes passing the spy nodes checks under LionLink: moneronet.info

<boog900> so far it seems like ~200 nodes have switch sides

(removed)

(removed)

(removed)

(removed)

<jeffro256> Yes it's equivalent > <DataHoarder> would doing s_sr = ConvertPointE(d_e * K^j_v) be equivalent?

<jeffro256> To do s_sr = d_e ConvertPointE(K^j_v) and s_sr = ConvertPointE(d_e K^j_v)

<jeffro256> That's interesting that the vartime ed25519 impl is faster, but I honestly can't imagine that this portion of transaction construction is a performance blocker compared to the FCMPs.

Nah, it's for p2pool output calculation context

At least on p2pool we don't need to do the FCMP just make the outputs

jeffro256: annotated my X25519 ScalarMult to clarify that only scalars mod l return valid results, and otherwise they behave as if scalar[31] &= 127 clamping is applied (even when carrot says it's unclamped). This matches mx25519 unclamped behavior and raw rust -dalek library.

Otherwise had failing tests on the custom test vectors when fuzzed

This may be obvious but when one reads github.com/jeffro256/carrot/blob/master/carrot.md#331-curve25519

> In this specification, when we mention scalar-point multiplication, we always mean a "full" scalar multiplication, without "scalar clamping" [15]. Most implementations of X25519 [16], an ECDH algorithm on Curve25519, will "clamp" the scalar, treating some bits implicitly as always 0s or always 1s.

one might think that no clamping at all is done, for full 255 bits

however later > the private view key could be any unclamped element of Fℓ

this then introduces the precondition of scalar being mod l, however, neither mx25519 fork or -dalek do verify this is the case

in real usage this would never be hit but when making unit tests you can have garbage data in garbage data out when specifying random scalars (unreduced)

(removed)

(removed)

(removed)

(removed)

<321bob321> Thanks mbll

<jeffro256> > <DataHoarder> jeffro256: annotated my X25519 ScalarMult to clarify that only scalars mod l return valid results, and otherwise they behave as if scalar[31] &= 127 clamping is applied (even when carrot says it's unclamped). This matches mx25519 unclamped behavior and raw rust -dalek library.

<jeffro256> What do you mean by "only scalars mod l return valid results"? X25519 can take any 32-bit array as a scalar and produce consistent scalar-point multiplications. Just because the 255th bit is ignored doesn't mean that scalars not mod l are invalid. I chose to not clamp the multiplication in Carrot because we need to support l [... too long, see mrelay.p2pool.observer/e/xK6e8sIKc2ZJdkVm ]

yeah, that's what I mean that for real usage the 255th bit is never set (mod l)

however the raw exposed function can take non-mod l scalars, which then have it's 255th bit ignored

this causes a split in tests testing for "full unclamped (all 255 bits are multiplied)" to "255th bit is clamped" (current behavior, which is ok behavior)

say scalar = a046e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4, point = e6db6867583030db3594c1a424b15f7c726624ec26b3353b10a903a6d0ab1c4c

mx25519 scalar mult gives c3da55379de9c6908e94ea4df28d084f32eccf03491c71f754b4075577a28552

unclamped scalar mult (not ignoring 255th bit) gives c1e8b5670164e2296fc04e4aec3bbd7b40b288d7a26f421a3a92afe6a5522939

I wouldn't mind as much as this is fine behavior, except the testcases explicitly then go and include tests with that bit set (against real world usage) so that 255th bit clamping should get documented

(those values are from mx25519 tests from the unclamped fork)

in a few implementations I looked up of the montgomery ladder used for the scalar mult of X25519, they have a comment around using 254 due to 255th bit being clamped between others, but the unclamped one uses the full 255 bits

<jeffro256> This is a far point. I am considering tweaking the derivation of Carrot-derived k_v to do a field-wise clamp of a 32-byte array which would produce equivalent results if doing a true unclamped Curve25519 scalar-point mul with modified scalar or an RFC 7748 clamped scalar-point mul with unmodified scalar. It would give Carrot implementors flexibility with the libraries that they can choose.

Not that it's relevant as a citing but the Wikipedia example en.wikipedia.org/wiki/Elliptic_curv…ion#Constant_time_Montgomery_ladder does use for i from l - 1 downto 0 do where l-1 is 255 so this behavior could be repeated

<jeffro256> DataHoarder: Yes according to RFC 7748, the 254th bit should always be set. mx25519 is non-conforming in this regard

right, yeah, that too, but here I was looking just at the 255th bit itself

in my case I had to lift the inner x25519 scalar mult then adapt it, yeah, would be nicer to use existing libraries for it (or just document it well with a test vector set)

I included your mx25519 fork test vectors here git.gammaspectra.live/P2Pool/consen…rypto/curve25519/montgomery_test.go

<jeffro256> > <DataHoarder> Not that it's relevant as a citing but the Wikipedia example en.wikipedia.org/wiki/Elliptic_curv…ion#Constant_time_Montgomery_ladder does use for i from l - 1 downto 0 do where l-1 is 255 so this behavior could be repeated

<jeffro256> Yes a Montgomery ladder in general can do as many bits as your heart desires, but the X25519 and Carrot spec both ignore the 255th bit

<jeffro256> DataHoarder: Why not just clamp the 255th bit and pass that to some other library ?

yes, clamping would be fine as well. But document it :)

document that X25519 clamping according to RFC is not done, instead 255th bit is clamped and rest are unclamped

in my case I have field elements to do the ladder with so I just imported the single function (and added the tests around it)

Updates: monero-project/research-lab #151#issuecomment-3451901765