HiVE -- Frequently asked Questions
==================================

Disclaimer
Reading the FAQ is not a good substitute for carefully reading the
original paper: https://eprint.iacr.org/2014/344.pdf

Q: The current implementation only supports 2 volumes. Isn't that
pointless?

A: Not at all! In general, you can plausibly deny the existence of a
2nd volume, if 1) there is no evidence on the disk that you are using
a 2nd volume, and 2.) installation of HiVE does not automatically
imply that you use a 2nd volume. That is, there has to be a plausible
reason that you could just have used a single volume.

Q: So, why would I use HiVE with just a single volume?

A: Even with only a single volume, HiVE has a significant advantage
over Truecrypt running with a single volume. In case you are convinced
that you will never be coerced to reveal your password, e.g., if you
are living or traveling in a country where law prohibits
self-discrimination in all cases, you only need one volume.  Now, as
HiVE employs a novel Oblivious RAM construction, even a single volume
is protected against a multiple snapshot adversary that gets access to
your hard disk on several occasions. An adversary that can monitor
patterns of (encrypted) disk blocks changing can, without having access
to the password, learn a lot about what is going on the hard
disk. Contrary to Truecrypt, HiVE protects in these situations, too.

Q: You are using AES-CBC with 256 bit key length. Is that secure?

A: HiVE requires an ''IND$-CPA'' encryption construction, i.e.,
ciphertexts need to be indistinguishable from random bit
strings. Standard examples are CBC or Counter Mode using a
''pseudo-random permutation'' (secure block cipher). While, e.g.,
Truecrypt offers triple encryption, we are not aware of any
significant real-world attack against AES-256. We stress that the
current implementation uses AES-256 as an exchangeable building
block. You are free to replace it with the block cipher and key length
you fancy. AES has the advantage of hardware acceleration on modern
CPUs. Note that XTS as used in many related disk encryption solutions
does not provide ''IND$-CPA'', leading to vulnerabilities against some
attacks.

Q: How do you generate randomness? 

A: *UPDATE: We now use a scheme based on AES-CTR to generate
randomness by default.* As in many cryptographic protocols, HiVE
requires cryptographically secure generation of (pseudo-)random
numbers. In the current implementation, as a starting point, we use a
scheme to generate pseudo-random numbers based on the stream cipher
RC4.  In personal communication, K. Paterson and M. Strefler have
pointed out that RC4, besides its various modifications (e.g.,
DROP-N), is prone to certain attacks (I. Mantin, Eurocrypt 2005).  As
with encryption, we stress that RC4 is again an exchangeable building
block, and we encourage the open source community to expand our
implementation with more potential RNGs.

Q: How can I trust you? Is there a backdoor in HiVE's implementation?

A: You should neither trust the concepts nor the current
implementation. While HiVE has been scientifically peer-reviewed and
will be presented at ACM's flagship security conference CCS'14, this
usually does not mean much, and you should carefully try to understand
the ideas yourself. The source code is open, and we encourage to
verify and contribute to this project.

Q: When should I use HiVE?  

A: If you believe that an adversary can get access to the blocks of
your hard disk on more than one occasion.

Q: When should I not use HiVE?

A: If you want to protect your data only against theft or loss, so the
adversary gets access to your data only once. Note that we have
discussed the last two issues in great detail in the original paper.