logoalt Hacker News

kbolinoyesterday at 8:58 PM1 replyview on HN

Whole-file encryption with authentication is also more tamper-resistant. Basically the only thing an adversary can get away with there is rolling back the entire file to a previous version.

Whereas, any incrementally encrypted format has the additional risk of piecewise manipulations. For example, while SQLCipher authenticates each page, it doesn't authenticate the entire file, allowing for pages to be deleted, reordered, or duplicated (though duplication is easy to detect since each page has its own IV). The end result will generally just be a corrupted database, which will probably get detected by PRAGMA integrity_check, but compared to KDBX, this will not be detected by default nor is it guaranteed to be detectable at all.


Replies

WorldMakeryesterday at 9:41 PM

Another in place option is AES-encrypted ZIP. ZIP has the benefits that the Directory at the end of the file can also include piecewise metadata for full file validation.

A part of me wonders if the only real upgrade needed for the next "large file" KDBX relative format is from a GZIP stream of the XML plus attachments to a ZIP container of the XML with attachments in some folder structure combined with the choice of a good piecewise (modern) encryption for the ZIP container. (That is taking more cues from 7zip than from classic, now broken password-encrypted ZIP files.)

(Though as someone who tries to keep my KDBX files small, I think I'd still prefer the option of a whole-file encrypted format.)