2 ms·
From a cursory scan, this looks like it doesn't support key wrapping -- the private key ("identity" in age's parlance) is stored unencrypted on disk. This is a
by woodruffw 4y ago
From a cursory scan, this looks like it doesn't support key wrapping -- the private key ("identity" in age's parlance) is stored unencrypted on disk.
This is arguably a non-issue for most use cases (disk access is "game over" under most threat models), but it's nice to have e.g. for sharing configurations between multiple machines over a public channel (like a dotfiles repository). It would also bring this roughly up to "spec" with what other password managers do (i.e., in terms of requiring a "master" password that unlocks the vault).
- j3s 4y agovery true, and thank you for pointing this out. this is an intentional design decision - you can see me rationale here: https://j3s.sh/thought/storing-passwords-with-age.html https://j3s.sh/thought/storing-passwords-with-age.html it boils down to exactly what you noted - disk access is game over in most cases anyways, and i like the convenience of plaintext on the disk. i will be exploring the yubikey model that filippo recently outlined though https://words.filippo.io/dispatches/passage/ https://words.filippo.io/dispatches/passage/ - so stay tuned! :D
- woodruffw 4y agoThanks for sharing your rationale! I tend to agree -- the practical alternative for Linux anyways is some kind of key agent, and it's unclear to me (having written a few password managers at this point, including an age-based one[1]) that the attacker model for an agent is any different. The only advantage is the "public" channel one I mentioned, and that can of course be done out of band. And since I forgot to say it earlier: excellent work! [1]: https://github.com/woodruffw/kbs2 https://github.com/woodruffw/kbs2
- j3s 4y agowow, extremely cool, ty! i'm excited to play with kbs2 when i find a little free time.