We have an insecure database we want to make secure using only a small secure storage (the superblock). By secure we mean that the database will end up providing confidentiality and integrity but will not guarantee availability. The block store itself is implemented as a Merkle Tree. A Merkle Tree or hash tree stores information such that every leaf node is labelled with the hash of a data block and every non-leaf node is labelled with the cryptographic hash of the labels of its child nodes. In this implementation, data is also being stored in the non-leaf nodes. Since the hash of each node depends on the hash of its children, if any node changes, the hash at the top changes, which is useful in detecting adversary activity and providing integrity. For confidentiality, each node is encrypted with a key and a nonce, where the nonce is the number of the block (blockNum). A truly random nonce would be better but this suffices since it will be unique for each block. The key for encryption and decryption is stored in the superblock. To our knowledge each user has their own block store which itself has its own "superblock" in which the key for each user is stored. These "superblocks" are not themselves secure but rely on the security of the master block. The master block is an abstraction in block store multiplexor. The multiplexor has one true superblock and is one blockstore and the rest that are created for the users are an abstraction. As such, since this tree is implemented with BlockStoreAuthEnc, the entirety of the multiplexor (including the virtual user stores) is secure. We tested the idea that each user has their own abstract superblock to store keys by creating several users in different sessions, authenticating them, and then checking if the superblocks were overwritten by authenticating them again. If they did not have separate superblocks then the information would have been rewritten and they would not have been able to be authenticated, but this was not the case. In ServerAuth we create a substore with the multiplexor and store the hashed password in the superblock that has been salted with the username. This information is used to authenticate the users upon login.Furthermore, the myBlockStore is used to create the ArrayStore to store the usernames. Since myBlockStore is created from the multiplexor, it is also secured by our integrity check and encryption. Finally, we stored the first hundred bytes of the username to check existence, although by hasing the password with the username as salt, the same username as in creation must be used to authenticate (as would be desired).