#Security Warnings

## Security Audits

Hush has not been subjected to a formal third-party security review! But the
some of the Zcash and Komodo source code it is based on has.

Hush does our best to integrate fixes and recommendations from upstream audits
to our own code, such as audits on ZecWallet that apply to SilentDragon.
Hush used to report many new bugs and CVEs to upstream Zcash and Komodo but
those relations have broken down.

Additionally, Hush itself finds many CVE's and things-that-should-be-CVE's
in Zcash internals. Since Zcash community treats Hush people so poorly, we
keep these bugs and fixes to ourselves. If you want to know some of them,
let us know and bring your wallet. Public information available at
<a href="https://attackingzcash.com">attackingzcash.com</a>

## Wallet Encryption

Wallet encryption is disabled, for several reasons:

- Encrypted wallets are unable to correctly detect shielded spends (due to the
  nature of unlinkability of ShieldedSpends) and can incorrectly show larger
  available shielded balances until the next time the wallet is unlocked. This
  problem was not limited to failing to recognize the spend; it was possible for
  the shown balance to increase by the amount of change from a spend, without
  deducting the spent amount.

- While encrypted wallets prevent spending of funds, they do not maintain the
  shielding properties of JoinSplits (due to the need to detect spends). That
  is, someone with access to an encrypted wallet.dat has full visibility of
  your entire transaction graph (other than newly-detected spends, which suffer
  from the earlier issue).

- We were concerned about the resistance of the algorithm used to derive wallet
  encryption keys (inherited from [Bitcoin](https://bitcoin.org/en/secure-your-wallet))
  to dictionary attacks by a powerful attacker. If and when we re-enable wallet 
  encryption, it is likely to be with a modern passphrase-based key derivation 
  algorithm designed for greater resistance to dictionary attack, such as Argon2i.

You should use full-disk encryption (or encryption of your home directory) to
protect your wallet at rest, and should assume (even unprivileged) users who are
running on your OS can read your wallet.dat file.

## Side-Channel Attacks

This implementation of Hush is not resistant to side-channel attacks. You
should assume (even unprivileged) users who are running on the hardware, or who
are physically near the hardware, that your `hushd` process is running on will
be able to:

- Determine the values of your secret spending keys, as well as which notes you
  are spending, by observing cache side-channels as you perform a JoinSplit
  operation. This is due to probable side-channel leakage in C++.

- Determine which notes you own by observing cache side-channel information
  leakage from the incremental witnesses as they are updated with new notes.

- Determine which notes you own by observing the trial decryption process of
  each note ciphertext on the blockchain.

You should ensure no other users have the ability to execute code (even
unprivileged) on the hardware your `hushd` process runs on until these
vulnerabilities are fully analyzed and fixed.

## REST Interface

The REST interface is a feature inherited from upstream Bitcoin.  By default,
it is disabled. We do not recommend you enable it until it has undergone a
security review.

## RPC Interface

Users should choose a strong RPC password. If no RPC username and password are set, hush 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 hushd. (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.)

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 hushd and loss of funds. For multi-user services that use one or more hushd 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.

## Block Chain Reorganization: Major Differences

Hush has Delayed-Proof-of-Work, which drastically improves the Zcash rule-of-thumb of "re-organize 100 blocks to crash all ZEC full nodes in the world".

## Logging z_* RPC calls

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.

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.

Private spending keys for z addresses are never logged.

## Potentially-Missing Required Modifications

In addition to potential mistakes in code we added to Bitcoin Core, Zcash
and Komodo and potential mistakes in our modifications to Bitcoin Core, Zcash and Komodo, it is also possible
that there were potential changes we were supposed to make to Bitcoin Core, Zcash and Komodo but
didn't, either because we didn't even consider making those changes or have not found out about
them. Patches Welcome!
