Consider the use of other cryptogaphic primitives (ed25519 for example)

[mildred]

It would be nice if we had the choice of which cryptography primitive we use for objects. Specifically, I would prefer using ed25519 which is an elliptic curve algorithm that was not approved by NIST. But its security is equivalent to ~3000-bit RSA while having much shorter keys and being way faster.

It would also be a great feature when we'll have to upgrade to stronger primitives in the future.

[jbenet]

Yep, we're certainly building with this modularity in mind.—
Sent from Mailbox

On Mon, Sep 8, 2014 at 11:43 PM, mildred [email protected] wrote:

It would be nice if we had the choice of which cryptography primitive we use for objects. Specifically, I would prefer using ed25519 which is an elliptic curve algorithm that was not approved by NIST. But its security is equivalent to ~3000-bit RSA while having much shorter keys and being way faster.

It would also be a great feature when we'll have to upgrade to stronger primitives in the future.

Reply to this email directly or view it on GitHub:
https://github.com/jbenet/ipfs/issues/29

[np]

I'm also in favor of elliptic curve crypto. Not only keys are shorter but they are also simpler (not a pair of primes), RSA turned out to be pretty vulnerable to the slightest issue in the PRNG.

While getting this through modularity would be one option. Modularity on the choice of crypto primitives is also a slippery slope. What do you guys think of NaCl?

[jbenet]

@np +1 for NaCl and we have an outstanding PR for ECC in go-ipfs that will go in with keystore -- we'll be refining the keystore spec this week, and hopefully implement it soon: https://github.com/ipfs/specs/tree/master/keystore (note that spec is WIP)

(also one problem with NaCl in go-ipfs is that we've so far been able to keep c libs out, so that it's only Go. this can change but ideally not. i think in the long run we may split off all the crypto operations (enc/dec sig/ver) into a separate module that go-ipfs can either embed or run as a separate binary, depending on the use case. (one of the reasons for putting it as a separate binary is that it may make it so we do not have to hand the large go-ipfs binary the private keys, only to the smaller more auditable binary. but not sure yet if this is worth the effort soon)

[cryptix]

@jbenet: i just used nacl box from golang.org/x/crypto to solve the golangchallenge 2. Afaict it's pure go.

IMHO it would be a nice candidate to replace our current secpipe implementation.

[jbenet]

@cryptix oh agl implemented nacl in go? i ❤️ that man.

[jbenet]

@cryptix yes im down. also, dont recall how box does things exactly, but i'd love to be able to learn what we can from QUIC's "zero handshake" encryption scheme. it's super nice for speed.

one other constraint to consider is what happens when keys differ. from my point of view it should be fine as long as we accpet them. (i.e. you can do secret sharing by treating these as 2 separate one-direction encryptions instead of a 2-party handshake). i.e. soemthing like:

// each side does (much abbreviated, just a sketch!!)

insecure.Read(remotePK)
secret := randomNonce()
secret_enc := remotePK.Encrypt(secret)
insecure.Write(secret_enc)

cipher := initialize symmetric cipher using secret
secure := cipher.Wrap(insecure)

so each side ends with different one-direction secrets. not sure but this may be what QUIC does.

(disclaimer: no idea if the above actually works or is broken i have to think about it more)

[cryptix]

I read a little into QUIC Crypto and I have some concern about it's use in a p2p setting because of how it wants to achieve relay protection using client send nonces.

Replay protection

...

Since the server cannot introduce an nonce into the handshake without a round trip, the client must give a unique ID to every connection and the server must ensure that it never processes the same connection twice. The client's nonce serves as a suitable ID.

The requirement that the server never process the same connection twice is troublesome because it suggests that all the servers, worldwide, which serve a given domain, need to access a consistent, eternal register of previous client nonces. However, we can significantly relax that requirement by partitioning the state and by requiring clock sync.

We can partition the state by having the server ensure not that the client nonce is unique, but rather that the nonce is unique within a given “orbit”. An orbit partitions the nonce space and identifies a set of servers which manage a shared register of previously observed client nonces.

IIUC It sounds like this is designed for a classical server<->client relation where you can (geographically) restrict/re-route connections to a certain group of servers. Which to me feels like a pretty weird restriction for a p2p network. I'm sure there are different ways to achieve this but I guess it won't be vanilla QUIC then.

[jbenet]

@cryptix

I think that requirement is actually fine. What it's saying is this: (a) in TLS, replay protection happens via a random nonce from each side used in key derivation. this adds an extra round trip. (b) QUIC avoids the roundtrip by letting the client pick it and just making sure any connection recipient (server in their terminology) doesn't process the same connection origin (client) nonce twice. (c) when it is desired that multiple servers appear as one (serving a single domain) those must make sure

In the p2p setting, each peer can be either recipient ("server") or originator ("client") (really, dialer or listener), and if we don't need more than one peer to appear as a single host for domain purposes (in most cases we don't, p2p usually means each peer is its own identity), then it's perfect! We can ignore (c). We can just worry about the set of nonces we receive directly.

It's not clear from that doc (maybe it's elsewhere) whether the client nonces need to be kept in perpetuity (see below). (the doc speaks as if this is the case). That seems like a brittle requirement, as it suggests an attack where attackers instantiate millions of new connections causing the target to store millions of nonces. I'll ask the QUIC list.

Update: i had missed this:

The second way by which we can make the server's job easier is by requiring clock sync between the server and the client. If we mirror TLS's method of including a timestamp in the nonce then servers need only maintain state for a limited amount of time. Without this, servers would have to maintain the strike-register indefinitely.

It's still a viable attack, even though it has a time limit.

[Stebalien]

We now have support for ed25519 and friends.

[daviddias]

@Stebalien fully? Even for dialing?

[Stebalien]

The only thing remaining is enabling creating ed25519 keys: ipfs/kubo#3625.