doc/security-warnings.md

   1 Security Warnings
   2 ====================
   3
   4 Security Audit
   5 --------------
   6
   7 Zcash has been subjected to a formal third-party security review. For security
   8 announcements, audit results and other general security information, see
   9 https://z.cash/support/security.html
  10
  11 x86-64 Linux Only
  12 -----------------------
  13
  14 There are [known bugs](https://github.com/scipr-lab/libsnark/issues/26) which
  15 make proving keys generated on 64-bit systems unusable on 32-bit and big-endian
  16 systems. It's unclear if a warning will be issued in this case, or if the
  17 proving system will be silently compromised.
  18
  19 Wallet Encryption
  20 -----------------
  21
  22 Wallet encryption is disabled, for several reasons:
  23
  24 - Encrypted wallets are unable to correctly detect shielded spends (due to the
  25   nature of unlinkability of JoinSplits) and can incorrectly show larger
  26   available shielded balances until the next time the wallet is unlocked. This
  27   problem was not limited to failing to recognize the spend; it was possible for
  28   the shown balance to increase by the amount of change from a spend, without
  29   deducting the spent amount.
  30
  31 - While encrypted wallets prevent spending of funds, they do not maintain the
  32   shielding properties of JoinSplits (due to the need to detect spends). That
  33   is, someone with access to an encrypted wallet.dat has full visibility of
  34   your entire transaction graph (other than newly-detected spends, which suffer
  35   from the earlier issue).
  36
  37 - We were concerned about the resistance of the algorithm used to derive wallet
  38   encryption keys (inherited from [Bitcoin](https://bitcoin.org/en/secure-your-wallet))
  39   to dictionary attacks by a powerful attacker. If and when we re-enable wallet
  40   encryption, it is likely to be with a modern passphrase-based key derivation
  41   algorithm designed for greater resistance to dictionary attack, such as Argon2i.
  42
  43 You should use full-disk encryption (or encryption of your home directory) to
  44 protect your wallet at rest, and should assume (even unprivileged) users who are
  45 running on your OS can read your wallet.dat file.
  46
  47 Side-Channel Attacks
  48 --------------------
  49
  50 This implementation of Zcash is not resistant to side-channel attacks. You
  51 should assume (even unprivileged) users who are running on the hardware, or who
  52 are physically near the hardware, that your `zcashd` process is running on will
  53 be able to:
  54
  55 - Determine the values of your secret spending keys, as well as which notes you
  56   are spending, by observing cache side-channels as you perform a JoinSplit
  57   operation. This is due to probable side-channel leakage in the libsnark
  58   proving machinery.
  59
  60 - Determine which notes you own by observing cache side-channel information
  61   leakage from the incremental witnesses as they are updated with new notes.
  62
  63 - Determine which notes you own by observing the trial decryption process of
  64   each note ciphertext on the blockchain.
  65
  66 You should ensure no other users have the ability to execute code (even
  67 unprivileged) on the hardware your `zcashd` process runs on until these
  68 vulnerabilities are fully analyzed and fixed.
  69
  70 REST Interface
  71 --------------
  72
  73 The REST interface is a feature inherited from upstream Bitcoin.  By default,
  74 it is disabled. We do not recommend you enable it until it has undergone a
  75 security review.
  76
  77 RPC Interface
  78 ---------------
  79
  80 Users should choose a strong RPC password. If no RPC username and password are set, zcashd will not start and will print an error message with a suggestion for a strong random password. If the client knows the RPC password, they have at least full access to the node. In addition, certain RPC commands can be misused to overwrite files and/or take over the account that is running zcashd. (In the future we may restrict these commands, but full node access – including the ability to spend from and export keys held by the wallet – would still be possible unless wallet methods are disabled.)
  81
  82 Users should also refrain from changing the default setting that only allows RPC connections from localhost. Allowing connections from remote hosts would enable a MITM to execute arbitrary RPC commands, which could lead to compromise of the account running zcashd and loss of funds. For multi-user services that use one or more zcashd instances on the backend, the parameters passed in by users should be controlled to prevent confused-deputy attacks which could spend from any keys held by that zcashd.
  83
  84 Block Chain Reorganization: Major Differences
  85 -------------------------------------------------
  86
  87 Users should be aware of new behavior in Zcash that differs significantly from Bitcoin: in the case of a block chain reorganization, Bitcoin's coinbase maturity rule helps to ensure that any reorganization shorter than the maturity interval will not invalidate any of the rolled-back transactions. Zcash keeps Bitcoin's 100-block maturity interval for generation transactions, but because JoinSplits must be anchored within a block, this provides more limited protection against transactions becoming invalidated. In the case of a block chain reorganization for Zcash, all JoinSplits which were anchored within the reorganization interval and any transactions that depend on them will become invalid, rolling back transactions and reverting funds to the original owner. The transaction rebroadcast mechanism inherited from Bitcoin will not successfully rebroadcast transactions depending on invalidated JoinSplits if the anchor needs to change. The creator of an invalidated JoinSplit, as well as the creators of all transactions dependent on it, must rebroadcast the transactions themselves.
  88
  89 Receivers of funds from a JoinSplit can mitigate the risk of relying on funds received from transactions that may be rolled back by using a higher minconf (minimum number of confirmations).
  90
  91 Logging z_* RPC calls
  92 ---------------------
  93
  94 The option `-debug=zrpc` covers logging of the z_* calls.  This will reveal information about private notes which you might prefer not to disclose.  For example, when calling `z_sendmany` to create a shielded transaction, input notes are consumed and new output notes are created.
  95
  96 The option `-debug=zrpcunsafe` covers logging of sensitive information in z_* calls which you would only need for debugging and audit purposes.  For example, if you want to examine the memo field of a note being spent.
  97
  98 Private spending keys for z addresses are never logged.
  99
 100 Potentially-Missing Required Modifications
 101 ------------------------------------------
 102
 103 In addition to potential mistakes in code we added to Bitcoin Core, and
 104 potential mistakes in our modifications to Bitcoin Core, it is also possible
 105 that there were potential changes we were supposed to make to Bitcoin Core but
 106 didn't, either because we didn't even consider making those changes, or we ran
 107 out of time. We have brainstormed and documented a variety of such possibilities
 108 in [issue #826](https://github.com/zcash/zcash/issues/826), and believe that we
 109 have changed or done everything that was necessary for the 1.0.0 launch. Users
 110 may want to review this list themselves.