4 ms·

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.

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.