Skip to content

Database Security

Jump to bottom
scrod edited this page Sep 13, 2010 · 7 revisions

If encryption is enabled (Preferences > Notes > Security), neither the data nor the metadata of any note will ever be written to disk in clear text, even temporarily. Even the number of notes and their relative lengths are fully opaque. By ensuring that no unencrypted data will ever touch the disk, the problem of secure file deletion can be avoided entirely.

Encryption algorithm

Notational Velocity uses the OpenSSL implementation of AES-256 in cipher-block chaining mode. However if AES-128 proves more secure, the DB preferences format would make using an alternative key size straightforward.

Key derivation

  1. Beginning with the password (which can contain any unicode character and be of any length), a master key is generated via the PBKDF2 function using 1) as many SHA-1 iterations as the CPU can perform within a user-specified period of time and 2) a fully random 256-byte salt.
  2. The master key is then fed into PBKDF2 with a single iteration and another 256-byte random salt to generate a one-time data session key, which is used to actually encrypt compressed bulk data.
  3. Stored alongside the compressed data is a verifier key, also generated by PBKDF2 from the master key with yet another salt. The data session salt and master salt are stored as well.
  4. Upon decryption, the master key is computed from the password + stored master salt, and the verifier key is computed from that master key + verifier salt. If the computed verifier key matches the stored verifier key, then the data session key is computed from the master key + stored data session salt and decryption finally takes place.

Write-ahead log security

The write-ahead log file, which stores changes not yet written to the database, is also encrypted using keys ultimately derived from the password.

  1. Upon initializing the log, a log session key is generated by PBKDF2 from the master key plus a log session salt.
  2. This log session key is then used to generate a record key with a unique salt each time a change-record is appended. The record salt is stored in the header prefixing each record.

Securing memory-resident note data

Because it’s inevitable that the contents of Notational Velocity’s memory will be swapped to disk at some point, users should enable Secure Virtual Memory in the Security preferences panel in Mac OS X.

Additionally, to prevent unauthorized access while Notational Velocity is left running, users should also enable Require password to wake this computer from sleep or screen saver from the same panel, and set the screen saver to activate after some period of time.

Clone this wiki locally