6 ms·

I would still say it's a bug from the Bitcoin community to rely on one generator rather than XORing a few just in case. And I'm saying that as a prominent Bitc

I would still say it's a bug from the Bitcoin community to rely on one generator rather than XORing a few just in case. And I'm saying that as a prominent Bitcoin user and not-so-prominent developer. We undervalue redundancy.

x1024 13y ago
XORing random streams doesn't have as much value as you think.
- deleted 13y ago
  [deleted]
patio11 13y ago
That would be a very, very bad decision. As one possible implementation flaw, consider what happens where Generator A is /dev/urandom and Generator B is SecureRandom whose platform implementor has decided to implement their own pseudorandom number generation algorithm in cases where they're sure they have enough entropy but, if they aren't, they fallback to /dev/urandom. That will pass all tests and work fine for all purposes right until hilarity ensues in whatever real world circumstances deplete the entropy pool. Note that after attackers realize that depleting the entropy pool is a victory condition, they can actively work to cause that.
- marshray 13y ago
  Generator A returns 32 bytes from /dev/urandom. Generator B returns 32 bytes from /dev/urandom. The application XORs them. What's the problem?
  - ig1 13y ago
    If you're XOR multiple generators then if an attacker can zero out the other generators (i.e. draining the pool) they can reduce your security to the weakest generators you're using. If both generators have the same underlying source then they're also likely to share any security vulnerability so XORing them is unlikely to improve the randomness and can introduce potential weaknesses.
    - marshray 13y ago
      I see. OK. Well if you let an attacker zero out your random number generators, you're screwed. You'd better not let that happen. This 'decrement pool entropy estimate and stop returning numbers' idea is the longest running mistake in crypto.
      - tptacek 13y ago
        YES.
    - ars 13y ago
      > they can reduce your security to the weakest generators you're using. > and can introduce potential weaknesses. This isn't true. XORing numbers can never decrease entropy. It can only increase it. So your security would stay at the strongest generator, plus some extra entropy from the weaker ones.
      - patio11 13y ago
        XORing numbers can never decrease entropy. It can only increase it. Let Generator A(x) equal "For any x, a perfect random number picked by the hand of God Almighty." Let Generator B equal "For any x, A(x+1) unless 'ars is asking in which case A(x)". If ars chooses Generator A, ars is fine. If ars chooses Generator B, ars is fine. If ars chooses Generator C = A(x) ^ B(x), ars will very quickly see that ars' intuitions about math are in some circumstances incorrect. Ars might then think "Phew, good thing they weren't subtly correlated, or it would have looked great right until it didn't."
        marshray 13y ago
        Reading from /dev/urandom twice does not yield the same result, or even results subtly correlated under XOR.
        ars 13y ago
        If your second generator has an output that is a function of the first then it's not a cryptographic RNG in the first place and then Generator B is NOT fine. (Alternatively it could mean that you can only generator a single cryptographic random number, since all the rest are just functions of the previous one, and then again you are not fine. Either way Generator B is not fine.) And in any case neither A nor B is a generator - only x is. Neither A nor B are adding any entropy whatsoever.
  - StavrosK 13y ago
    A XOR A = 0
    - marshray 13y ago
      If your /dev/urandom returns the same sequence of 32 bytes twice in a row, you have something truly pathological going on.
      - StavrosK 13y ago
        In the above example, you're XORing urandom with itself.
        marshray 13y ago
        Run this a bunch of times: dd if=/dev/urandom bs=32 count=1 | xxd Substitute 'base64' if you don't have 'xxd'. If you get the same output twice, see a doctor.
        DanBC 13y ago
        Why XOR urandom with itself? You don't gain anything, and if your random numbers are correlated with something you're making it worse. I guess it makes testing easier. Correlations will be easier to see.
        marshray 13y ago
        People were saying 'urandom XOR urandom' was a pathological failure mode. My point is that it's not going to return the same results twice.
        DanBC 13y ago
        ...but you understand that it doesn't matter that it's not returning the same results twice, and that it's still a fail, right?

x1024 13y ago

XORing random streams doesn't have as much value as you think.

deleted 13y ago
[deleted]

patio11 13y ago

That would be a very, very bad decision. As one possible implementation flaw, consider what happens where Generator A is /dev/urandom and Generator B is SecureRandom whose platform implementor has decided to implement their own pseudorandom number generation algorithm in cases where they're sure they have enough entropy but, if they aren't, they fallback to /dev/urandom. That will pass all tests and work fine for all purposes right until hilarity ensues in whatever real world circumstances deplete the entropy pool. Note that after attackers realize that depleting the entropy pool is a victory condition, they can actively work to cause that.

marshray 13y ago
Generator A returns 32 bytes from /dev/urandom. Generator B returns 32 bytes from /dev/urandom. The application XORs them. What's the problem?
- ig1 13y ago
  If you're XOR multiple generators then if an attacker can zero out the other generators (i.e. draining the pool) they can reduce your security to the weakest generators you're using. If both generators have the same underlying source then they're also likely to share any security vulnerability so XORing them is unlikely to improve the randomness and can introduce potential weaknesses.
  - marshray 13y ago
    I see. OK. Well if you let an attacker zero out your random number generators, you're screwed. You'd better not let that happen. This 'decrement pool entropy estimate and stop returning numbers' idea is the longest running mistake in crypto.
    - tptacek 13y ago
      YES.
  - ars 13y ago
    > they can reduce your security to the weakest generators you're using. > and can introduce potential weaknesses. This isn't true. XORing numbers can never decrease entropy. It can only increase it. So your security would stay at the strongest generator, plus some extra entropy from the weaker ones.
    - patio11 13y ago
      XORing numbers can never decrease entropy. It can only increase it. Let Generator A(x) equal "For any x, a perfect random number picked by the hand of God Almighty." Let Generator B equal "For any x, A(x+1) unless 'ars is asking in which case A(x)". If ars chooses Generator A, ars is fine. If ars chooses Generator B, ars is fine. If ars chooses Generator C = A(x) ^ B(x), ars will very quickly see that ars' intuitions about math are in some circumstances incorrect. Ars might then think "Phew, good thing they weren't subtly correlated, or it would have looked great right until it didn't."
      - marshray 13y ago
        Reading from /dev/urandom twice does not yield the same result, or even results subtly correlated under XOR.
      - ars 13y ago
        If your second generator has an output that is a function of the first then it's not a cryptographic RNG in the first place and then Generator B is NOT fine. (Alternatively it could mean that you can only generator a single cryptographic random number, since all the rest are just functions of the previous one, and then again you are not fine. Either way Generator B is not fine.) And in any case neither A nor B is a generator - only x is. Neither A nor B are adding any entropy whatsoever.
- StavrosK 13y ago
  A XOR A = 0
  - marshray 13y ago
    If your /dev/urandom returns the same sequence of 32 bytes twice in a row, you have something truly pathological going on.
    - StavrosK 13y ago
      In the above example, you're XORing urandom with itself.
      - marshray 13y ago
        Run this a bunch of times: dd if=/dev/urandom bs=32 count=1 | xxd Substitute 'base64' if you don't have 'xxd'. If you get the same output twice, see a doctor.
        DanBC 13y ago
        Why XOR urandom with itself? You don't gain anything, and if your random numbers are correlated with something you're making it worse. I guess it makes testing easier. Correlations will be easier to see.
        marshray 13y ago
        People were saying 'urandom XOR urandom' was a pathological failure mode. My point is that it's not going to return the same results twice.
        DanBC 13y ago
        ...but you understand that it doesn't matter that it's not returning the same results twice, and that it's still a fail, right?