4 ms·

Random number generator problem is solved in Chrome: var x = new Uint8Array(10); window.crypto.getRandomValues(x); console.log(x); It's also supp

by rorrr 14y ago

Random number generator problem is solved in Chrome: var x = new Uint8Array(10); window.crypto.getRandomValues(x); console.log(x); It's also supposed to work in FF, but for some reason doesn't: https://developer.mozilla.org/en-US/docs/DOM/window.crypto https://developer.mozilla.org/en-US/docs/DOM/window.crypto

ema 14y ago
You also have to ensure that "window.crypto.getRandomValues = function(y) {};" wasn't executed earlier.
- Drakim 14y ago
  Hmmm, interesting. I think you can check if a function is native or not by casting the function to a string, and I don't think there are any native functions the attacker would stand to gain anything by swapping.
  - ema 14y ago
    > I think you can check if a function is native or not by casting the function to a string you can swap the toString method too.
    - visarga 14y ago
      That's just nasty!
- csuwldcat 14y ago
  There are a multitude of natively available browser functions that are immutable and cannot be CRUD'd. This guy really needs to understand more about the browser. His commentary on client storage in the browser also is myopic.
jvdongen 14y ago
And how are you going to be sure that 'window.crypto.getRandomValues' points to the function you expect? Currently you can't be.
- UnoriginalGuy 14y ago
  What does this have to do with what he said? He addressed one problem and then you bash him over the head with a completely different one.
  - jvdongen 14y ago
    My point is relevant as he considered the problem of availability of a CSPRNG 'solved' - and it isn't until you also solve most of the other problems Thomas identifies. And it was not my intention to 'bash' anyone - if it came across as such I apologize.
- makomk 14y ago
  Technically you can't be sure that when you open() /dev/random in a native C application that it's actually opening /dev/random either. Yes, really.
  - jvdongen 14y ago
    You're technically correct - it's all a matter of degrees of certainty. That does however not invalidate any of the points made in the article. If that native C application runs on a server that is fully under your control you stand a far, far better chance then when that native C application (say a web browser) runs on some computer not under your control. Especially if that native C application is explicitly written to accept run-time addition of random third-party code (aka browser extensions).
- jQueryIsAwesome 14y ago
  Yes you can be sure; using an iframe + innerHTML because the later one is not a function and can't point at one or can be defined any other way and the same goes for its parent objects. document.body.innerHTML += "<iframe></iframe>"; document.body.childNodes[document.body.childNodes.length-1].contentWindow.crypto.getRandomValues; And please don't talk about how the JS engione of the browser can be compromised too; I know that but here we are aiming for practical applications not a philosophical debate about how everything is just an illusion.

by rorrr 14y ago

ema 14y ago

You also have to ensure that "window.crypto.getRandomValues = function(y) {};" wasn't executed earlier.

Drakim 14y ago
Hmmm, interesting. I think you can check if a function is native or not by casting the function to a string, and I don't think there are any native functions the attacker would stand to gain anything by swapping.
- ema 14y ago
  > I think you can check if a function is native or not by casting the function to a string you can swap the toString method too.
  - visarga 14y ago
    That's just nasty!
csuwldcat 14y ago
There are a multitude of natively available browser functions that are immutable and cannot be CRUD'd. This guy really needs to understand more about the browser. His commentary on client storage in the browser also is myopic.

jvdongen 14y ago

And how are you going to be sure that 'window.crypto.getRandomValues' points to the function you expect? Currently you can't be.

UnoriginalGuy 14y ago
What does this have to do with what he said? He addressed one problem and then you bash him over the head with a completely different one.
- jvdongen 14y ago
  My point is relevant as he considered the problem of availability of a CSPRNG 'solved' - and it isn't until you also solve most of the other problems Thomas identifies. And it was not my intention to 'bash' anyone - if it came across as such I apologize.
makomk 14y ago
Technically you can't be sure that when you open() /dev/random in a native C application that it's actually opening /dev/random either. Yes, really.
- jvdongen 14y ago
  You're technically correct - it's all a matter of degrees of certainty. That does however not invalidate any of the points made in the article. If that native C application runs on a server that is fully under your control you stand a far, far better chance then when that native C application (say a web browser) runs on some computer not under your control. Especially if that native C application is explicitly written to accept run-time addition of random third-party code (aka browser extensions).
jQueryIsAwesome 14y ago
Yes you can be sure; using an iframe + innerHTML because the later one is not a function and can't point at one or can be defined any other way and the same goes for its parent objects. document.body.innerHTML += "<iframe></iframe>"; document.body.childNodes[document.body.childNodes.length-1].contentWindow.crypto.getRandomValues; And please don't talk about how the JS engione of the browser can be compromised too; I know that but here we are aiming for practical applications not a philosophical debate about how everything is just an illusion.