From asanso at adobe.com Fri Feb 22 05:38:52 2019 From: asanso at adobe.com (Antonio Sanso) Date: Fri, 22 Feb 2019 13:38:52 +0000 Subject: [curves] Verifiable Delay Functions from Supersingular Isogenies and Pairings Message-ID: Hi *, We recently published a paper that might be interesting for this audience: https://eprint.iacr.org/2019/166.pdf Any comment is more than welcome 😊 Regards antonio -------------- next part -------------- An HTML attachment was scrubbed... URL: From conradoplg at gmail.com Wed May 22 11:13:16 2019 From: conradoplg at gmail.com (=?UTF-8?B?Q29ucmFkbyBQLiBMLiBHb3V2w6ph?=) Date: Wed, 22 May 2019 15:13:16 -0300 Subject: [curves] Finalizing XEdDSA In-Reply-To: References: Message-ID: On Mon, Oct 31, 2016 at 7:12 PM Trevor Perrin wrote: > > https://whispersystems.org/docs/specifications/xeddsa/ > > Thanks for feedback everyone, > > I plan to make the following tweaks, then freeze the design (at least > for 25519): > (...) > > (2) Replace hash_i(a || ... || Z) with hash_i(a || Z || pad || ...) > for reasons here [2] - mainly a bit more sidechannel resistance, and > slightly cleaner use of the hash. > Sorry for resurrecting this, but I've been studying this issue and I'm wondering: is there any reason why this was not incorporated into the specification? It still uses hash_i(a || ... || Z). In this paper https://eprint.iacr.org/2017/985.pdf it is explicitly mentioned that XEdDSA is vulnerable for this reason. Best regards, Conrado From burdges at gnunet.org Sat Jun 22 15:25:29 2019 From: burdges at gnunet.org (Jeff Burdges) Date: Sun, 23 Jun 2019 00:25:29 +0200 Subject: [curves] Schnorrkel Message-ID: <39066F0C-A335-47E7-B48A-80F5BFE3677E@gnunet.org> At some point last fall I started playing around with an ed25519-dalek fork, and it kinda snowballed.. We now have a crate that implements an NSEC5 style VRF and 3-round trip Schnorr multi-signatures, using Ristretto for the group and recommending merlin (STROBE) for hashing: https://github.com/w3f/schnorrkel/ https://github.com/w3f/schnorrkel/blob/master/src/vrf.rs https://github.com/w3f/schnorrkel/blob/master/src/musig.rs It attempts to strike a reasonable balance between missuse resistance and flexibility, so we expose the DLEQ proofs underlying the VRF, but address malleability aggressively to support “HDKD", and session type are used for multi-signatures. We expect to add a 2-round trip multi-signature akin to mBCJ eventually, but adapted for more realistic use cases than the published mBCJ. I’d love to get feedback either in the mailing list or in the issues https://github.com/w3f/schnorrkel/issues where some interesting discussion topics remain open. There is nothing here that really requires Ristretto of course, but it’s good to have the basics handy in Ristretto, since no map from Ristretto to Ed25519 will be standardised. And merlin makes everything far more readable. And the only bit twiddling is to support batch verification of both schnorrkel and ed25519 signatures without knowing which is which in advance: https://github.com/w3f/schnorrkel/blob/master/src/sign.rs#L81 ;) Best, Jeff p.s. We’re hiring cryptography researchers: https://web3.bamboohr.com/jobs/view.php?id=29 https://web3.bamboohr.com/jobs/view.php?id=44