I know these sorts of questions come up, but I couldn't find a simple answer, most of the answers are don't do thatFor play, I built myself a webapp, it uses sjcl to encrypt and decrypt notes on the client, whilst sending the encrypted form back to the server.I am storing the key in local storage.From my research, I am at risk from:Cross site scripting attacks (my application uses AJAX to send and receive the data from the server, I'm not sure if that is an attack vector).Local machine being hacked. At the moment the app can only be used on machines I have full control over, the moment I log in from a machine I do not control and type my key, that machine essentially has my key.Any type of flaw in local storage that lets a site from a different domain read the storage of other websites stored in the browser.I am sure I have missed countless other attack vectors.At first glance, I feel like it's impossible to design a client side encrypted note taking application that never sends the key to the server. With programming, there is almost always a way.Is there a way I can make the app actually usable?
How to implement simple secure client side encryption
encryption;local storage
Basically, if the key is safe, the data is safe too (provided that its a good encryption algorithm and the key long enough, which I take as granted).If I understood right, you only send encrypted data over the wire, not the key itself. If it's not the case, please discard this whole answer.Assuming the key is never sent over the wire, the only way to compromise the data is to discover the key. This could happen if:How the key is generated is predictibleSomebody having access to the fileA virus on the PCDNS spoofing attacks (claiming to be your host/domain) -> Use TLS and certificates (see http://dev.w3.org/html5/webstorage/#privacy)Exploiting a bug in some exotic browser/version (dunno if this already happenned, and if there are some vulnerability alerts or such)...is there anything else?...perfect security is hard to achieve. But in your case, it seems an attacker must go to great length in order to hack it, or the user have a compromised machine from the start. Usually, the bottleneck is the user itself. ;)