4 ms·
In part it depends on the strength (and secure transmission of your passphrase (though if you have a good way of transmitting the passphrase this becomes less u
by sleepychu 9y ago
In part it depends on the strength (and secure transmission of your passphrase (though if you have a good way of transmitting the passphrase this becomes less useful))
The encryption itself is solid (assuming it is implemented correctly and as described, I've not inspected the code) but as mentioned a short pass phrase combined with predictable plain text format would make this quite easy to brute force.
- falcolas 9y agoThe pass phrase also can't be changed, without reencryping the entire page. Once leaked, the contents are effectively publicly available. Also, you can't revoke access (again, without site-wide re-encryption). An interesting POC, but not something that is really practical for broader use.
- sleepychu 9y agoI considered both these points when I was composing my answer but came to the conclusion that this is true for basically any encryption strategy, if I've transmitted contents signed with your public key then when your private key becomes known so does the contents. Even when you manage to keep the key secret I can't revoke your access to the material or prevent you re-transmitting it to others.
- falcolas 9y agoTrue, but if there's one shared key for each page, the chances of that key getting loose are higher. There are alsomethods of encrypting a message where you can specify multiple recipients (i.e. multiple keys), letting you remove one key without affecting the viewership of the page for people with the other keys. It's a hard problem, and this is certainly a novel solution to that problem, but I still don't really see myself using it.
- plaguuuuuu 9y agoyou could just do the encryption on the server side, in which case you just change the key and done. /s