-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate to libsodium #9
Comments
if you went with libsodium, you could sign/encrypt using the metadat key |
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 |
Migrating to use |
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 |
sa-weet! you could probs just pop in sodium-universal in place of sodium-native for browser support, re: @aschrijver |
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 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 not sure how useful this is, but thought i'd share! |
@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: I would suggest waiting for that to be ready before pursuing key blinding schemes for Curve25519. |
@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. |
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
|
The actual migration to libsodium for 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. |
@tarcieri, what's the state of ristretto looking like these days? |
If you want to play around with a bleeding edge cryptography library you really probably shouldn't be using yet, there's this: |
thx! seems like https://github.com/dalek-cryptography/curve25519-dalek is coming along too! |
Yeah dalek is in great shape if you're looking for a Rust library |
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? |
People suggest we use ECC keys instaed of 2048-bit (or 4096) RSA, which can be generated with libsodium
The text was updated successfully, but these errors were encountered: