lldbenc

lldbenc

this library is a work in progess!

it has not been audited!

DO NOT EXPECT IT TO BE SECURE!

This package implements an encryption wrapper for lldb.Filer. Ideally it can at some point be used to encrypt modernc.org/kv databases.

The encryption is performed using AES-XTS. This is also used e.g. by the linux disk encryption LUKS. What is noteworthy is that the XTS mode of operation is not authenticated, i.e. it can not detect if changes to the ciphertext are made. Instead it decrypts to random data. Authenticated modes of operation have a per-block overhead, which is something i didn't want in the application i had in mind designing this. However, in order to be helpful in other contexts as well, I am considering to add support for this.

Open Issues

• figure out how to select initial tweak
  • idea: derive two values from the provided key, one for en/decryption; one as a tweak
• consider implementing support for multiple modes of operation.
• throughout the code, implement logical and physical block size to be different. this is a groundstone for authenticated modes of operation.
• discuss threat model around unencrypted write-ahead-log files, and how to mitigate the threat.
• research if lldb.ACIDFiler0 can be made to use an lldb.Filer instead of os.File.

Limitations

I hoped I could use this library to encrypt a modernc.org/kv database. However, despite being mostly based on lldb.Filer, parts of that library (the write-ahead-log, to be precise) still consume an *os.File, which we can not encrypt this way. This means that if we still used it, all data will be written to disk in the clear, and only deleted afterwards. Since SSDs usually don't really delete data in order to achieve longer life-times, this can be a powerful exfiltration vector. Additionally having regular disk-encryption reduces the risk to some degree, but not entirely. Another option could be to store the write-ahead-log in a ramdisk, but that would mean that it is lost if the computer crashes.

The best case would be if the write-ahead-log would be changed to work with lldb.Filers.

How does it work?

Encryption is performed in larger blocks (these are not the AES blocks). The current default block size is 256 bytes but can be configured. I believe a reasonable block size nowadays woud be 4kB, because disk updates require rewriting this much anyway. Ultimately however it likely depends on the use case.

In order to provide a footgun for users, the package allows using a different block cipher than AES.

What can I use as keys?

The encryption key must be pseudorandom. This especially means that passwords can be immediately used. Instead, use a password-based key derivation function like Argon2, Ballon hashing or scrypt to derive a strong key from the password. To select the parameters, follow the advice in the Argon2 RFC:

We recommend the following procedure to select the type and the parameters for practical use of Argon2.

1. Select the type y. If you do not know the difference between them or you consider side-channel attacks as viable threat, choose Argon2id.

2. Figure out the maximum number h of threads that can be initiated by each call to Argon2.

3. Figure out the maximum amount m of memory that each call can afford.

4. Figure out the maximum amount x of time (in seconds) that each call can afford.

5. Select the salt length. 128 bits is sufficient for all applications, but can be reduced to 64 bits in the case of space constraints.

6. Select the tag length. 128 bits is sufficient for most applications, including key derivation. If longer keys are needed, select longer tags.

7. If side-channel attacks are a viable threat, or if you're uncertain, enable the memory wiping option in the library call.

8. Run the scheme of type y, memory m and h lanes and threads, using different number of passes t. Figure out the maximum t such that the running time does not exceed x. If it exceeds x even for t = 1, reduce m accordingly.

9. Hash all the passwords with the just determined values m, h, and t.