Ilari Liusvaara <ilari.liusvaara@elisanet.fi>

I thought to review the properites of the proposed schemes from few PoVs: - Protocol usage (how the scheme behaves as seen from outside) - Coding (mainly "annoying" operations, e.g. inversion/sqrt mod order, random numbers, nonstandard hash APIs, non- baseline hashes or operations that seem really complex) - If it would work with non-NPOT (even if non-NPOT Edwards curves are extremely rare) or E-521 curves with baseline hashes (max. 512 bits per shot). - Extras like personalization, firewalling and batchability. - Apparent starting scheme. I might have missed some (for hashes, I assumed efficient non- aligned processing, which good implementations of hashes seem to do, and those that aren't good are slow anyway). Obviously, YMMV on what properties are important and what are not (e.g. working on curves beyond design with standard hashes is probably not very important)... Proposal by Watson Ladd: ------------------------ Online-only scheme. Has two online pipes, and needs the private key to start the online pipe. Has logically one hash function. Does not use inversions nor square roots mod order. No random numbers outside keygen&batching. Works with standard hash APIs. Non-NPOT safety unknown, does not extend to E-521 with baseline hashes. Neither personalization nor firewalling is supported. Is batchable. Derived from Schnorr scheme. Proposal by Ilari Liusvaara: ---------------------------- Online/Offline scheme, dictated by the signer. Has one online pipe, which is a raw hash. No information needed to start online pipe. Has logically two hash functions. Does not use inversions nor square roots mod order. No random numbers outside keygen&batching, Works with standard hash APIs. Non-NPOT safe, does not extend to E-521 with baseline hashes. Personalization and firewalling supported, with arbitrary-length inputs. Is batchable. Derived from EdDSA. Proposal by Dan Brown: ---------------------- Online-only scheme. Has two online pipes, and needs the private key to start the online pipe. Has logically one hash function. Has inversions mod order. Works with standard hash APIs. Specifies blinding which in places some of which would need random numbers. Non-NPOT safety unknown, unknown if extends to E-521 with baseline hashes. Neither personalization nor firewalling is supported. Is batchable. Derived from ECDSA scheme (to me, it essentially seems like deterministic ECDSA or something extremely close). Proposal by Daniel J. Bernstein, Simon Josefsson, Tanja Lange, Peter Schwabe and Bo-Yin Yang: --------------------------------------------------------------------------------------------- Online/Offline scheme, dictated by the key. Has one online pipe, which is a raw hash. The inner hash specification from key is needed to start online pipe. Has logically two hash functions. Does not use inversions nor square roots mod order. No random numbers outside keygen&batching. Hash extension does not seem to work with standard APIs (and anything larger than Curve25519 will use that extension). The specified basepoint for 448-bit curve does not look to be Curve448-compatible[1]. Non-NPOT safe, extends to E-521 with baseline hashes. Neither personalization nor firewalling is supported. Is batchable. Derived from EdDSA scheme. Proposal by Mike Hamburg: -------------------------- Online/Offline scheme, dictated by the signer. Has one online pipe, which is a raw hash. No information needed to start online pipe. Has logically two hash functions. Does not use inversions nor square roots mod order. No random numbers outside keygen. Works with standard hash APIs. Not Non-NPOT safe, does not extend to E-521 with baseline hashes. Personalization and firewalling share common fixed-length 64-bit field. Is not batchable. Derived from Schnorr scheme. [1] AFAICT, the Curve448-compatible basepoint is: y= 693F46716EB6BC248876203756C9C7624BEA73736CA3984087789C1E05A0C2D73AD3FF1CE67C39C4FDBD132C4ED7C8AD9808795BF230FA14 x either valid value, as there (y/x)^2=5 mod p. Sidenote: Why in cfrg-curves draft the isogeny is specified as (x/y)^2, given that: (1,0)+(1,0) = (0,-1) (1,0) transforms to infinity (0,-1) transforms to 0M. infinity+infinity = infinity != 0M Whereas (y/x)^2 transforms those as: (1,0)+(1,0) = (0,-1) (1,0) transforms to 0M. (0,-1) transforms to infinity 0M+0M=infinity. (My prototype ECC lib also uses (y/x)^2, and has fair bit of testing with Edwards/Montgomery consistency.) -Ilari