> It stores all password entries (including names) in a single encrypted file (vault).
> a simple custom vault format.
I understand what you're saying about password-store's directory structure exposing website names as plain text filenames...but, the upside of that design is that it tends to be very resilient.
imagine that you're updating an entry in your vault, and right as you save it you lose power, resulting in file corruption.
with password-store's design, the blast radius of the corruption is limited to that one single entry.
with your design, the potential blast radius of corruption could be my entire password vault.
in particular, looking at your file-management code [0, 1] it looks like it does a complete rewrite of the vault file on every save, without doing "rewrite to temp file then atomically rename" or any similar tricks meant to handle partial file writes.
if you haven't seen it before, I'd suggest reading "SQLite As An Application File Format" [2] and consider using SQLite as the storage backend.
It's not like I'm writing the algorithms from scratch, OpenSSL is doing all of the heavy lifting. I'm aiming for actual simplicity, and so my vault format is harder to get wrong than parsing PGP packets (sure, that's handled by GPG in the case of pass, but it is still needless complexity for a password manager).
As for the "safer than pass" thing, pass does not encrypt entry names, so yes encrypting my way is safer than not encrypting at all in that aspect at least. Plus the whole KDF + symmetric only thing, though if you don't trust the way I handle it I have nothing to add here.
And I wouldn't translate "use it at your own risk" to "please use it". More like "you may use it if you choose so". You are free to back me up or tear it apart, or do nothing and go about your day. The software is not production-ready, though any help to change that is welcome.
> It stores all password entries (including names) in a single encrypted file (vault).
> a simple custom vault format.
I understand what you're saying about password-store's directory structure exposing website names as plain text filenames...but, the upside of that design is that it tends to be very resilient.
imagine that you're updating an entry in your vault, and right as you save it you lose power, resulting in file corruption.
with password-store's design, the blast radius of the corruption is limited to that one single entry.
with your design, the potential blast radius of corruption could be my entire password vault.
in particular, looking at your file-management code [0, 1] it looks like it does a complete rewrite of the vault file on every save, without doing "rewrite to temp file then atomically rename" or any similar tricks meant to handle partial file writes.
if you haven't seen it before, I'd suggest reading "SQLite As An Application File Format" [2] and consider using SQLite as the storage backend.
0: https://codeberg.org/jlucas/pacc/src/branch/master/src/db.c
1: https://codeberg.org/jlucas/pacc/src/branch/master/src/vault...
2: https://sqlite.org/appfileformat.html
Why are you rolling out your own crypto? Timing attacks, unvalidated inputs and no bounds checking.
> I am not a cryptographer. ... However I am fairly confident that this is at least safer than pass. Feel free to prove me wrong.
Translation: I have no experience in safe cooking. Please use my garlic oil, and my chicken salad. Feel free to prove me wrong - from the ER ward.
It's not like I'm writing the algorithms from scratch, OpenSSL is doing all of the heavy lifting. I'm aiming for actual simplicity, and so my vault format is harder to get wrong than parsing PGP packets (sure, that's handled by GPG in the case of pass, but it is still needless complexity for a password manager).
As for the "safer than pass" thing, pass does not encrypt entry names, so yes encrypting my way is safer than not encrypting at all in that aspect at least. Plus the whole KDF + symmetric only thing, though if you don't trust the way I handle it I have nothing to add here.
And I wouldn't translate "use it at your own risk" to "please use it". More like "you may use it if you choose so". You are free to back me up or tear it apart, or do nothing and go about your day. The software is not production-ready, though any help to change that is welcome.
Thank you for your attention.