5 ms·

JavaScript, and all other crypto code not done with native code is not safe, for a reason not mentioned in this article: side channel attacks. When attempting

by exDM69 14y ago

JavaScript, and all other crypto code not done with native code is not safe, for a reason not mentioned in this article: side channel attacks. When attempting to create crypto code using an interpreter or a byte code virtual machine, additional side channels are created by the differences in the execution compared to executing native code. Crypto code should be written in Assembler or C code where the assembly output is reviewed by the author. This is the only way to create code that does introduce side channel information that can be used with timing attacks, cache attacks, branch predictor attacks, etc. This introduces a problem because it takes a cryptographer and a hardware architecture expert in the team to write safe code for cryptographic primitives. This does not mean you can't safely use crypto from interpreted languages, as long as the cryptographic primitives are good native code.

jakozaur 14y ago
Using the same logic, you need also review CPU and hardware since it may contain backdoors or other intentional insecurities. Even worse, there are allegations it's already happening: http://hexus.net/tech/news/cpu/40037-china-made-us-military-chip-security-backdoor/ http://hexus.net/tech/news/cpu/40037-china-made-us-military-... Of course, changing the interpreter seems to be an order (or two) of magnitude easier than supplying malicious interpreter. However, I would argue that if you are able to replace JavaScript engine you could do same with whole browser, so SSL is also worthless...
deltasquared 14y ago
What is magical about C code, or asm, or microcode that makes it more secure? Everyone has to trust someone. See the Ken Thompson hack: http://c2.com/cgi/wiki?TheKenThompsonHack http://c2.com/cgi/wiki?TheKenThompsonHack
- hedgie 14y ago
  a timing or voltage dependence on the key used for the encryption/decryption is often exploited by side channel attacks. this dependence can be used in some sophisticated attacks to reduce the key space dramatically. c and asm/microcode are close enough to the hardware that the operations let you analyze potential side channel leakage. for instance, if i look at the generated assembly it's possible to reason if the time/voltage used by the decryption operation is a function of the key used in the decryption. when a virtual machine is introduced the just in time compilation itself may introduce these dependencies between timing/voltage and the key used in decryption even if the source code does not appear to. however, unlike in c, you can't just go examine the compiled assembly to ensure a timing attack wasn't added by the compiler. the actual native code becomes a function of the virtual machine installed. the guy above you knows what he's talking about.
trekkin 14y ago
As there can be backdoors and bugs in OSes and hardware, any crypto code done on generic-purpose computers with standard OSes (Windows, OSX, Linux, BSD) is not safe. That does not mean it is useless. The same is true for JS crypto - yes, it is not as safe as crypto in native code, but it can be used to add an additional layer of security in certain (non-critical) use cases. [Disclosure: I run AES.io]
- hedgie 14y ago
  timing attacks don't necessarily need access to the actual machine to work. his point is valid because a side channel timing attack may arise from the differences in time it takes to receive a response from the server. there are remote timing attacks that take advantages in the differences in execution time between paths in the code. this means anyone observing message traffic may be able to execute a side channel attack, instead of just people with access to the hypothetical backdoors you mention. you are saying not safe as if the term has a standard meaning across all contexts. anything can be cracked - the question is whether the time it takes to crack a computer is worth it compared to the data stored on the computer. in almost any case you actually need cryptography and it's not just a nice to have (aka credit cards, personal information) it's not worth using anything but native code.
  - trekkin 14y ago
    > timing attacks don't necessarily need access to the actual machine to work. his point is valid because a timing attack may arise from the differences in time it takes to receive a response from the server. That point of yours actually points to a potential vulnerability in server-side (possibly native-code) encryption, not client-side encryption, which we discuss here. I completely agree with you that anything can be cracked, and JS crypto more so than _some_ native-code cryptosystems. My point is that using JS crypto for some non-critical applications (e.g. as an alternative to corporate IM/email) can be useful and convenient.
    - hedgie 14y ago
      >That point of yours actually points to a potential vulnerability in server-side (possibly native-code) encryption, not client-side encryption, which we discuss here. ...it also relates to the time it takes to generate a response from the client, server was just a specific example. side channel attacks are extremely flexible. the only reasonably secure crypto code is code that executes in the same amount of time no matter the execution path. lastly, if you're using protocols to prevent mitm attacks, you've already reached a level of sophistication where you may as well just throw javascript crypto out and use a real crypto package. if you're not using those protocols the information is basically free and you shouldn't add any crypto because that might mistakenly convince people that they're secure.

