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). </jonas>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
