Securing Data at Rest, Pt. III

Evaluated GPG for encrypting audio files. It worked very well, and fast enough for in-band decryption, at about 0.3 s / file, on average on my dev box. Unfortunately, GPG seems to have poor library support in a deliberate attempt to subvert malicious users.

I once mistakenly thought of GPG as an encryption total package: custom encryption, key management, and key trust management. Now I see it really as a key trust application layered over existing standard compression algorithms, with a key management front end. Given that we will not be sharing keys, key trust is not at issue, and it really makes GPG seem like overkill. Hence, my decision to spike encryption of transcripts using Java's Cryptographic Extension.

Since I have the option with the JCE, I'm interested in speedy decryption, which would mean using a stream cipher. JCE provides stream ciphers, but stream ciphers have weaknesses, especially if you happen to reuse a key. If an attacker got her hands on the ciphertext for which she has the plaintext, she can derive the key stream. As a result, the recommended practice is to use a block cipher that supports a mode that behaves like a stream cipher (e.g., AES in CFB mode).

For reference, tests yielded the following results:

• Block cipher: 15ms encrypt / 125 ms decrypt
• Block cipher as stream: 63 ms encrypt / 78 ms decrypt
• Stream cipher: 31 ms encrypt / <>

Next is the issue of protecting secret data. Security best practice is to not store keys in a config file. Your options are in a separate file/registry, encrypted/not. The idea of encrypting the keys again seems like the quickest way into the 9th circle of key hell. This made me look at LSA secrets and the DPAPI.

LSA secrets is the first choice, because it stores the secret data in the profile of the running user account, making storage not my problem. Accounts indicate that this API is complex, has a maximum number of secrets that can be stored, and is required to run with administrative privileges--all cons, as far as I'm concerened.

DPAPI sounds like salvation, but for the fact that it's at end of life (MSDN advises using the .NET framework instead) and I'm responsible for storing the encrypted blob, and interop with Java will take some work, likely involving JNA to export the DPAPI methods. If I have to store the keys, I might as well do it some way more convenient.