7 ms·

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

by 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.
- demallien 14y ago
  As someone that has spent the better part of the last 18 months getting animations as smooth as possible in Javascript, I will happily buy a beer for anyone trying to execute a time-based side-channel attack against Javascript. You'll need the beer to cry into when the garbage collector craps all over your assumptions of constant durations for code path execution...
  - trekkin 14y ago
    Exactly - interpreted code is harder to do timing attacks against because interpreters add a lot of timing "noise", while native code is much more consistent re: time taken to execute a specific routine.
    - hedgie 14y ago
      a timing attack doesn't require constant duration for execution paths in the code. even with the noise in server communications remote timing attacks are often feasible - the noise filters out when you up the number of measurements or use the statistical techniques most modern side channel attacks rely on. remote timing attacks contain noise by default, as they rely on server communications passed across a network with latency instead of examining the hardware directly to determine execution time. if you compare the network latency to the cache timing you'll find the noise is actually pretty fucking substantial. a timing attack relies on a average difference in execution time between two paths of code. certain noise isn't going to protect you - for example, if everything on average takes 200ms longer, the average difference in execution time is still there.
      - trekkin 14y ago
        I'm not saying timing attacks against interpreted code are impossible. I'm just saying they are easier to execute against native code, and thus have nothing to do with JS crypto being less secure than native crypto.
        hedgie 14y ago

by trekkin 14y ago

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.
demallien 14y ago
As someone that has spent the better part of the last 18 months getting animations as smooth as possible in Javascript, I will happily buy a beer for anyone trying to execute a time-based side-channel attack against Javascript. You'll need the beer to cry into when the garbage collector craps all over your assumptions of constant durations for code path execution...
- trekkin 14y ago
  Exactly - interpreted code is harder to do timing attacks against because interpreters add a lot of timing "noise", while native code is much more consistent re: time taken to execute a specific routine.
  - hedgie 14y ago
    a timing attack doesn't require constant duration for execution paths in the code. even with the noise in server communications remote timing attacks are often feasible - the noise filters out when you up the number of measurements or use the statistical techniques most modern side channel attacks rely on. remote timing attacks contain noise by default, as they rely on server communications passed across a network with latency instead of examining the hardware directly to determine execution time. if you compare the network latency to the cache timing you'll find the noise is actually pretty fucking substantial. a timing attack relies on a average difference in execution time between two paths of code. certain noise isn't going to protect you - for example, if everything on average takes 200ms longer, the average difference in execution time is still there.
    - trekkin 14y ago
      I'm not saying timing attacks against interpreted code are impossible. I'm just saying they are easier to execute against native code, and thus have nothing to do with JS crypto being less secure than native crypto.
      - hedgie 14y ago