search

ssbc / ssb-keys

keyfile operations for ssb
36 stars 26 forks source link

tracking PR: add nacl crypto #14

Closed dominictarr closed 9 years ago

dominictarr commented 9 years ago

This adds ed25519 via nacl. It's at least twice as fast as k256 from sjcl, and doesn't have side-channel leaks...

Side channels (when you gain information about the key by examining, eg, how other software runs on the same computer... is probably a big risk in JS crypto, because it would be pretty easy to get more js running on the same computer...)

Also, this makes https://github.com/ssbc/scuttlebot/pull/192 take only 5 seconds!!!

Another benefit is that the ed25519 public key is only 32 bytes long (same size as a blake2s hash) so we can just put it in every message instead of looking up, which could make the validation algorithm simpler too!

dominictarr commented 9 years ago

Also, this looks like it should be backwards compatible, since it works alongside the old k256 signatures.

pfrazee commented 9 years ago

ecma-nacl worries me, the user and repo are nobodies

I prefer we use libsodium via node bindings, and consider pure-js versions later (https://download.libsodium.org/doc/bindings_for_other_languages/index.html)

dominictarr commented 9 years ago

Oh hey! look this emscripten port of libsodium is faster than ecma-nacl... https://github.com/jedisct1/libsodium.js

And it's the same api as https://github.com/paixaop/node-sodium which installed correctly, and is actively maintained ;)

pfrazee commented 9 years ago

soo I guess Im ok with the emscripten port since it is api-compatible with original libsodium

dominictarr commented 9 years ago

it's literally the same code, because it is compiled from it.

dominictarr commented 9 years ago

okay now it is using libsodium-wrappers. I tried to use sodium... but it's actually causing an 'out of order' error in secure-scuttlebutt/validation.js maybe it's some sort of race because it's too fast? more investigation to do here...

dominictarr commented 9 years ago

improved test coverage, and made sure everything is backwards compatible. But we should wait until I figure out what is breaking validation before we merge this.

pfrazee commented 9 years ago

Looking good so far!

So we're going to be changing curves -- is ssb going to continue supporting k256? If so, what'll the differences be for users of one vs the other? If not, maybe we should ditch legacy entirely.

it's literally the same code, because it is compiled from it.

I don't totally agree. It's close, but the runtime is different, and I think that invites subtle differences which could cause bugs. But having API compat with libsodium gives us a quick escape hatch if the purejs version has a problem ("quick, to the native bindings!") so Im ok with not worrying, for now.

dominictarr commented 9 years ago

ha! so it wasn't a race condition (thank god) it was just that now the crypto is so fast that it can sign two messages within the same millisecond, and timestamps must be monotonically increasing... making a pr to fix this in ssb-feed

pfrazee commented 9 years ago

nice!!

dominictarr commented 9 years ago

okay this is ready to merge :+1: ?

dominictarr commented 9 years ago

added seeded keys, which are needed to mint one time capabilities.