4 ms·

Shameless plug: SJCL is a great library and easy to work with. I've used it to build a non-profit decentralized encryption tool that can be used to send and re

by colept 10y ago

Shameless plug: SJCL is a great library and easy to work with. I've used it to build a non-profit decentralized encryption tool that can be used to send and receive files that will self-decrypt using SJCL, JavaScript FileReader, and HTML5 download attributes. User A creates a password to encrypt a file using this client-side mechanism - which produces a self-decrypting HTML file. User B opens this HTML file in their browser which will ask them for the password to decrypt the file allowing them to download the original file all without a server. The homepage can be downloaded and self-hosted at will. https://zipit.io/ https://zipit.io/ edit: I have uploaded it to Github today for easy self-hosting: https://github.com/colepatrickturner/zipit https://github.com/colepatrickturner/zipit

a_w 10y ago
How does User B obtain the password to decrypt the file? How does the key distribution part work?
- colept 10y ago
  It's a plaintext password - not nearly as secure as PGP or the like.
  - StavrosK 10y ago
    There's no "non-plaintext password", encryption keys are encryption keys. I don't know if SJCL includes asymmetric crypto, but there's nothing wrong with AES.
    - tptacek 10y ago
      SJCL includes public-key crypto, and its defaults include an iterated KDF for password-based encryption, and CCM with random IVs. It's one of the better crypto interfaces (though, again, it's hamstrung when it's run inside a browser).
      - StavrosK 10y ago
        Ah, thanks. Last I used it, I only needed the symmetric part, so I couldn't remember whether it had an asymmetric part as well. It is a very good library indeed, and was (at least partly) written by Dan Boneh, whom I regard highly.
        tptacek 10y ago
        "bitwiseleftshift" is Mike Hamburg. :)
        StavrosK 10y ago
        I was just wondering that! Half the contributors on the Github repo have the default avatars and barely any info on their profiles, so I couldn't figure out who was who.
e12e 10y ago
So, decryption prior to authentication of the executable/ciphertext? So it's more likely to be user A encrypts M with K producing C, uploads to server, where E(ve) swaps out C for C' that records the password B types in and sends it to E - C' then claims "an error occurred, please reload the page/app" and then submits C'', a message M' chosen by Eve encrypted with K? And since C' and C'' are delivered as (js) executables - Eve can choose what to do - try for a compromise when B runs C', show the original message but run additional code for C'' ... ?
- ruleabidinguser 10y ago
  When you put it that way im not sure I understand it anymore lol
  - blablabla123 10y ago
    I think C is the code and C'(') is some evil attack code. Several blog posts about JS crypto mention that given all the past attacks on TLS, it's not unlikely that someone can perform a Man-in-the-middle attack to swap out code.
    - e12e 10y ago
      C "executable" cipher text that is (presumably) made by prepending a js decryptor (executable code) to encrypt(M,K) - ie: C=make_executable_js(encrypt(M,K)). C' could be anything (B only sees a minfied blob of js) - but at the very least is likely to be runnable js code. In the simplest case, it's simply a modified message M', encrypted with K and prepended with the (presumably) benign decryption code -- the change now being that when A wrote ("HI MOM, PLZ SEND MONEY TO ACCOUNT #121"), M' reads similar except for the account number (etc, etc). The main difference (apart from implementation details of encryption and so forth under a js runtime) from Gnu Privacy Guard - is that one can/should/would get a trusted gpg binary that should be safe(ish) to run on potentially untrusted ciphertext. Note that in the example above, Eve doesn't start out knowing the Key, K -- but as B runs any random js-code found at the "drop" point, Eve might be able to use said code to obtiain K (B types it in and allows untrusted code to handle the secret). Contrast with getting a cd-rom from a trusted source with an OS and gpg on it - feeding gpg some reandom cipher text C' that Eve created, barring gpg bugs, a) doesn't give Eve access to K, and b) doesn't trick B into reading some bogus message M', different from the message A wanted to send in the first place. In short - it would make more sense to distribute the decryptor js-script in a public but trusted manner - and then run the decryptor on the cipher text that could then be obtained in a different manner. What an executable self-decrypting file (weather .exe or .js file) might be good for, is if A hands it to B on a USB key or transfer the encrypted archive in some trusted manner - the data would then be "safe" until B sits down and types in K. How useful this actually is, is up for debate. All that said - I think it's great fun to make little tools like this, but we should be a careful about teaching people (even for fun) to run random code - be that js or other code.

