Hi Colin

> In case the server goes rogue and starts refusing to sign, the user can use 
> their userRecoveryPrivKey to send the funds anywhere they choose. Because if 
> this, the userRecoveryPrivKey is best suited to cold wallet storage.

Would you then assume that userWalletPubKey is a hot key (stored on the users 
computer eventually in a browser based local storage container)?
In case of an attack on the server responsible for serverWalletPubKey (where 
also the personal information of the user are stored [including the xpub == 
amount of funds hold by the user)), wound’t this increase the users risk of 
being an possible target (False sense of multisig security, comparing to cold 
storage / HWW keys)?

> In the more likely event that the user forgets their password and/or looses 
> access to their userWalletPrivKey as well as loses their recovery key, they 
> rely on the serverRecoveryPrivKey.
> When the user first sets up their wallet, they answer some basic identity 
> information, set up a recovery password, and/or set up recovery questions and 
> answers. This information is explicitly NOT sent to serve with the exception 
> of recovery questions (although the answers remain with the user, never 
> seeing the server). What is sent to the server is it's 256 bit hash used to 
> identify the recovery wallet. The server then creates a 1025 bit nonce, 
> encrypts it, stores it, and transmits it to the user's client.

I guess this will result in protecting the funds stored in this transaction 
entirely on the users identity information and eventually the optional recovery 
password, though I guess you are adding additional security by protecting via 
the server nonce from brute-forcing.

Why 1025bit for the nonce?
Why SHA512 instead of SHA256 (I guess you need 256bit symmetric key material 
for the key encryption)?
Considered using a (H)KDF for deriving the symmetric key (even if the server 
based nonce reduces the possibility of brute-forcing)?

Your modal has probably the TORS (trust on recovery setup) weakness (compared 
to a HWW where you [should] be protected on compromised systems during private 
key creation).


Attachment: signature.asc
Description: Message signed with OpenPGP

bitcoin-dev mailing list

Reply via email to