by exDM69 14y ago

jakozaur 14y ago

Using the same logic, you need also review CPU and hardware since it may contain backdoors or other intentional insecurities. Even worse, there are allegations it's already happening: http://hexus.net/tech/news/cpu/40037-china-made-us-military-chip-security-backdoor/ http://hexus.net/tech/news/cpu/40037-china-made-us-military-... Of course, changing the interpreter seems to be an order (or two) of magnitude easier than supplying malicious interpreter. However, I would argue that if you are able to replace JavaScript engine you could do same with whole browser, so SSL is also worthless...

deltasquared 14y ago

What is magical about C code, or asm, or microcode that makes it more secure? Everyone has to trust someone. See the Ken Thompson hack: http://c2.com/cgi/wiki?TheKenThompsonHack http://c2.com/cgi/wiki?TheKenThompsonHack

hedgie 14y ago
a timing or voltage dependence on the key used for the encryption/decryption is often exploited by side channel attacks. this dependence can be used in some sophisticated attacks to reduce the key space dramatically. c and asm/microcode are close enough to the hardware that the operations let you analyze potential side channel leakage. for instance, if i look at the generated assembly it's possible to reason if the time/voltage used by the decryption operation is a function of the key used in the decryption. when a virtual machine is introduced the just in time compilation itself may introduce these dependencies between timing/voltage and the key used in decryption even if the source code does not appear to. however, unlike in c, you can't just go examine the compiled assembly to ensure a timing attack wasn't added by the compiler. the actual native code becomes a function of the virtual machine installed. the guy above you knows what he's talking about.

trekkin 14y ago

As there can be backdoors and bugs in OSes and hardware, any crypto code done on generic-purpose computers with standard OSes (Windows, OSX, Linux, BSD) is not safe. That does not mean it is useless. The same is true for JS crypto - yes, it is not as safe as crypto in native code, but it can be used to add an additional layer of security in certain (non-critical) use cases. [Disclosure: I run AES.io]

hedgie 14y ago
timing attacks don't necessarily need access to the actual machine to work. his point is valid because a side channel timing attack may arise from the differences in time it takes to receive a response from the server. there are remote timing attacks that take advantages in the differences in execution time between paths in the code. this means anyone observing message traffic may be able to execute a side channel attack, instead of just people with access to the hypothetical backdoors you mention. you are saying not safe as if the term has a standard meaning across all contexts. anything can be cracked - the question is whether the time it takes to crack a computer is worth it compared to the data stored on the computer. in almost any case you actually need cryptography and it's not just a nice to have (aka credit cards, personal information) it's not worth using anything but native code.
- trekkin 14y ago
  > timing attacks don't necessarily need access to the actual machine to work. his point is valid because a timing attack may arise from the differences in time it takes to receive a response from the server. That point of yours actually points to a potential vulnerability in server-side (possibly native-code) encryption, not client-side encryption, which we discuss here. I completely agree with you that anything can be cracked, and JS crypto more so than _some_ native-code cryptosystems. My point is that using JS crypto for some non-critical applications (e.g. as an alternative to corporate IM/email) can be useful and convenient.
  - hedgie 14y ago
    >That point of yours actually points to a potential vulnerability in server-side (possibly native-code) encryption, not client-side encryption, which we discuss here. ...it also relates to the time it takes to generate a response from the client, server was just a specific example. side channel attacks are extremely flexible. the only reasonably secure crypto code is code that executes in the same amount of time no matter the execution path. lastly, if you're using protocols to prevent mitm attacks, you've already reached a level of sophistication where you may as well just throw javascript crypto out and use a real crypto package. if you're not using those protocols the information is basically free and you shouldn't add any crypto because that might mistakenly convince people that they're secure.