by colept 10y ago

a_w 10y ago

How does User B obtain the password to decrypt the file? How does the key distribution part work?

colept 10y ago
It's a plaintext password - not nearly as secure as PGP or the like.
- StavrosK 10y ago
  There's no "non-plaintext password", encryption keys are encryption keys. I don't know if SJCL includes asymmetric crypto, but there's nothing wrong with AES.
  - tptacek 10y ago
    SJCL includes public-key crypto, and its defaults include an iterated KDF for password-based encryption, and CCM with random IVs. It's one of the better crypto interfaces (though, again, it's hamstrung when it's run inside a browser).
    - StavrosK 10y ago
      Ah, thanks. Last I used it, I only needed the symmetric part, so I couldn't remember whether it had an asymmetric part as well. It is a very good library indeed, and was (at least partly) written by Dan Boneh, whom I regard highly.
      - tptacek 10y ago
        "bitwiseleftshift" is Mike Hamburg. :)
        StavrosK 10y ago
        I was just wondering that! Half the contributors on the Github repo have the default avatars and barely any info on their profiles, so I couldn't figure out who was who.

e12e 10y ago

So, decryption prior to authentication of the executable/ciphertext? So it's more likely to be user A encrypts M with K producing C, uploads to server, where E(ve) swaps out C for C' that records the password B types in and sends it to E - C' then claims "an error occurred, please reload the page/app" and then submits C'', a message M' chosen by Eve encrypted with K? And since C' and C'' are delivered as (js) executables - Eve can choose what to do - try for a compromise when B runs C', show the original message but run additional code for C'' ... ?

ruleabidinguser 10y ago
When you put it that way im not sure I understand it anymore lol
- blablabla123 10y ago
  I think C is the code and C'(') is some evil attack code. Several blog posts about JS crypto mention that given all the past attacks on TLS, it's not unlikely that someone can perform a Man-in-the-middle attack to swap out code.
  - e12e 10y ago
    C "executable" cipher text that is (presumably) made by prepending a js decryptor (executable code) to encrypt(M,K) - ie: C=make_executable_js(encrypt(M,K)). C' could be anything (B only sees a minfied blob of js) - but at the very least is likely to be runnable js code. In the simplest case, it's simply a modified message M', encrypted with K and prepended with the (presumably) benign decryption code -- the change now being that when A wrote ("HI MOM, PLZ SEND MONEY TO ACCOUNT #121"), M' reads similar except for the account number (etc, etc). The main difference (apart from implementation details of encryption and so forth under a js runtime) from Gnu Privacy Guard - is that one can/should/would get a trusted gpg binary that should be safe(ish) to run on potentially untrusted ciphertext. Note that in the example above, Eve doesn't start out knowing the Key, K -- but as B runs any random js-code found at the "drop" point, Eve might be able to use said code to obtiain K (B types it in and allows untrusted code to handle the secret). Contrast with getting a cd-rom from a trusted source with an OS and gpg on it - feeding gpg some reandom cipher text C' that Eve created, barring gpg bugs, a) doesn't give Eve access to K, and b) doesn't trick B into reading some bogus message M', different from the message A wanted to send in the first place. In short - it would make more sense to distribute the decryptor js-script in a public but trusted manner - and then run the decryptor on the cipher text that could then be obtained in a different manner. What an executable self-decrypting file (weather .exe or .js file) might be good for, is if A hands it to B on a USB key or transfer the encrypted archive in some trusted manner - the data would then be "safe" until B sits down and types in K. How useful this actually is, is up for debate. All that said - I think it's great fun to make little tools like this, but we should be a careful about teaching people (even for fun) to run random code - be that js or other code.