On 4/7/15, 12:42 PM, "Brian Warner" <[email protected]> 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 >> leaks)? > >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! Paul > 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 >just doing: > > git clone XYZ > cd XYZ > ./setup-lockup > >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 >> unfortunate.) > >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 >data. > > >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? :). > >thanks, > -Brian >_______________________________________________ >Curves mailing list >[email protected] >https://moderncrypto.org/mailman/listinfo/curves _______________________________________________ Curves mailing list [email protected] https://moderncrypto.org/mailman/listinfo/curves
