SQLite Forum

Embedded Encrypted Log - SEE vs ZIPVFS

Embedded Encrypted Log - SEE vs ZIPVFS

(1) By Ken Edwards (kejaed) on 2020-08-13 18:33:12 [link] [source]


I would like to use SQLite in a project as the base for logging in an embedded system. The logs need to be encrypted so I have looked into the SQLite Encryption Extension (SEE) and the ZIPVFS Read/Write Compressed Database Extension.

While compression is not a requirement, seeing that the ZIPVFS extension offered both compression and encryption made me consider it as the extension to go with for the logging system.

However, in this thread in the SQLite mailing list, Dr. Hipp noted that:

"ZIPVFS is designed to be read-mostly. ZIPVFS trades write performance in exchange for better compression and read performance."

This, along with the notes in the ZIPVFS readme section 9.4 "Database fragmentation", lead me to believe that ZIPVFS might not be the best candidate for an encrypted logging system on an embedded platform, and that SEE would be a better choice.

If anyone could comment on the proposed selection of SEE over ZIPVFS for an encrypted embedded logging system, I would appreciate it.

Thank you in advance.


(2) By Larry Brasfield (LarryBrasfield) on 2020-08-13 22:16:06 in reply to 1 [link] [source]

You say that compression is not a requirement, so one of your options is to use Zlib's compression level 0 which means "no compression". Dr. Hipp's observation about read-mostly and write performance will have little applicability then.

You appear to have "encrypted" as a requirement, but since you appear willing to settle for whatever that means in terms of security. (I take this to indicate weak encryption would be good enough for your purposes.) Traditional PKZIP encryption (used on common "zip" utilities) is quite weak, and easily broken. Stronger encryption is done separately from Zlib's operation.

Given your not-yet-well-defined requirements, the choice between SEE and Zlib (non)compression with weak encryption could go either way once performance and security requirements are firmed up. Strong encryption takes time, on both read and write, regardless of where it is implemented (in software. [a]) Compression is a lightweight operation compared to strong encryption. So I submit that you have setup a false choice with your question.

[a. Hardware supported encryption may be much faster. ]

(3) By Keith Medcalf (kmedcalf) on 2020-08-13 23:56:23 in reply to 1 [source]

The logs need to be encrypted

Why do the logs need to be encrypted? Is there a rational reason or is it just "checkbox compliance"?

Encryption is trivial. Key Management is hard. Without the latter the former is merely obfuscation.