developers already have sjcl.encrypt(‘password’, ‘data’) and sjcl.decrypt(‘password’, ‘encrypted-data’) available, so that part is already done, i think? unless we choose to compete with sjcl, but i don’t think that’s a priority at this point.
i agree, the place to enter the password should be inside the app, for two reasons:
putting it in the widget, next to where people put in their storage address, suggests that people should put their storage password in there, it will be very confusing i think
putting it in the widget suggests that the app has no access to it, and the password is under the control of remotestorage.js. this will not be true though, because an app could easily inspect the DOM
therefore, it is clearer to make it so the user is giving their client-side password to the app, not to the widget.
filenames are not encrypted, you can clearly see where the ‘irc-credentials’ crypto-blob lives on the storage.
sjcl is used as the crypto library.
the user inputs the master password into the app UI, not into the widget.
there are no derived passwords, the master passwords stay in memory until you leave the page.
the module (in this case the ‘irc’ module) dictates which items should be encrypted and which not.
This last design decision means that all apps using the irc module need to also include sjcl.js, and they also need to make the user enter their master password before the credentials can be retrieved. You can’t have a situation where one app encrypts the irc credentials, and the next one doesn’t.
Please discuss! Once we discuss and reach consensus, we can start implementing.
I disagree with this one, because it means that every password input will look different. The widget is optional anyway (at least it should be), so if you don’t use it you have the form in the app. But if you use it, it should be a unified experience for users and a predefined flow and UI for developers in my opinion.
I think that the remoteStorage library should not depend on the implementation details of SJCL or any other encryption library. We should depend on encryption standards instead.
Native WebCrypto (all major browser vendors working on implementing it ATM) will allow to achieve much better security than any pure javascript approach. We should agree what we will use by default and encrypt/decrypt with best available tool on the platform. Right now it can be SJCL for web application, Mozilla NSS for Firefox extensions or WebCrypto in a year or two.
We should also take into account that data can be encrypted now and decrypted now with SJCL and decrypted in several years with WebCrypto.
We can agree that by default we will use AES-CBS-256 or AES-CTR-256 and this defaults will be forced by remoteStorage.{encrypt,decrypt}. I think we should not recommend to user use directly sjcl.{encrypt,decrypt} because SJCL uses own defaults. For example, by default it uses for encryption AES-CCM-128 that aren’t available in current WebCrypto spec Web Cryptography API.
Advanced users can still use SJCL or any other library directly of course. But with this flexibility they will take also all responsibility to support these encoding schemes during application lifetime.
ok, so how can we reach consensus on these two issues? afaics, the option to use WebCrypto is not realistic in the current browser landscape, right? i’m hesitant to try to roll our own crypto lib, i would rather rely on something that comes from Stanford and is generally considered the leading go-to option at current state of the art.
as for adding a password UI to the widget, i think that’s a non-urgent enhancement, but i can see how it would be nice to have. maybe we can do “vote by doing” on that one? the people who want to have it can be the people who build it. is that reasonable?
Nobody said anything else here. I’m not sure you’ve read the last post carefully enough. It raises very good points about using common defaults in our own library and using SJCL as a shim (which could be the only option for now).
Let’s just prefix the cyphertext with ‘AES-CCM-128:’, that way we are prepared for switching to another cypher if we ever need/want to remove AES-CCM-128 support.
CCM, GCM and OCB2 are all authenticated encryption modes, CBS and CTR are unauthenticated encryption modes.
SJCL is high-level library and it promotes to use most secure authenticated encryption modes, WebCrypto instead is low-level library and provides low-level primitives which you can use to for authenticated encryption.
ATM WebCrypto mention only one authenticated encryption mode GCM, that also support SJCL AFAIK. So from the portability point of view is better to use AES-128 in GCM mode as default symmetric encryption method IMO.
Please note, WebCrypto API isn’t finished yet and list of supported algorithms may change in nearest 2 month.
Flock implemented a per-file encryption mechanism on top of webdav. I think its key exchange mechanism (if not more) would be a perfect fit for remoteStorage.
I’ve come across multiple benchmarks that put Forge significantly ahead of sjcl in terms of encryption and hashing performance. This one, for instance, puts Forge at roughly an order for magnitude faster. It’s rather dated, and there are some curious differences in the encryption modes used between the different libraries, but I think this means maybe we should do some more benchmarking before blindly defaulting to sjcl.
I also happen to prefer Forge’s documentation, as every function comes with multiple examples on how they can be used, compared to sjcl’s which is rather barebones.
