We have an RFC now for Curve25519 and it behooves us to start looking at
it and what it means to HIP. I definitely need to look at it for DEX as
I don't have to wait for Ed25519 which is moving along as well.
I believe an important part that impacts HIP in RFC 7748 is:
Designers using these curves should be aware that for each public
key, there are several publicly computable public keys that are
equivalent to it, i.e., they produce the same shared secrets. Thus
using a public key as an identifier and knowledge of a shared secret
as proof of ownership (without including the public keys in the key
derivation) might lead to subtle vulnerabilities.
Ouch! That is us, I believe.
So this points to KEYMAT changes. If you look elsewhere in 7748 you see
in 6.1:
Both now share K = X25519(a, X25519(b, 9)) = X25519(b, X25519(a, 9))
as a shared secret. Both MAY check, without leaking extra
information about the value of K, whether K is the all-zero value and
abort if so (see below). Alice and Bob can then use a key-derivation
function that includes K, K_A, and K_B to derive a symmetric key.
So this is a bit different requirement for KEYMAT. Again, it definitely
impacts DEX, but also BEX. I believe.
One item not mentioned that is very important in DEX is ephemeral vs
static key usage. What concerns are there with static key usage?
Any comments on working to include this curve work? Also be on the
watch for BLAKE2 as the hash to use over SHA256.
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
