This document provides a high-level overview of the encryption implementation released in VoodooPad 5.1.4 (Mac) and VoodooPad 2.1.4 (iOS).
Additional technical details are available via the VoodooPad Crypto Specification.
After Plausible Labs' acquisition of VoodooPad, a cryptography audit was performed, and VoodooPad's legacy encryption implementation was found to be fundamentally insecure. This standard was developed as a replacement, using only well-documented and well-understood primitives and protocols. The standard is published publicly to allow for external review, verification, and comment.
As of 5.1.4 (Mac OS X) and 2.1.4 (iOS), all VoodooPad releases ship with a secure encryption implementation conforming to this standard. In addition, VoodooPad will display a warning — and allow the user to perform an immediate upgrade — upon opening a document encrypted with the insecure legacy cryptography implementation.
VoodooPad supports two modes of document encryption:
Both per-page and full-document encryption are based on the composition of well-understood standards and recommendations:
To prevent padding oracle attacks, as well as to decrease the potential attack surface of the application, VoodooPad leverages encrypt-then-MAC for all authenticated encrypted data.
PBKDF2-HMAC-SHA512 is used for all password-based key derivation, and HKDF is used to generate subkeys from the PBKDF2 output, where required. Keys are only ever used for a single purpose.
VoodooPad also makes use of SQLite to generate indices of document data for faster querying and searching, stored seperately in
~/Library/Caches. Refer to Appendix A for additional details regarding the use of encryption with SQLite.
When performing full document encryption, multiple keys are used to perform encryption and authentication of the VooodooPad document:
If the document password is changed:
Per-page encryption builds on the same cryptographic foundation as full-document encryption, but uses a slightly simplified keying model based on per-page password-based key derivation:
If the page's password is changed, new PMK and PMK-DATA keys are generated as above, and the page data is re-encrypted with the newly derived keys.
Unlike full-document encryption, per-page encryption exposes page meta-data — including the page name — as unauthenticated plaintext in the document's SQLite cache (stored seperately from the document in
Refer to the VoodooPad Crypto Specification for a complete accounting of meta-data exposed via per-page encryption.
When encrypting SQLite indexes, VoodooPad makes use of SEE, a proprietary encryption extension authored by the SQLite developers. SEE supports a fixed set of ciphers and encryption modes; VoodooPad uses SEE's AES-128-CCM implementation to ensure both confidentially and authentication of the per-document index data.