sjcl icon indicating copy to clipboard operation
sjcl copied to clipboard

The SJCL demo - A new user-friendly version

Open AlchemyUnited opened this issue 9 years ago • 4 comments

For anyone who might be interested in a more user-friendly version of the demo

https://github.com/ezWebDevTools/ezCryptoJS

IMPORTANT

I'm not a "crypto guy" but I presume my cosmetic (read: UI & UX) changes don't compromise the integrity of the original demo. That said, feedback, pull requests, etc. are welcomed.

Thx.

AlchemyUnited avatar Dec 22 '15 15:12 AlchemyUnited

Glad to stumble across SJCL, and then see this enhanced webgui pop up to demo. Nice work and thank you for sharing. One suggestion I had is, a way to turn the generated ciphertext into a weblink that someone could more easily share, that when clicked will pull up the site with the ciphertext entered, so that only the password is required to decrypt again at the push of a button? I am trying to accomplish this over the weekend, and if lucky (I'm a hardware, not software guy) I will share.

ps. SJCL and your work made me sign-up today - a github newb is born!

djcabrera avatar Dec 31 '15 22:12 djcabrera

hey @djcabrera -

i like your ideas. Keep in mind there are security "rules" that the browser enforces to prevent JavaScript from doing nefarious things to your local files and such. There is also a limit to the # of characters in a URL. In theory it would be possible to turn the JSON object into a URL.

For example (in pseudo code)

{ arg1 : value1, arg2 :value 2, }

could become

...?arg1=value1&arg2=value2...

You could take that, reconstruct the JSON object and put it in the cypher text textarea.

The issues I see off the top of my head...

  1. That could generate a string that's too long for a legit URL

  2. That URL could end up in your browser history - regardless of being encrypted - might not be something you want.

Again. I like your idea. I too amy trying to reduce the # of step in my workflow when using ezCrypoJS (which is one of the reasons I add the file select, as well as the drag & drop). I'm just not to sure the benefits outweigh the risk.

Your thoughts?

AlchemyUnited avatar Jan 01 '16 14:01 AlchemyUnited

Interesting, good point re. legit URL string, which would probably be limited after 2,000 characters or so.

My goal is to provide a local 501c3 org the ability to send/receive secure blobs of text using an open solution. They use Google Apps for non-profit, and the only solution they offer is an expensive commercial product.

If a user must simply visit the encryption/decryption page and copy/paste away to send/receive secure messages, that's not such a barrier to entry. I'll be keeping an eye on this project. Thank you so much for your reply and hard work.

djcabrera avatar Jan 07 '16 01:01 djcabrera

{...thinking out loud...}

  1. I'm not sure when you last looked but last week-ish I added a second save button. There's now save and JSON and save as .txt (text.) There's no difference in the contents. A .txt just seemed a bit more discrete.

That said, it might be possible to do a save and attach to email. My sense is, that's probably a security issue. That is, you're not gonna be able to attach automatically.

Would that help? If so, let me know and if I get a moment I can look into it.

  1. Another option might be to use Google Drive (or similar) to share the file. That is, the "sending" is dong via the share feature.

For example, let's say I have a Google Drive on my local machine. I have a crypto file in a folder within that drive, and that folder is shared with you. I can see. You can see it. If I make a change, you'll get that "copy." If you make a change, I'll get that "copy." The only catch is, we have to both use the same PW / cyrpto-settings.

The other issue is, reloading an updated version of the file in my browser once you've updated it. That is, I don't want to overwrite your updates because I had an old version of the file open in ezCryptoJS. Again, I'd have to look into this.

  1. Perhaps I need to add a "Save and Clear" check box? That is, once you save, the form clears and you'd have to reopen that file. The reopen / start from scratch would force you to get the new / latest version of the file, and not use the stuff in the textarea to overwrite the old file. Am I making sense?

  2. Is there a compliance issue? That is, do you have to save older version of the messages? Or is this just a simple note-passing process?

AlchemyUnited avatar Jan 07 '16 14:01 AlchemyUnited