ECID Elliptic curve based CID

[klondike]

ECID's propossal text is currently defined in http://www.dcbase.org/wiki/ECID I'm opening this thread for discussion before I try to get it approved as an official extension.

So, any question/complain?

[Ayo]

Some notes:

Clients supporting ECID will have aside from the normal hash based PID/CID set a PID corresponding to a valid curve25519 private key and a CID corresponding to the public curve25519 key matching this PID

Aside? Or instead? The proposal suggests that the curve-based keys replace the old hash-based PID/CID values on a supported hub. Does this "aside" refer to the fact that a client still needs to maintain the hash-based PID/CID values for non-supporting hubs, or is it envisioned that a client will have two CIDs on a single hub?

INF parameter adition [..] ECH

Parameters must be two characters.

HMAC_k is the result of the HMAC function with the session hash algorithm with the key number x from the key derivation table

I don't get this one. What, exactly, is the key derivation table? I don't currently see how the extension provides any added security, and I suspect it has to do with me not understanding this part.


I inferred that the goal of this extension is to provide both:
- Reliable identities (i.e. CIDs that can be verified and can't be stolen)
- Authenticated connections

As for the latter, what advantage does it have over KEYP? Besides that it also works for non-TLS connections; but we can just force TLS, can't we? Since every TLS-supporting client (i.e. every client) already has its own TLS key pair, wouldn't it be easier to just make the CID a hash of the public key? That, too, will allow clients and hubs to verify that the client is the true owner of the CID. Or am I missing something?

[klondike]

Clients supporting ECID will have aside from the normal hash based PID/CID set a PID corresponding to a valid curve25519 private key and a CID corresponding to the public curve25519 key matching this PID

Aside? Or instead? The proposal suggests that the curve-based keys replace the old hash-based PID/CID values on a supported hub. Does this "aside" refer to the fact that a client still needs to maintain the hash-based PID/CID values for non-supporting hubs, or is it envisioned that a client will have two CIDs on a single hub?

Yes, it refers to the fact that the old hash-based PID/CID values are still needed for non supporting hubs, at least for the team being.

INF parameter adition [..] ECH

Parameters must be two characters.

Oki, my fault I fixed that the parameter will be EC then

HMAC_k is the result of the HMAC function with the session hash algorithm with the key number x from the key derivation table

I don't get this one. What, exactly, is the key derivation table? I don't currently see how the extension provides any added security, and I suspect it has to do with me not understanding this part.

The key derivation table is a table and method used to provide per client keys to extensions, it is defined in the PIDK extension.

I inferred that the goal of this extension is to provide both:
- Reliable identities (i.e. CIDs that can be verified and can't be stolen)
- Authenticated connections

As for the latter, what advantage does it have over KEYP? Besides that it also works for non-TLS connections; but we can just force TLS, can't we? Since every TLS-supporting client (i.e. every client) already has its own TLS key pair, wouldn't it be easier to just make the CID a hash of the public key? That, too, will allow clients and hubs to verify that the client is the true owner of the CID. Or am I missing something?

Well, there are a few problems with hashing the certificate, the first coming to mind is the risk of reuse in old hubs if the hash is tiger. Also there is the problem that said hash is not the public key and can't be used for offline key derivation as this protocol allows (this feature will make more sense later when I start with SUD1).

Lastly the main advantage over KEYP is that this doesn't depends at all on the hub to distribute the authentication tokens and can be used on systems like the DHT network.

[klondike]

[2012-10-12 15:20] <cologic> klondike: well, I'm unsure what my dcbase forum login is (or if I have one) - so I won't respond in a particularly detailed manner since the forum is better for that...

1) https://bugs.php.net/bug.php?id=62924 is an example of a language [much as I dislike PHP, it is common...] which doesn't have Curve25519 support, even if there's a Java version, etc. I'm slightly wary, I guess, of anything that's not in standard crypto toolkits for this purpose, but haven't come found any terribly damning things about Curve25519 per se, so that's something.

2) The use of HMAC as the key heavy lifting step in http://www.dcbase.org/wiki/ECID is (nonsarcastically) confidence-inspiring.

5) HKDF, per RFC 5869, looks superficially reasonable, but is probably beyond my expertise to review in any way beyond observing such. I will say this is the first time I've heard of it, so I have no pre-existing biases (positive or negative) to it, sans a naturally somewhat conservative approach to security.

6) My read of http://www.dcbase.org/wiki/ECID is that a hub could fairly easily support multiple such schemes simultaneously (indeed, it will have to from the start: the current version and ECID) so I'm not hugely concerned with getting that absolutely perfect, because it's unlikely to turn into a terrible perpetual support burden so long as ADC BASE is somewhat acceptable.

7) ECID-over-non-SSL is almost more compelling than ECID-over-SSL because it cuts out a larger portion of threats (network monitoring). Just a random thought...

8) I'm unsure if the A/B order anti-symmetry in "HMAC_k3(MSK+CID_A+CID_B+ECH_A+ECH_B)" vs "M2=HMAC_k4(MSK+M1+CID_B+CID_A+ECH_B+ECH_A)" is particularly principled or whether it actually adds to security.
[2012-10-12 15:22] <cologic> http://sourceforge.net/apps/trac/cryptopp/ticket/10 doesn't support curve25519 nor does OpenSSL nor etc. So, if maintained code exists for one's preferred development environment, that's great, but it seems like it could be relatively easily 'orphaned'.
[2012-10-12 15:23] <cologic> AFAICT, that means C and Java are probably good. Anything else is iffy medium-term.
[2012-10-12 15:24] <klondike> Ok cologic will post that to the forums on your behalf then
[2012-10-12 15:24] <cologic> I'll also just admit a slightly potentially irrational phobia of being drawn into djb's orbit :p

Comments:
The curve25519 algorithm is public so implementations for other languages can be provided, also the fact there is a pure C implementation allows interfacing with many languages (including PHP).

The asymmetry is inferred from the SRP key proof and is used to prevent some replay issues.

And well djb I don't like that much either, but his algorithms tend to be pwoerful