Closed ignaloidas closed 1 year ago
Hi Ignas!
First of all, thank you for vetting the security of the plugin! I really appreciate your work.
I understand your concern, and I anticipated this attack vector by salting the key passphrase with the UNIX time:
The reason I implemented a deterministic key generator is for encrypting file attachments, a feature that I'm still working on.
But I agree with you that Crypto.getRandomValues is cryptographically more secure for this key and I'll make this an issue to change it.
I understand your concern, and I anticipated this attack vector by salting the key passphrase with the UNIX time:
Sadly this is not enough. An attacker can locally brute force through all the possible time values of a year in about 6 days with a single 3090, faster with more resources. Could probably be optimized even further, to simply search +- 5 minutes for each note upload time if we're talking about the attacker having access to the database, which depending on how often the notes show up, could reduce the attack to a day or so.
I understand your concern, and I anticipated this attack vector by salting the key passphrase with the UNIX time:
Sadly this is not enough. An attacker can locally brute force through all the possible time values of a year in about 6 days with a single 3090, faster with more resources. Could probably be optimized even further, to simply search +- 5 minutes for each note upload time if we're talking about the attacker having access to the database, which depending on how often the notes show up, could reduce the attack to a day or so.
I see, thanks for letting me know. I will fix this ASAP.
Shipped in version 1.0.1 🚀
Thanks!
Generating keys purely from note content make the keys stable for specific content. Actors can verify if some note they got without any identifying information comes from. While attacks from external actors would be difficult because note IDs aren't easily enumerable, whoever runs the storage service can easily check whether there is a note with specific content in the system, and which user uploaded it (since uploads are logged with an user ID). As far as I understand the security model obsidian-quickshare is intended to satisfy, this is a security issue.
Fix would be to use a secure random generator to generate the key, like
Crypto.getRandomValues