[curves] pure-python Ed25519 library for review
paul at marvell.com
Tue Apr 7 13:47:09 PDT 2015
On 4/7/15, 12:42 PM, "Brian Warner" <warner at lothar.com> wrote:
>On 4/7/15 12:05 PM, Gregory Maxwell wrote:
>> I applaud you for seeking public review; but doesn't your remark above
>> mean that many people will use it, because its easy, even if their
>> actual (and perhaps not completely known to them) security
>> requirements demand that it not have timining sidechannels (or memory
>Yeah, that's totally fair. I'm torn on this point. I feel there are
>plenty of applications in which a non-constant-time implementation is
>safe to use, and the alternative (requiring C code) means those
>applications just won't get written or deployed.
Yes - very valuable Š even as a reference implementation for test vectors.
Thanks much for posting!
> For example:
>* the PAKE-based file-transfer application I built this for
> (https://github.com/warner/magic-wormhole), where each "password" is
> used once, and a human must transcribe the password
>* https://github.com/warner/git-lockup , which creates and verifies
> Ed25519 signatures on git commits. The signatures are created locally
> (in a post-commit hook), which the network adversary doesn't get to
> see, and the verifier doesn't have any secrets anyways.
>In both applications, requiring users to install a C module requires a
>compiler (especially troublesome on windows), or for us to host
>pre-compiled binaries (for which we'd really want verifiable /
>reproducible builds). The git-lockup application is particularly
>sensitive to deployment barriers: thanks to the current pure-python
>form, a downstream user of a suitably-published git repo can completely
>protect themselves against subsequent (TOFU) unauthorized commits by
> git clone XYZ
> cd XYZ
>which installs a hook that verifies the Ed25519 signatures during 'git
>fetch'. That setup command doesn't fetch any external code, doesn't
>compile anything, and doesn't need to include binaries for every
>conceivable platform in the source tree.
>> (Especially that seems odd when also talking about SPAKE2, ... a
>> complex zero knowledge password based key agreement having a timing
>> leak that might even be visible on the network would be really
>To be honest, I'm not so worried about SPAKE2, because it's (again,
>generally) deployed in a mode where a human has to input something for
>each execution of the protocol. So it's naturally rate-limited by the
>user's patience, preventing the timing-measuring attacker from getting a
>significant number of samples.
>I'd be more concerned about something like an automated Ed25519
>certificate signer, where the attacker gets non-human-mediated access to
>a signing oracle. Or an encrypted-message autoresponder that's using
>Curve25519, so you can ping it a million times to accumulate the timing
>The big problem with these cautionary footnotes in crypto-libraries is
>that they increase the chances someone will use them "off-label". Too
>many such footnotes makes it almost impossible to use safely. But
>sometimes I think aiming for no footnotes is a limitation too. "The
>perfect is the enemy of the good" and all (which of course goes against
>our instincts as security folks).
>I guess I want to be able to use this library for my own projects, where
>I think I can correctly evaluate the consequences of the caveats, and
>steer everyone else (or everyone I think won't evaluate them correctly)
>towards pynacl and other libsodium-based C bindings. FWIW, I'm not
>publishing this to PyPI. But maybe I should add code to make the library
>delete itself if it gets run with the wrong userid? :).
>Curves mailing list
>Curves at moderncrypto.org
More information about the Curves