Subtleties with ed25519 and x25519

[joe-p]

Currently the owner address is used for the verification method and key agreement:

	pubkey, err := AlgorandAddressToEd25519(ownerAddr)
			if err == nil {
				x25519Key, err := Ed25519ToX25519(pubkey)
				if err == nil {
					keyAgreements = append(keyAgreements, VerificationMethod{
						ID:                 didID + "#x25519-owner",
						Type:               KeyTypeX25519,
						Controller:         didID,
						PublicKeyMultibase: X25519ToMultibase(x25519Key),
					})
				}
			}

This can be problematic for rekeyed accounts because the the owner address may be rekeyed. This means either

A) The owner no longer has the respective private key
or
B) A malicious actor that now has the original private key can incorrectly verify themselves as the DID owner

I think the resolver should instead use algod to get the AuthAddr for ownerAddr and use that for verification methods.

Additionally an Algorand address may not correspond to a valid x25519 key if the Address comes from a soft-derived HD account since the private scalar is not properly clamped according to the standard. They may still be able to do a DH exchange with that unclamped scalar, but it will not be following the x25519 standard and compatibility with external libs may be a mixed bag.

There's also the problem of knowing whether an address is an app or lsig but this is less of a problem since no one will have the corresponding private key.

Honestly I would say if someone wants key exchange methods on their DID that should be a custom field not associated with the address due to the above complexities. At the very least, however, I would recommend using the AuthAddr

[th0tmaker]

Don't use ed25519 and x25519 keys interchangeably (or derive one from the other), they are not same the same curve representation (one is edwards, the other is montgomery) and are optimized for different applications. There are some crypto libs out there that provide methods that let you derive one from the other, but they usually document the risk associaated in doing so, and highlight that it should be basically be done under specific, constrained scenarios, and if it's possible, you should avoid it.

I think DIDComm uses an optional filed for key exchange agreements. Basically, the user decides if they want the feature or not. If they do, they generate a long-lived x25519 keypair, and pin the public key to the DID data, then store the corresponding private key somewhere safe, which they then get to use to decrypt the incoming encrypted messages. Because long-lived keys sacrifice forward secrecy (if key is compromised at any point ,the attacker can decrypt past secrets), it's often suggested the owner should 'rotate' keys, basically swap the existing keypair with a fresh one every once in a while, though, i don't know how feasible that if the public key is part of on-chain data, then you'd have to make updates to that data as well in this case... The secret sender doesn't need to have a long-lived key to encrypt and send the secret. They can generate an ephemeral x25519 keypair in their case, send the secret, then discard it. This ensures forward secrecy on their part.

For the whole key agreement exchange protocol you'll also probably need HKDF and AEAD cipher. The Diffie-Hellman only computes the secret scalar (32 bytes), but you need HKDF to compress and expand that into safe key format. An AEAD cipher will add additional safety to ciphertext. It allows you to bind the ciphertext to some additional context data that must match and can also detect the ciphertext has been tempered with and allows you to bind the ciphertext. Maybe some nonce/timstamp to prevent reuse.