[wps]

Because KDBX is a gzipped and encrypted stream, this is actually fundamentally an issue with the spec itself. A client must re-encrypt and compress the file prior to writing because a mere append operation is not possible. SQLite solves this issue by allowing you to write with page level granularity rather than being forced to dump the whole file for a single tiny change!

[ptx]

Couldn't they simply switch to zip files? Those have an index and allow opening individual files within the archive without reading the whole thing.

Also, I don't understand how using XML makes for a brittle schema and how SQL would solve it. If clients choke on unexpected XML elements, they could also do a "SELECT *" in SQL and choke on unexpected columns. And the problem with people adding different attributes seems like just the thing XML namespaces was designed for.

[lukeschlather]

It's a single XML file. Zip sounds like the worst of both worlds. You would need a new schema that had individual files at some level (probably at the "row level.") The article mentions SQLCipher which allows encrypting individual values separately with different keys. Using different keys for different parts of a kdbx sounds ridiculous, but I could totally imagine each row being encrypted with a compound key - a database-level key and a row-level key, or using PKI with a hardware token so that you don't need to decrypt the whole row to read a single field, and a passive observer with access to the machine's memory can't gain access to secrets the user didn't explicitly request.

[WorldMaker]

ZIP files can have block-like relatives to the SQLite page. It could still be a single XML file and have piecewise encryption in a way that change saving doesn't require an entire file rewrite, just the blocks that changed and the updated "File Directory" at the end of the ZIP file.

Though there would be opportunity to use more of the ZIP "folder structure" especially for binary attachments and icons, it wouldn't necessarily be "required", especially not for a first pass.

(That said there are security benefits to whole file encryption over piecewise encryption and it should probably be an option whether or not you want in-place saves with piecewise encryption or whole file replacement with whole file encryption.)

[kbolino]

A ZIP file with solid encryption (i.e., the archive is encrypted as a single whole) has all of the same tradeoffs as a KDBX file as far as incremental updates are concerned.

A ZIP file with incremental encryption (i.e., each file is individually encrypted as a separate item) has its own problems. Notably: the file names are exposed (though this can be mitigated), the file metadata is not authenticated, and the central directory is not authenticated. So sure, you can read that index, but you can't trust it, so what good is it doing? Also, to support incremental updates, you'd either have to keep all the old versions of a file around, or else remove them and end up rewriting most/all of the archive anyway. It's frankly just not a very good format.

[layer8]

Not encrypting everything as a whole however leaks information about the structure and what/how much was changed between two versions of the file.

[zzrrt]

> SQLite solves this issue by allowing you to write with page level granularity rather than being forced to dump the whole file for a single tiny change!

Smaller ideas that would address this: add support for non-CBC encryption modes, tweak/disable the compression so that small changes require less rewriting.

[ycombinatrix]

I see, thanks. Have you considered moving to Bitwarden?

[wps]

Yes actually, I have personally onboarded several people to BitWarden! (Including manually migrating their accounts, setting passwords and passkeys, etc) However, I dislike the centralization and lack of control. There was a paper discussed within the past couple days on HN about what a malicious BitWarden server was capable of, despite BitWarden's marketing. I believe BitWarden's team responded promptly and appropriately to the research.

VaultWarden is a good compromise (offers the choice of SQLite or Postgres under the hood), putting you in charge of the primary server, but it is honestly overkill for a single personal user compared to a kdbx file on a webdav share.

[clircle]

> overkill for a single personal user compared to a kdbx file on a webdav share.

Maybe. I'm looking into VaultWarden for my personal passwords because keeping a KBDX file up to date on iOS is painful (without a corporate cloud backing).

[wps]

Hey I’m with you here actually. Synctrain on iOS makes it bearable, and actually wakes itself up periodically in the background to do a sync. It’s not as good as it could be, but far better than the alternatives. Otherwise you can spin up WebDAV and direct connect via keepassium. Both work well in my usage.

[clircle]

> Synctrain

Good tip, I'm going to check that out!