<j​effro256:monero.social> Actually, in Carrot, it might be okay if we don't check that the point is in the main subgroup nor multiply by 8 to clear the cofactor. This is because, for Janus protection, we either rederive the ephemeral private key and check that the ephemeral pubkey is constructed correctly, or check an HMAC of the ephemeral pubkey as the message, authenticated with the private key. This sho<clipped messag

<j​effro256:monero.social> uld indirectly protect against non-prime subgroup attacks

<j​effro256:monero.social> *private view key

jeffro256: It might be fine, but the history of the existing mul8 is worth considering. Afaik the bit-leaking attack I linked wasn't actually known by the original cryptonote devs. It appears they added the mul8 for cryptographic robustness and as a matter of best practice, and I only discovered the attack after years of pondering wtf the mul8 is actually needed for.

<j​effro256:monero.social> That's a very good point. You can probably tell that I really want the mul8 gone lol

Yeah it's not ideal, but at least it doesn't have a massive impact on perf.

Can anyone comment on this? reddit.com/r/Monero/comments/1f3xhf…s_a_slightly_tweaked_version_of_the

<a​aron:cypherstack.com> The two formulations are equivalent for security purposes

<a​aron:cypherstack.com> FWIW I've seen both in use, so I don't think that seeing one instead of the other is particularly notable. That being said, glad to have sharp eyes keeping an eye on that sort of thing!

<k​ayabanerve:matrix.org> Not only is there no difference, the original formulation I've heard of Claus Schnorr's work was (e, s) where s = r - cx, not s = r + cx. r + cx was more modern works such as EdDSA AFAIK.