3 ms·

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(

by 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.
colept 10y ago
As with anything - the result is only as secure as transmission and execution - so isolation is the only guarantee. If you're truly paranoid - run without network connectivity and transmit through physical media. That being said, this was a fun project that demonstrates encryption at the lowest common denominator - versus the complexities of setting up PGP for email. This is something my grandmother still using AOL could use.
- e12e 10y ago
  Right, please don't take the above as critique of writing up a project like this - it's a fun thing to do. But even if your grandmother could use this, she wouldn't be able to use in any meaningful way in order to increase security around secret messages. The only case in which such a project (or an equivalent one that generated a self-decrypting executable that asked for a password, or something like[1]) - is that if the file received isn't a trojan, the data in the file remains secure until decrypted for the first time. But as there's no way to know the file isn't a trojan, unless it's been transmitted via secure channel, it doesn't really add any security. [1] I could see this working for a shell-script and a here-document using gpg: #!/usr/bin/env bash # this is makemsg.sh cat > msg.sh <<eof #!/usr/bin/evn bash # this is msg.sh gpg --decrypt <<eof eof echo "You will now be prompted for a passphrase." echo "After entering the passphrase, typer your" echo "message. End with end-of-file (ctrl-d)" gpg --symmetric --armor >> msg.sh echo eof >> msg.sh echo "Encrypted message msg.sh created" echo " - run msg.sh to read message" Note that msg.sh is rather easy to audit: #!/usr/bin/evn bash # this is msg.sh gpg --decrypt <<eof -----BEGIN PGP MESSAGE----- Version: GnuPG v1 jA0EAwMCtkFEXeN2ydJgyT94WmGBkuSM9wFomkopr6BAfnucTv3kyU/w+Ni54PZi rOdvVl7WUdvt7wZ/Pq64ycM6uqWFp5kXRvw4zCRSKeU= =Jq6V -----END PGP MESSAGE----- eof (Note that I've avoided indenting lines of cipher text to avoid breaking the layout).
  - e12e 10y ago
    Obviously, "msg.sh" is only "easy" to use on something like a Ubuntu/Linux desktop that comes with (ba)sh and gpg -- and it's only "easy to audit" for technical users. It's still easy enough to swap out the contents of "msg.sh" with something nefarious that sends the contents of ~/Maildir to a remote server or whatever. The point being, if the user can't trust the framework (in this case, operating system, shell and gpg executable) there can be no trust in the handling of data either. But blindly running code (be that a shell-script or javascript code) is generally a bad idea...

by e12e 10y ago

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.

colept 10y ago

As with anything - the result is only as secure as transmission and execution - so isolation is the only guarantee. If you're truly paranoid - run without network connectivity and transmit through physical media. That being said, this was a fun project that demonstrates encryption at the lowest common denominator - versus the complexities of setting up PGP for email. This is something my grandmother still using AOL could use.

e12e 10y ago
Right, please don't take the above as critique of writing up a project like this - it's a fun thing to do. But even if your grandmother could use this, she wouldn't be able to use in any meaningful way in order to increase security around secret messages. The only case in which such a project (or an equivalent one that generated a self-decrypting executable that asked for a password, or something like[1]) - is that if the file received isn't a trojan, the data in the file remains secure until decrypted for the first time. But as there's no way to know the file isn't a trojan, unless it's been transmitted via secure channel, it doesn't really add any security. [1] I could see this working for a shell-script and a here-document using gpg: #!/usr/bin/env bash # this is makemsg.sh cat > msg.sh <<eof #!/usr/bin/evn bash # this is msg.sh gpg --decrypt <<eof eof echo "You will now be prompted for a passphrase." echo "After entering the passphrase, typer your" echo "message. End with end-of-file (ctrl-d)" gpg --symmetric --armor >> msg.sh echo eof >> msg.sh echo "Encrypted message msg.sh created" echo " - run msg.sh to read message" Note that msg.sh is rather easy to audit: #!/usr/bin/evn bash # this is msg.sh gpg --decrypt <<eof -----BEGIN PGP MESSAGE----- Version: GnuPG v1 jA0EAwMCtkFEXeN2ydJgyT94WmGBkuSM9wFomkopr6BAfnucTv3kyU/w+Ni54PZi rOdvVl7WUdvt7wZ/Pq64ycM6uqWFp5kXRvw4zCRSKeU= =Jq6V -----END PGP MESSAGE----- eof (Note that I've avoided indenting lines of cipher text to avoid breaking the layout).
- e12e 10y ago
  Obviously, "msg.sh" is only "easy" to use on something like a Ubuntu/Linux desktop that comes with (ba)sh and gpg -- and it's only "easy to audit" for technical users. It's still easy enough to swap out the contents of "msg.sh" with something nefarious that sends the contents of ~/Maildir to a remote server or whatever. The point being, if the user can't trust the framework (in this case, operating system, shell and gpg executable) there can be no trust in the handling of data either. But blindly running code (be that a shell-script or javascript code) is generally a bad idea...