Migrate to libsodium

[jayrbolton]

People suggest we use ECC keys instaed of 2048-bit (or 4096) RSA, which can be generated with libsodium

• is it too slow?
• using openpgp.js has been handy; what do we lose by managing asymmetric keypairs without the OpenPGP stuff?

[lukeburns]

if you went with libsodium, you could sign/encrypt using the metadat key

[jayrbolton]

Yeah that's definitely on the todo list! I may even dig into it today. It may be good to make the switch earlier on, rather than down the line

[jayrbolton]

Migrating to use sodium-native in this branch: https://github.com/jayrbolton/dat-pki/tree/migrate-to-libsodium. Got setup and load functions going

[aschrijver]

Are you aware that you may be diverging from dat / hypercore approach when using libsodium? I believe the project is in the process of adopting sodium-universal which is under development. To be sure you should probably ask @mafintosh

[lukeburns]

sa-weet! you could probs just pop in sodium-universal in place of sodium-native for browser support, re: @aschrijver

[lukeburns]

this is probably the right time and place to share a fantasy of mine: of deterministically deriving relationship keys.

the idea: a peer would be able to create a pair of private read/write dats for direct communication with another peer without needing to establish communication first.

the math: alice and bob with public keys A and B and secret keys a and b compute a shared secret s via Diffie-Hellman, then compute new public keys s*A and s*B, which are known only to A and B and for which only A and B can compute the corresponding secret keys, s*a and s*b, respectively.

how it could be done: there is technical trickery with hashing and "clamping" (https://moderncrypto.org/mail-archive/curves/2017/000858.html) that happens to secret keys prior to signing / encryption, so it would require PRs to libsodium and hypercore to allow for signing / encryption with the "extended" (hashed and clamped) private key. i know of two ed25519 key derivation proposals that require the same functionality, bip32-ed25519 from folks at evernym.com (@khovratovich) and chainkd from folks at chain.com (@tarcieri).

this scheme i described above pretty much just removes the need for a handshake, but you could also come up with other derivation schemes. e.g. you could name dats: say my metadat key is A and i want to publish a dat entitled 'cats'. i could create a new dat with public key hash('cats')*A. then i just need to tell people who know my key that i published a dat entitled 'cats' and they could find the dat.

not sure how useful this is, but thought i'd share!

[tarcieri]

@lukeburns one of the things we were trying to do with the CFRG was define a standard scheme everyone can use, rather than the current state of bespoke schemes.

That said, "clamping", which is due in part to Curve25519 having a cofactor of 8, became a complicating issue in the specification of such schemes. For that reason I've been sort of holding out on actually pursuing such a scheme in hopes that there will be a standard way to eliminate cofactors when using Curve25519 in general.

There's some nascent work on that here:

https://github.com/ristretto

I would suggest waiting for that to be ready before pursuing key blinding schemes for Curve25519.

[lukeburns]

@tarcieri the schemes that i'm imagining here aren't blinding schemes. they're pretty simple, specific to this context, and i don't imagine they'd be standardized. i'd just need to be able to work with the same primitives as in more complicated schemes (i.e. the extended secret key). good to hear that standardization work is happening though.

are there other approaches for dealing with the cofactor than bernstein's bit-twiddling or the approach described in https://moderncrypto.org/mail-archive/curves/2017/000866.html? in the scheme i described above, the torsion-safe rep would be our only option, because bit-twiddling would affect the corresponding public-key.

[tarcieri]

Ristretto will provide prime order groups which can reuse both Ed25519 curve arithmetic and public keys. In the case of something like an extended public key, it also provides its own wire format which is free of cofactor ambiguities.

It's an adaptation of Decaf to Curve25519 (Decaf is for Ed448):

https://eprint.iacr.org/2015/673 -- Tony Arcieri

[jayrbolton]

The actual migration to libsodium for dat-pki is done using sodium-universal, so I'm closing this issue.

I do love the idea that you brought up @lukeburns, using Diffie Hellman to compute shared secret keys for the relationship dats. In the mean time, we can just keep plugging away at the handshake system and then replace it in the future if we figure out something better.

[lukeburns]

@tarcieri, what's the state of ristretto looking like these days?

[tarcieri]

If you want to play around with a bleeding edge cryptography library you really probably shouldn't be using yet, there's this:

https://github.com/Ristretto/libristretto255

[lukeburns]

thx! seems like https://github.com/dalek-cryptography/curve25519-dalek is coming along too!

[tarcieri]

Yeah dalek is in great shape if you're looking for a Rust library

[lukeburns]

Ended up playing around a bit with curve25519-dalek, since @yoshuawuyts rust implementation of hypercore is chugging along.

@jayrbolton, here's a proof of concept for the key derivation scheme i mentioned above https://github.com/lukeburns/channels, which could feasibly be used for private push messaging under some fairly reasonable network conditions (e.g. peers listen for private channels every time they encounter a new peer). it could also use this for private groups or public subfeeds (e.g. a cats feed associated with my public identity feed).

that said, i'm working on a fork of hypercore that replaces the crypto system entirely. am I right in thinking that signature schemes in ristretto cannot be made to be compatible with ed25519 signatures, @tarcieri?