public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

• * [bitcoin-dev] Structure for Trustless Hybrid Bitcoin Wallets Using P2SH for Recovery Options
         [not found]                                                                                                                                       ` <CAJJsNHtZWH4Cy-kpCRrbLeA339uoC3mL0Be2MBNdbW8PqjboJg@mail.gmail.com>
  @ 2017-08-09 18:49                                                                                                                                         ` Colin Lacina
    2017-08-09 19:35                                                                                                                                           ` Jonas Schnelli
    2017-08-09 20:14                                                                                                                                           ` Nick ODell
    0 siblings, 2 replies; 3+ messages in thread
  From: Colin Lacina @ 2017-08-09 18:49 UTC (permalink / raw)
    To: bitcoin-dev
  
  [-- Attachment #1: Type: text/plain, Size: 2975 bytes --]
  
  I believe I have come up with a structure that allows for trustless use of
  hybrid wallets that would allow for someone to use a hybrid wallet without
  having to trust it while still allowing for emergency recovery of funds in
  the case of a lost wallet. It would run off of this TX script:
  
  IF
       1 <clientRecoveryPubKey> <serverRecoveryPubKey> 2 CHECKMULTISIGVERIFY
  ELSE
       2 <userWalletPubKey> <serverWalletPubKey> 2 CHECKMULTISIG
  ENDIF
  
  A typical transaction using this would involve a user signing a TX with
  their userWalletPrivKey, authenticating with the server, possibly with 2FA
  using a phone or something like Authy or Google Authenticator. After
  authentication, the server signs with their serverWalletPrivKey.
  
  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.
  
  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.
  
  Meanwhile, the user's wallet client generates the serverRecoveryPrivKey.
  
  Once the client has both the serverRecoveryPrivKey, and the nonce, it uses
  SHA512 on the combination of the identity questions and answers, the
  recovery password (if used), the recovery questions and answers, and the
  nonce. It uses the resulting hash to encrypt the serverRecoveryPrivKey.
  
  Finally, the already encrypted key is encrypted again for transmission to
  the server. The server decrypts it, then rencrypts it for long term storage.
  
  When the user needs to resort to using this option, they 256 bit hash their
  information to build their recovery identifier. The server may, optionally,
  request e-mail and or SMS confirmation that user is actually attempting the
  recovery.
  
  Next, the server decrypts the saved nonce, as well as the first layer of
  encryption on the serverRecoveryPrivKey, then encrypts both for
  transmission to the user's client. Then the client removes the transmission
  encryption, calculates the 512 bit hash that was used to originally encrypt
  the serverRecoveryPrivKey by using the provided information and the nonce.
  
  After all of that the user can decrypt the airbitzServerRecoveryPrivKey and
  use it to send a transaction anywhere they choose.
  
  I was thinking this may make a good informational BIP but would like
  feedback.
  
  [-- Attachment #2: Type: text/html, Size: 4915 bytes --]
  
  ^ permalink raw reply	[flat|nested] 3+ messages in thread

• • * Re: [bitcoin-dev] Structure for Trustless Hybrid Bitcoin Wallets Using P2SH for Recovery Options
      2017-08-09 18:49                                                                                                                                         ` [bitcoin-dev] Structure for Trustless Hybrid Bitcoin Wallets Using P2SH for Recovery Options Colin Lacina
    @ 2017-08-09 19:35                                                                                                                                           ` Jonas Schnelli
      2017-08-09 20:14                                                                                                                                           ` Nick ODell
      1 sibling, 0 replies; 3+ messages in thread
    From: Jonas Schnelli @ 2017-08-09 19:35 UTC (permalink / raw)
      To: Colin Lacina, Bitcoin Protocol Discussion
    
    
    [-- Attachment #1.1: Type: text/plain, Size: 2152 bytes --]
    
    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>
    
    [-- Attachment #1.2: Type: text/html, Size: 3431 bytes --]
    
    [-- Attachment #2: Message signed with OpenPGP --]
    [-- Type: application/pgp-signature, Size: 833 bytes --]
    
    ^ permalink raw reply	[flat|nested] 3+ messages in thread

  • * Re: [bitcoin-dev] Structure for Trustless Hybrid Bitcoin Wallets Using P2SH for Recovery Options
      2017-08-09 18:49                                                                                                                                         ` [bitcoin-dev] Structure for Trustless Hybrid Bitcoin Wallets Using P2SH for Recovery Options Colin Lacina
      2017-08-09 19:35                                                                                                                                           ` Jonas Schnelli
    @ 2017-08-09 20:14                                                                                                                                           ` Nick ODell
      1 sibling, 0 replies; 3+ messages in thread
    From: Nick ODell @ 2017-08-09 20:14 UTC (permalink / raw)
      To: Colin Lacina, Bitcoin Protocol Discussion
    
    [-- Attachment #1: Type: text/plain, Size: 3957 bytes --]
    
    Colin,
    
    1) This is a good start for a BIP, but it's missing details. For example,
    the nonce is encrypted by the server. What key is it encrypted with?
    Clarifying ambiguities like this can sometimes reveal weaknesses that you
    wouldn't otherwise think of.
    
    2) What kind of recovery questions are asked? If it's something like "What
    was the name of your first pet?" then what prevents the server from
    stealing the wallet by trying a dictionary of the most common pet names? Is
    there a mitigation to this, besides picking cryptographically secure
    identifiers for my pets?
    
    --Nick
    
    On Wed, Aug 9, 2017 at 12:49 PM, Colin Lacina via bitcoin-dev <
    bitcoin-dev@lists•linuxfoundation.org> wrote:
    
    > I believe I have come up with a structure that allows for trustless use of
    > hybrid wallets that would allow for someone to use a hybrid wallet without
    > having to trust it while still allowing for emergency recovery of funds in
    > the case of a lost wallet. It would run off of this TX script:
    >
    > IF
    >      1 <clientRecoveryPubKey> <serverRecoveryPubKey> 2 CHECKMULTISIGVERIFY
    > ELSE
    >      2 <userWalletPubKey> <serverWalletPubKey> 2 CHECKMULTISIG
    > ENDIF
    >
    > A typical transaction using this would involve a user signing a TX with
    > their userWalletPrivKey, authenticating with the server, possibly with 2FA
    > using a phone or something like Authy or Google Authenticator. After
    > authentication, the server signs with their serverWalletPrivKey.
    >
    > 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.
    >
    > 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.
    >
    > Meanwhile, the user's wallet client generates the serverRecoveryPrivKey.
    >
    > Once the client has both the serverRecoveryPrivKey, and the nonce, it uses
    > SHA512 on the combination of the identity questions and answers, the
    > recovery password (if used), the recovery questions and answers, and the
    > nonce. It uses the resulting hash to encrypt the serverRecoveryPrivKey.
    >
    > Finally, the already encrypted key is encrypted again for transmission to
    > the server. The server decrypts it, then rencrypts it for long term storage.
    >
    > When the user needs to resort to using this option, they 256 bit hash
    > their information to build their recovery identifier. The server may,
    > optionally, request e-mail and or SMS confirmation that user is actually
    > attempting the recovery.
    >
    > Next, the server decrypts the saved nonce, as well as the first layer of
    > encryption on the serverRecoveryPrivKey, then encrypts both for
    > transmission to the user's client. Then the client removes the transmission
    > encryption, calculates the 512 bit hash that was used to originally encrypt
    > the serverRecoveryPrivKey by using the provided information and the nonce.
    >
    > After all of that the user can decrypt the airbitzServerRecoveryPrivKey
    > and use it to send a transaction anywhere they choose.
    >
    > I was thinking this may make a good informational BIP but would like
    > feedback.
    >
    > _______________________________________________
    > bitcoin-dev mailing list
    > bitcoin-dev@lists•linuxfoundation.org
    > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
    >
    >
    
    [-- Attachment #2: Type: text/html, Size: 6415 bytes --]
    
    ^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2017-08-09 20:14 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CAJJsNHsiAH3Wc_Fp-8f=5EBg8-jNH8rtEW5+u+PEC7JU+SdCGQ@mail.gmail.com>
     [not found] ` <CAJJsNHv_iPNnGgqqogoxGEk+5ipoELfPAnMM0obWUpTjWRZJRQ@mail.gmail.com>
     [not found]   ` <CAJJsNHvKR+ieYaFYw_KeCmJjWTzBYH9mSSFwtOdoyYB-kA+fLQ@mail.gmail.com>
     [not found]     ` <CAJJsNHuz17GQkKWsKc0sOJfueEyyJkPM0ErbSNB_A=9Qq9tgTQ@mail.gmail.com>
     [not found]       ` <CAJJsNHsdcYc7WiLuBSYPfoOvjG-v10zFL1d7_ROxx1HYx-nzHA@mail.gmail.com>
     [not found]         ` <CAJJsNHuMa9WoWm0_MZ+dDVRM6UxhOA7eNWqNX=NAVw6V7Nb0jg@mail.gmail.com>
     [not found]           ` <CAJJsNHsn=x-EzAWvRH171uM_8hmX9=_zYrn6yyn_mMP3DQGbbw@mail.gmail.com>
     [not found]             ` <CAJJsNHvXpeMgxLZZ6JDFX859xnYC30Xvs24=G8-pmE+GUk9prw@mail.gmail.com>
     [not found]               ` <CAJJsNHu+Rg7-mHY7mBVL6trKAbTfyq_44KjiQjRkU99_DUyCiQ@mail.gmail.com>
     [not found]                 ` <CAJJsNHueWeocmYN7tQZ111wi6GyAf81OBpR0gaqJaq6N0RokSQ@mail.gmail.com>
     [not found]                   ` <CAJJsNHvaeOdhia9bd1b-FTobUvYPsdryRo1U7fPdf=J6Xng1Rw@mail.gmail.com>
     [not found]                     ` <CAJJsNHuWf42Pzz39oH1F+NHxPoeMdoXqT8-5F8B5OLye1o8sFQ@mail.gmail.com>
     [not found]                       ` <CAJJsNHum5CVA7HOL26__WjFAQV09mAxfvDJ3o1Yu3BYNydzdvw@mail.gmail.com>
     [not found]                         ` <CAJJsNHs_aDmuqKpetceM+t_+jQLs8m0hFgtvhCJVvNLBrn3VjQ@mail.gmail.com>
     [not found]                           ` <CAJJsNHsT0VBufwkr4Lk-yRndeKDhchrp5g-UDv-vhcyjpi3-LA@mail.gmail.com>
     [not found]                             ` <CAJJsNHt46qBoihBBojt4Fu7S7Ryrqi-1HpXGiX4_nVMDQBq1oQ@mail.gmail.com>
     [not found]                               ` <CAJJsNHtCDCaW3ZtnNutL9q-PY4b5+eS-zcyfgT1B23gKH+127A@mail.gmail.com>
     [not found]                                 ` <CAJJsNHuU3NXGjZ+afUQ_Ct_3y5V7JgZQzemc9SQUGmGjrm8wfQ@mail.gmail.com>
     [not found]                                   ` <CAJJsNHt08PbYvtcVbCPw383-93r-NuCV_UPjGZ+moHime4dzFw@mail.gmail.com>
     [not found]                                     ` <CAJJsNHvtJ3eUNgpe8apLDoC_UOmk+0ezLiTXkhdG2tndTx=WBA@mail.gmail.com>
     [not found]                                       ` <CAJJsNHu+8+42R0jMfLbNZ7K8c0kQR3Tex+xiPH6WE+w_f+ORPQ@mail.gmail.com>
     [not found]                                         ` <CAJJsNHubV--c5xJQrrF6F5K5gQ2gexy3x-7pL_Gn7Oe6TpiMbw@mail.gmail.com>
     [not found]                                           ` <CAJJsNHvEPWSdquKrOt5kGRFFmLJ3yq2YfxEuQUC9upmKYV4oeg@mail.gmail.com>
     [not found]                                             ` <CAJJsNHsMBz06oo-miAkqUC4VenYq1+o08pi=fgDsnaq9B_+KSA@mail.gmail.com>
     [not found]                                               ` <CAJJsNHun0bf-TKxOr-WVJ1Tj3zt40OZOZAtzxRhD_+ise_+7=g@mail.gmail.com>
     [not found]                                                 ` <CAJJsNHvurUUkysWzjbxcXhdaUbL-CRPiBBABFd2HuFD14wZLkQ@mail.gmail.com>
     [not found]                                                   ` <CAJJsNHsib5VRs4R1N6C6ZhynAGhJ+QxW3d2LbzojEFnwddyyhw@mail.gmail.com>
     [not found]                                                     ` <CAJJsNHt01LuXqD+V=++6fp_VyW7TZ_1OzrsxZ7brBiqUKHcdng@mail.gmail.com>
     [not found]                                                       ` <CAJJsNHuZ_iMdeV0jZ618jO7osvUk97uV9Wae9NA_dgRQT=E5uQ@mail.gmail.com>
     [not found]                                                         ` <CAJJsNHtZ8bEZ-5zfpjzhoxfzaOM1RuZvRx6J+Pcr=r0=zZd=Kg@mail.gmail.com>
     [not found]                                                           ` <CAJJsNHspUanL7Y1E9RB_4G54Fs3RUy1uqUw8aUq3XYY6os_5ww@mail.gmail.com>
     [not found]                                                             ` <CAJJsNHtumDA8js_kaagwDHxLy9iF7UXwb5n9yX5cLvwNDDEMaw@mail.gmail.com>
     [not found]                                                               ` <CAJJsNHss2bW0DqYkvf5W4CMG3gaWFcT4oqXyzT4y93FveR6k4A@mail.gmail.com>
     [not found]                                                                 ` <CAJJsNHuHA_rksFEip9r=hKuHoM9Bag2AmFYr=2miJKzOWJC5dQ@mail.gmail.com>
     [not found]                                                                   ` <CAJJsNHv1QtpDvw_CZKhqryCxD21jtL+MQbZgqG-0HxzBbsnvPw@mail.gmail.com>
     [not found]                                                                     ` <CAJJsNHtNMQGiJwarobHKBau7o_hEnSMKSznKkbfa8y4e4BUA8Q@mail.gmail.com>
     [not found]                                                                       ` <CAJJsNHsX9Za=+8LYTK8mnq8XtuMrL03U2LAXHy15qv+XEKupZA@mail.gmail.com>
     [not found]                                                                         ` <CAJJsNHuyty=i6Mxu_sreVBkqmgDKtp3050=Hh1qy8Hfs8yV2sw@mail.gmail.com>
     [not found]                                                                           ` <CAJJsNHvNRzd0ZCv3QX9cR=JV8eUHF0z2QWdx9CK1v42iz2fOyA@mail.gmail.com>
     [not found]                                                                             ` <CAJJsNHsYjFj-g1RBoRMoTrfjLStCQ8SQrE7ZcM569yW0mxb1qQ@mail.gmail.com>
     [not found]                                                                               ` <CAJJsNHvVEydafdqx7ZwG9XmdNLZzbewVpAMfnvS=ZXNzV1fQYQ@mail.gmail.com>
     [not found]                                                                                 ` <CAJJsNHtEqzEg83k_s4Kg0YiJ3tWfCPOTPmnH0D-YiKZ6K5oGGg@mail.gmail.com>
     [not found]                                                                                   ` <CAJJsNHt2WydZewhrH5XZ-mpUMGBYvfke1H6F2cORpORv=LxShQ@mail.gmail.com>
     [not found]                                                                                     ` <CAJJsNHsCQXkp2uDTMTRJ=2ZVTcUXEPCPNusncACFtGoov5cOzw@mail.gmail.com>
     [not found]                                                                                       ` <CAJJsNHusmafTVS3xTyT5hR3ZjLkQ99A9qQK33e05BRdTF7+xhQ@mail.gmail.com>
     [not found]                                                                                         ` <CAJJsNHsp8oW=C-yzO5qiF9imZf-5EO+pYUJU6yHZz1wF=nevUA@mail.gmail.com>
     [not found]                                                                                           ` <CAJJsNHvOMxE2sBa4TKaazMsRH4OJaN=eS0JDRO81=J1OzGLkcg@mail.gmail.com>
     [not found]                                                                                             ` <CAJJsNHu3EZx9c2x99gwSEUNBCEa3SirteUx8+MqWcU_ShjLDRA@mail.gmail.com>
     [not found]                                                                                               ` <CAJJsNHsBYgmTmGeqUnvjnomO10m_TXjgt5xS8rROcV2aF=PPsQ@mail.gmail.com>
     [not found]                                                                                                 ` <CAJJsNHsKSE9ftorgZ4J7YLwz5rMpYq-7WpEtk61JEtxJfneKVQ@mail.gmail.com>
     [not found]                                                                                                   ` <CAJJsNHuTY+ckfvujru2K4vsOkfHyp1kYMJQAF0rmSeHhv3HdaA@mail.gmail.com>
     [not found]                                                                                                     ` <CAJJsNHuYfMWGjkw1_RPA5-a6p_EVsv3b4gussi9y9Mb8+WsR_A@mail.gmail.com>
     [not found]                                                                                                       ` <CAJJsNHv=cEnxg=yTCiDjWRedpBLuXmAyk-mGgQbHMDxFqoiiBw@mail.gmail.com>
     [not found]                                                                                                         ` <CAJJsNHs90da2u+ufLcVoqyYQ_pkAr55=gL_ZY0mAGCoDmyqMbQ@mail.gmail.com>
     [not found]                                                                                                           ` <CAJJsNHtni20bBUjLd_KOLnVxnZ4_AdDumLCkWbiU4v-cgXfJcA@mail.gmail.com>
     [not found]                                                                                                             ` <CAJJsNHtVQ_hSQho2yd_4n8g+sQ5mCZjrG-SALcm1Vrbb3_1oVw@mail.gmail.com>
     [not found]                                                                                                               ` <CAJJsNHus+SGAfh6SR9uY_VjgSiSsqtsH0=V-ecM8pm=whwSp0g@mail.gmail.com>
     [not found]                                                                                                                 ` <CAJJsNHvruYORGrd--nQayYW28k=F-A9PiP9O25w_1pvR2ABvcw@mail.gmail.com>
     [not found]                                                                                                                   ` <CAJJsNHsTYta-e0S_VZNMHNrEYnfy57U1W_bbzvkS3gQ=qVt75g@mail.gmail.com>
     [not found]                                                                                                                     ` <CAJJsNHv+TyGj=Mg3t2DS5YAW5WMdjckjFZA5KTO=JDtHB9iNCg@mail.gmail.com>
     [not found]                                                                                                                       ` <CAJJsNHukqjvTv-2G0jM8D6c2Bmt0o_uW6cd=GXvJHOzmSRg+BA@mail.gmail.com>
     [not found]                                                                                                                         ` <CAJJsNHv8mnT_GUcHmZy=6=_k1PxBSpfMSTtrz9UbERzhVwSbgw@mail.gmail.com>
     [not found]                                                                                                                           ` <CAJJsNHtb8Zed+5jZKx3oBNP7EMV-OPbuJD9mPjryRuroM=2bnA@mail.gmail.com>
     [not found]                                                                                                                             ` <CAJJsNHsWjUeCUp9jHwzEMMuN9jT2CNocpLyJRJKzDvY5Q_VAaQ@mail.gmail.com>
     [not found]                                                                                                                               ` <CAJJsNHuLfeB_oP+98jteLyr_q=_pdWkJP1+h4fgUBoeG3shBXQ@mail.gmail.com>
     [not found]                                                                                                                                 ` <CAJJsNHuM-k1-MKHw-TcP5RFJz7bwg=YuLvjXKzunYcUK7wYhjg@mail.gmail.com>
     [not found]                                                                                                                                   ` <CAJJsNHvEttaWfk9FQXA34WskxqU5sTyzvK_a56voWVOb7vtbcQ@mail.gmail.com>
     [not found]                                                                                                                                     ` <CAJJsNHukHECFiMj2PFKOMSQmkT1f8Y=N20_9bx2p_3n0ahJKmQ@mail.gmail.com>
     [not found]                                                                                                                                       ` <CAJJsNHtZWH4Cy-kpCRrbLeA339uoC3mL0Be2MBNdbW8PqjboJg@mail.gmail.com>
2017-08-09 18:49                                                                                                                                         ` [bitcoin-dev] Structure for Trustless Hybrid Bitcoin Wallets Using P2SH for Recovery Options Colin Lacina
2017-08-09 19:35                                                                                                                                           ` Jonas Schnelli
2017-08-09 20:14                                                                                                                                           ` Nick ODell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox