Security Consideration for Deterministic Keygen

[0xc0de4c0ffee]

Our current deterministic keygen is simple HKDF design easy to explain and implement.

In worst case of deterministic keys or signature leakage we don't have good enough plans so it'll open up for bruteforce attacks on password after key/signature leak from users signing ditto requests on bad clients.. actual ownership of domain is never compromised as resolver doesn't handle domain ownership, as last line of defense users can eject resolver and/or change ownership of their domain to gain full control of everything again.

Condition Red:

1. key leak : if deterministic keys are leaked it's not that bad as owners can change password/ and reset their signer/IPNS keys.
2. signature leak : if deterministic signature is leaked, it allows attackers to bruteforce password and prevent owner.

quick fix A OR B:
A) simple : hashing password with user data and add that hash in signature request, it'll close that bruteforce surface.
let statement = Requesting signature for IPNS key generation\n\nUsername: ${ens}\nExtradata: ${<keccak256(ens, password?password:"", caip10)>}\nSigned By: ${caip10}, better to make password non-optional in this case and use that to encrypt deterministic ipns/signer keys stored on client.

B) hard : next level after HKDF is PBKDF or Scrypt like.. better we don't complicate for now, but for our CAIP we can let App-specific sides select their own algo to generate hashkey before plugging that to hash-to-privkey function.

Extra security : clients should handle keys more seriously, delete keys after use or encrypt keys with password if it's saved on client side after use. Possibly use MM/wallet's encrypt/decrypt features, some wallets don't support.. we can always generate extra secp256k1 signer key for records on client side to pair with IPNS keys instead of bugging wallet for multiple signature requests for records signing.

[sshmatrix]

Here is a walk-through (total Signatures + Transactions) of how things work on the client:

1. User signs S1 to generate IPNS keys for the first time and initiates transaction T1 to migrate Resolver and T2 to set the S1-generated IPNS as the contenthash

• T1 + T2 in one transaction possible? fastSetup()?

2. When setting records, user signs

• S2 to re-generate IPNS, and
• S3 to attach separate signature with the records. We don't use the same signatures from S2 because exposing S2 risks security as you pointed out.

Note:

• We don't store private keys anywhere, not even in localStorage. Keys are generated upon Sn and purged from the core React state once the process completes.

• We only generate ed25519 keys for IPNS key generation and the signatures are always made by the Ethereum keys, i.e. there is no secondary secp256k1 keygen. Do we need it?

There are basically,

• 2 signatures for each record update,
• 2 signatures (since 1 is re-usable) and 2 (possibly 1) transactions for the initial setup + record update

Thinking out loud:

I guess if we generate another secp256k1 key from same hashkey, then we don't need to get the user to sign twice and only once will be sufficient. What about verification of such a signature? It will resolve to a different public key, which the contract needs to store and handle. Isn't this extra trouble?

[sshmatrix]

I see. We are storing the manager key in the contract. It makes name management easier but adds some gas to T2. Sounds fine to me. There are too many approved and approvedForAll

[0xc0de4c0ffee]

T1 is to switch resolver on ENS/?wrapper contract,
T2 to add contenthash on resolver contract,
T3 if owners want to approve/manager to sign-offchain records,

"Fast setup" is to set both contenthash and manager keys in same T2 tx on-chain.
K1 is still valid signer if there's no K2/manager keys.

[sshmatrix]

I have pushed both versions to git on separate branches; for now, let's continue with the one with less signatures and on-chain manager. We have the code if/when required to change signers

[sshmatrix]

K1 is still valid signer if there's no K2/manager keys.

Does it mean that K2/Manager keys are optional feature? If yes, then we should implement it as an option in the client. It is a difference of paying $14 for initial setup vs. paying $20, which is significant. I can trigger a modal which explains this extra step in 2-3 lines and asks the user whether they would like to set manager keys. Those who want can do it for ease of access. What do you think? In the end, it is a trade-off between one time fees vs. more manual signatures at each update.

[0xc0de4c0ffee]

1. resolver setup costs ~35k gas
2. contenthash setup is ~75k gas
3. set approval/extra signer is ~45k gas

"multicall" mixing 2+ 3, gas cost is ~95k.

3 is optional one time setup as secondary/helper keys,
it's secondary feature key set there for future to do crypto stuffs that we can't directly do with K1/wallet keys for security reasons.
e,g, ECDH/ shared secret, TSS/MPC, or handling basic stealth pay that require ecmul hash with privkeys, we cant do that in MM/wallets keys... as it's secp256k1 we can reuse K2 for nostr.json pubkeys.

** with IPNS+secp256k1 support we can use same K2 for both IPNS and records manager, and extend same for future features.