you can see how the keys are generated under the 'pgp' tab on your user page.
both the privkey and pubkey are stored in the datbase, but the privkey will be stored in a password protected form, so don't choose a weak password or the NSA will be reaDing all of your messages if the datacenter hosting ieddit's servers get raided.
i had some performance issues initially with the standard key generation algorithm, but after I switched to ECC the performance seems decent, even on mobile
EDIT: i'll probably use a client-side generated mnemonic instead of user passphrases (shoutouts to /u/mnemonic or w/e ur name is)
the most serious risk assuming i implement this correctly is the pgp javascript being modified by an adversary with access to the server, or a xss vulnerability.
not sure what i can really do about this. if an adversary compromises the server, they can also modify any file/page integrity checks.
i could setup a deadman switch or similar that throws a warning if i don't check in with a pgp signed message every x days... but that still leaves a large amount of time for users to be potentially compromised. not to mention it relies on my key not being compromised by this adversary.
a warrant canary has the same issue.
at the end of the day, this is good enough security. if your threat model includes the us federal government as an adversary, i recommend continuing to roll your own pgp.
i can also set optional expiration times on messages, but even that only adds to the good enough security.
the main assurances this provides is it ensures that, under normal site operation (assuming an adversary does not compromise the servers directly and modify them, or finds a vulnerability, and that I also do not try anything sneaky), your messages will not be able to be read even by me.
as you can probably tell my understanding of async js is... not the best, but the additional performance overhead caused by my poor code should basically be non-existent
Keep in mind, the library I'm using, and how I'll be using it, is the same shit protonmail utilizes.
If I'm understanding how the library works, privkeys created with a passphrase will not even be usuable without that passphrase. No hashing required. In which case, I could even store the entire privkey without concern.
I'm not 100% sure on that, but this is the impression I have gotten so far when reading the openpgpjs documentation.
yeah after playing around with it, the ui experience of having to re-enter keys is horrible.
since the security is already only 'good enough', i might as well just store the passphrase after being entered in localstorage... i hate this but idk what else to do
with an option to toggle it, and warning users of the compromise that has been made for ui.
anybody who wants anything more secure will just have to roll their own pgp.
both the privkey and pubkey are stored in the datbase, but the privkey will be stored in a password protected form, so don't choose a weak password or the NSA will be reaDing all of your messages if the datacenter hosting ieddit's servers get raided.
i had some performance issues initially with the standard key generation algorithm, but after I switched to ECC the performance seems decent, even on mobile
EDIT: i'll probably use a client-side generated mnemonic instead of user passphrases (shoutouts to /u/mnemonic or w/e ur name is)
the most serious risk assuming i implement this correctly is the pgp javascript being modified by an adversary with access to the server, or a xss vulnerability.
not sure what i can really do about this. if an adversary compromises the server, they can also modify any file/page integrity checks.
i could setup a deadman switch or similar that throws a warning if i don't check in with a pgp signed message every x days... but that still leaves a large amount of time for users to be potentially compromised. not to mention it relies on my key not being compromised by this adversary.
a warrant canary has the same issue.
at the end of the day, this is good enough security. if your threat model includes the us federal government as an adversary, i recommend continuing to roll your own pgp.
i can also set optional expiration times on messages, but even that only adds to the good enough security.
the main assurances this provides is it ensures that, under normal site operation (assuming an adversary does not compromise the servers directly and modify them, or finds a vulnerability, and that I also do not try anything sneaky), your messages will not be able to be read even by me.
you can find the current generation code here https://github.com/cc-d/ieddit/blob/master/static/pgp.js
as you can probably tell my understanding of async js is... not the best, but the additional performance overhead caused by my poor code should basically be non-existent