4 ms·

Some people actually do decompile things to make sure they don't contain security vulns. However, if your threat model includes Apple or Microsoft hiding a bac

by hannob 10y ago

Some people actually do decompile things to make sure they don't contain security vulns. However, if your threat model includes Apple or Microsoft hiding a backdoor in the OS then you can't use their OS. Designing your own CSPRNG doesn't help you. If you want that level of security you need to switch to an operating system you can trust (what that means is a complicated question which probably includes free software, reproducible builds, transparency logs and then you'll still end up with hardware you can't trust).

lisper 10y ago
> Some people actually do decompile things to make sure they don't contain security vulns. Of course, and tptacek might even be one of them. But most people don't do this. And if you don't do it yourself, if you rely on someone else who says that they did it, how do you know you can trust them? This rabbit hole is, of course, as deep as you care to dig it. It's not possible to function without trusting someone. All I'm saying is that if you choose to go down this particular branch of the rabbit hole, it is possible to learn the essentials more expeditiously than reading a 40 page document. > Designing your own CSPRNG doesn't help you That depends on what kind of back door it is. If it's just /dev/urandom which is compromised then rolling your own CSPRNG does help. And a backdoored /dev/urandom is not a completely unreasonable threat model. It's a lot easier to hide a backdoor in a CSPRNG than in just about any other part of the system because the I/O behavior of a compromised CSPRNG can be indistinguishable from a reliable one. But yes, if you're approaching this level of paranoia then switching to an open-source OS is probably more bang for the buck. But even there, are you sure that the code for /dev/urandom has been properly audited?
- tptacek 10y ago
  Yes.
  - lisper 10y ago
    Do I really need to explain why that's not a constructive answer?
    - tptacek 10y ago
      You asked a question I have a very straightforward answer for, and so I gave it to you.
      - lisper 10y ago
        OK, but the way you interpreted my question was not the way I meant it. You had already made it clear that you trust vendors. And that's fine. It's not unreasonable to trust a vendor. You have to trust someone. When I asked, "Are you sure..." I did not mean "you, Thomas Ptacek." I didn't even mean, "You, Hanno Böck" even though he is the one I was actually responding to. I meant, "You, some hypothetical person in a hypothetical scenario", specifically, a scenario where you (the hypothetical person, not you, Thomas Ptacek) are "approaching this level of paranoia", i.e. where (hypothetical) you believe that a compromised CSPRNG is a possibility you need to seriously consider for whatever reason. How can that person be confident that they can trust OpenBSD? In case you are tempted to take another whack at an answer, let me stipulate that I am assuming that this hypothetical person to whom the question is being addressed is reasonably technically competent but not a crypto expert. In particular, my hypothetical person does not know who Thomas Ptacek is, and so has no reason to lend any particular credence to his assessment of the situation in the absence of other evidence or arguments.
        tptacek 10y ago
        You asked whether the LRNG had been competently audited. It has been, by multiple groups. If you'd asked me whether the XNU kernel RNG has been audited, I would give the same answer. Different groups, of course. I don't see how these answers depend on who asked the question. It could be me asking, it could be Trevor Perrin asking, it could be Theodore T'so. The scrutiny received by both of these CSPRNGs would be the same. If you believe your personal machine has been so completely compromised that the code for your kernel CSPRNG differs materially from the current reference code that has been reviewed, you have bigger problems than your CSPRNG. Whether you have those problems or not, writing an ad hoc userland CSPRNG is unlikely to mitigate any problem, but is very likely to cause new ones. Practically all major crypto randomness vulnerabilities are caused by userland RNGs. The funny thing about this thread is that I thought I'd entered it by agreeing with you! Certainly, I think this RFC is pretty dumb.

by hannob 10y ago

lisper 10y ago

> Some people actually do decompile things to make sure they don't contain security vulns. Of course, and tptacek might even be one of them. But most people don't do this. And if you don't do it yourself, if you rely on someone else who says that they did it, how do you know you can trust them? This rabbit hole is, of course, as deep as you care to dig it. It's not possible to function without trusting someone. All I'm saying is that if you choose to go down this particular branch of the rabbit hole, it is possible to learn the essentials more expeditiously than reading a 40 page document. > Designing your own CSPRNG doesn't help you That depends on what kind of back door it is. If it's just /dev/urandom which is compromised then rolling your own CSPRNG does help. And a backdoored /dev/urandom is not a completely unreasonable threat model. It's a lot easier to hide a backdoor in a CSPRNG than in just about any other part of the system because the I/O behavior of a compromised CSPRNG can be indistinguishable from a reliable one. But yes, if you're approaching this level of paranoia then switching to an open-source OS is probably more bang for the buck. But even there, are you sure that the code for /dev/urandom has been properly audited?

tptacek 10y ago
Yes.
- lisper 10y ago
  Do I really need to explain why that's not a constructive answer?
  - tptacek 10y ago
    You asked a question I have a very straightforward answer for, and so I gave it to you.
    - lisper 10y ago
      OK, but the way you interpreted my question was not the way I meant it. You had already made it clear that you trust vendors. And that's fine. It's not unreasonable to trust a vendor. You have to trust someone. When I asked, "Are you sure..." I did not mean "you, Thomas Ptacek." I didn't even mean, "You, Hanno Böck" even though he is the one I was actually responding to. I meant, "You, some hypothetical person in a hypothetical scenario", specifically, a scenario where you (the hypothetical person, not you, Thomas Ptacek) are "approaching this level of paranoia", i.e. where (hypothetical) you believe that a compromised CSPRNG is a possibility you need to seriously consider for whatever reason. How can that person be confident that they can trust OpenBSD? In case you are tempted to take another whack at an answer, let me stipulate that I am assuming that this hypothetical person to whom the question is being addressed is reasonably technically competent but not a crypto expert. In particular, my hypothetical person does not know who Thomas Ptacek is, and so has no reason to lend any particular credence to his assessment of the situation in the absence of other evidence or arguments.
      - tptacek 10y ago
        You asked whether the LRNG had been competently audited. It has been, by multiple groups. If you'd asked me whether the XNU kernel RNG has been audited, I would give the same answer. Different groups, of course. I don't see how these answers depend on who asked the question. It could be me asking, it could be Trevor Perrin asking, it could be Theodore T'so. The scrutiny received by both of these CSPRNGs would be the same. If you believe your personal machine has been so completely compromised that the code for your kernel CSPRNG differs materially from the current reference code that has been reviewed, you have bigger problems than your CSPRNG. Whether you have those problems or not, writing an ad hoc userland CSPRNG is unlikely to mitigate any problem, but is very likely to cause new ones. Practically all major crypto randomness vulnerabilities are caused by userland RNGs. The funny thing about this thread is that I thought I'd entered it by agreeing with you! Certainly, I think this RFC is pretty dumb.