5 ms·

The strange story of “Extended Random”

180 points by dankohn1 9y ago

NelsonMinar 9y ago
Does the IETF still take cryptographic advice from the NSA?
- garmaine 9y ago
  Yes. It’s also hard not to, given the revolving door and the incestous nature of the industry.
  - QAPereo 9y ago
    Besides, just rejecting all of their advice makes you as easy to manipulate as following all of their advice.
    - garmaine 9y ago
      The alternative is ignore, not reject.
      - QAPereo 9y ago
        That’s a good point, true.
  - yuhong 9y ago
    I like to mention how the NSA is funded by government debt in the current debt-based economy. Which basically means that the more it spends, the more dollars gets printed.
  - tptacek 9y ago
    There is no "revolving door" between the industry and NSA, or really between the industry and any part of the USG. This is something you've made up.
    - garmaine 9y ago
      I actually work in this space, and yes it is often the case that you find people on standards bodies with prior experience at major government IT contractors with classified gaps in their CVs, and/or former private sector people who rotate into those same government contracting positions. These also tend to be the people making more ... weird ... proposals that are likely backdoors.
      - tptacek 9y ago
        Point to one of such proposal, and we'll look at the resume.
- tptacek 9y ago
  They've never formally taken cryptographic advice from the NSA. For a good long while, the chair of the IRTF CFRG was Kevin Igoe, who worked for NSA. CFRG is now chaired by Kenny Paterson, and has been for several years. Even during the Igoe years, IETF process is open; if IETF suffers from undue NSA influence, it's a consequence of people generally being too disengaged to push back on anything. IETF crypto work is particularly painful, as the noisiest people involved in the process are not, as a rule, the most crypto-literate. As always, it's worth remembering that at the time extended-random was standardized, nobody --- including cryptographers --- worried about exposing RNG output on the wire. If anything, we had the opposite concern, after the Debian fiasco. Extended-random is shady, and I now lean towards Matthew Green's take on it, but that comes from a much more recent perspective on this stuff.
weinzierl 9y ago
Do these printers use Dual_EC_DRBG too (in addition to Extended Random), to make them actually vulnerable? > Ironically, the printers are now the only thing that still exhibits the features of this (now deprecated) version of BSAFE. This is not because the NSA was targeting printers. Whatever devices they were targeting are probably gone by now. It’s because printer firmware tends to be obsolete and yet highly persistent. It’s like a remote pool buried beneath the arctic circle that preserves software species that would otherwise vanish from the Internet. Pretty chilling, but on the other hand: If this was true it should be possible to prove digging through firmware archives and actually finding these targeted devices.
- tptacek 9y ago
  This is a really good question. Is it published anywhere that this version of BSAFE enabled Dual_EC?
  - adzm 9y ago
    > From 2004 to 2013, the default CSPRNG in BSAFE was Dual_EC_DRBG
    - tptacek 9y ago
      I believe you, and think I remember reading this before. BSAFE is batshit.
cesarb 9y ago
The annoying thing is that, if they change the key_share extension to another number (and mark the current one as "reserved"), they'll have to run the TLS 1.3 experiments all over again (to see if there's anything on the new number), delaying TLS 1.3 even more.
felber 9y ago
The last part of the article made me think: Are there any printers whose software is open? Printers where always a blackbox for me that wasted ink and did not work when I needed it...
- s3krit 9y ago
  I'm afraid I can't answer your question directly, but printers being made proprietary was one of the things that led Richard Stallman to starting the GNU project, and the fight for companies to provide source code for the products they were selling to users. >In 1980, Stallman and some other hackers at the AI Lab were refused access to the source code for the software of a newly installed laser printer, the Xerox 9700. Stallman had modified the software for the Lab's previous laser printer (the XGP, Xerographic Printer), so it electronically messaged a user when the person's job was printed, and would message all logged-in users waiting for print jobs if the printer was jammed. Not being able to add these features to the new printer was a major inconvenience, as the printer was on a different floor from most of the users. This experience convinced Stallman of people's need to be able to freely modify the software they use. https://en.wikipedia.org/wiki/Richard_Stallman#Events_leading_to_GNU https://en.wikipedia.org/wiki/Richard_Stallman#Events_leadin...
colmmacc 9y ago
The IETF TLS working group has included a relevant suggestion in the TLS1.3 draft RFC: https://github.com/tlswg/tls13-spec/commit/465de0e189b2b59090d0eac0acbc42942af9ca77 https://github.com/tlswg/tls13-spec/commit/465de0e189b2b5909... The idea is simple: use two different instances of a secure RNG. One for "public" material that can be seen on the wire, which would include server and client random data. Another for "secret" material such as the private parts of DH parameters. With that set up, it's hard to impossible for DUAL_EC style attacks to work. Even if the RNG is "broken", there's nothing public to go-on to hint at what the state might be. We've been doing this in Amazon s2n since the first version, and I believe BouncyCastle does it too. Hopefully we'll see more implementations pick up the technique.
- koolba 9y ago
  > use two different instances of a secure RNG. One for "public" material that can be seen on the wire, which would include server and client random data. Another for "secret" material such as the private parts of DH parameters. Wow that's an incredibly simple solution. I feel like that general approach (where possible split client facing vs internal states) could be applied to many other places as well. Are there any problems with the additional initial entropy requirements to maintain separate RNGs (two per connection)? Or is it globally static, internal vs external?
  - blattimwind 9y ago
    RNG state entropy is not a resource that is exhausted by using the RNG. But even if it were, and assuming entropy limitations are relevant in this context (which I'd argue they are not), the total entropy requirement would not change by merely deriving the same set of values in another way. You might only need more bytes (!= entropy) from your root RNG to seed two separate RNGs. In which case you could just stretch the same number of bytes you'd normally request using e.g. HKDF. But again, it doesn't make much sense to think of entropy as something you can count or use up, really. There is no way to tell, and just a few bits (say 128) of entropy would be sufficient for almost anything...
    - 9y ago
gumby 9y ago
> In 2013, the Snowden revelations revealed the existence of a campaign to sabotage U.S. encryption systems. Is the information assurance directorate even active any more? It's interesting that they played a role (perhaps unwitting) in reducing security, or at least that their efforts to improve things were surfed by the people who gave RSA $10M. Back in the days when Brian Snow ran it I actually thought the ISD was on the side of the good guys, especially when we learned (via IBM) that their changes to the s-box had improved things.
otakucode 9y ago
All I could think of when I read 'why would the government spy on the government' was the CIA director having to admit and apologize for the CIA hacking into the servers holding documents being reviewed by the Congressional committee investigating them for their torture program... Different agencies in the government certainly have incentive and historical precedent for spying on and manipulating the others.

180 points by dankohn1 9y ago

NelsonMinar 9y ago

Does the IETF still take cryptographic advice from the NSA?

garmaine 9y ago
Yes. It’s also hard not to, given the revolving door and the incestous nature of the industry.
- QAPereo 9y ago
  Besides, just rejecting all of their advice makes you as easy to manipulate as following all of their advice.
  - garmaine 9y ago
    The alternative is ignore, not reject.
    - QAPereo 9y ago
      That’s a good point, true.
- yuhong 9y ago
  I like to mention how the NSA is funded by government debt in the current debt-based economy. Which basically means that the more it spends, the more dollars gets printed.
- tptacek 9y ago
  There is no "revolving door" between the industry and NSA, or really between the industry and any part of the USG. This is something you've made up.
  - garmaine 9y ago
    I actually work in this space, and yes it is often the case that you find people on standards bodies with prior experience at major government IT contractors with classified gaps in their CVs, and/or former private sector people who rotate into those same government contracting positions. These also tend to be the people making more ... weird ... proposals that are likely backdoors.
    - tptacek 9y ago
      Point to one of such proposal, and we'll look at the resume.
tptacek 9y ago
They've never formally taken cryptographic advice from the NSA. For a good long while, the chair of the IRTF CFRG was Kevin Igoe, who worked for NSA. CFRG is now chaired by Kenny Paterson, and has been for several years. Even during the Igoe years, IETF process is open; if IETF suffers from undue NSA influence, it's a consequence of people generally being too disengaged to push back on anything. IETF crypto work is particularly painful, as the noisiest people involved in the process are not, as a rule, the most crypto-literate. As always, it's worth remembering that at the time extended-random was standardized, nobody --- including cryptographers --- worried about exposing RNG output on the wire. If anything, we had the opposite concern, after the Debian fiasco. Extended-random is shady, and I now lean towards Matthew Green's take on it, but that comes from a much more recent perspective on this stuff.

weinzierl 9y ago

Do these printers use Dual_EC_DRBG too (in addition to Extended Random), to make them actually vulnerable? > Ironically, the printers are now the only thing that still exhibits the features of this (now deprecated) version of BSAFE. This is not because the NSA was targeting printers. Whatever devices they were targeting are probably gone by now. It’s because printer firmware tends to be obsolete and yet highly persistent. It’s like a remote pool buried beneath the arctic circle that preserves software species that would otherwise vanish from the Internet. Pretty chilling, but on the other hand: If this was true it should be possible to prove digging through firmware archives and actually finding these targeted devices.

tptacek 9y ago
This is a really good question. Is it published anywhere that this version of BSAFE enabled Dual_EC?
- adzm 9y ago
  > From 2004 to 2013, the default CSPRNG in BSAFE was Dual_EC_DRBG
  - tptacek 9y ago
    I believe you, and think I remember reading this before. BSAFE is batshit.

cesarb 9y ago

The annoying thing is that, if they change the key_share extension to another number (and mark the current one as "reserved"), they'll have to run the TLS 1.3 experiments all over again (to see if there's anything on the new number), delaying TLS 1.3 even more.

felber 9y ago

The last part of the article made me think: Are there any printers whose software is open? Printers where always a blackbox for me that wasted ink and did not work when I needed it...

s3krit 9y ago
I'm afraid I can't answer your question directly, but printers being made proprietary was one of the things that led Richard Stallman to starting the GNU project, and the fight for companies to provide source code for the products they were selling to users. >In 1980, Stallman and some other hackers at the AI Lab were refused access to the source code for the software of a newly installed laser printer, the Xerox 9700. Stallman had modified the software for the Lab's previous laser printer (the XGP, Xerographic Printer), so it electronically messaged a user when the person's job was printed, and would message all logged-in users waiting for print jobs if the printer was jammed. Not being able to add these features to the new printer was a major inconvenience, as the printer was on a different floor from most of the users. This experience convinced Stallman of people's need to be able to freely modify the software they use. https://en.wikipedia.org/wiki/Richard_Stallman#Events_leading_to_GNU https://en.wikipedia.org/wiki/Richard_Stallman#Events_leadin...

colmmacc 9y ago

The IETF TLS working group has included a relevant suggestion in the TLS1.3 draft RFC: https://github.com/tlswg/tls13-spec/commit/465de0e189b2b59090d0eac0acbc42942af9ca77 https://github.com/tlswg/tls13-spec/commit/465de0e189b2b5909... The idea is simple: use two different instances of a secure RNG. One for "public" material that can be seen on the wire, which would include server and client random data. Another for "secret" material such as the private parts of DH parameters. With that set up, it's hard to impossible for DUAL_EC style attacks to work. Even if the RNG is "broken", there's nothing public to go-on to hint at what the state might be. We've been doing this in Amazon s2n since the first version, and I believe BouncyCastle does it too. Hopefully we'll see more implementations pick up the technique.

koolba 9y ago
> use two different instances of a secure RNG. One for "public" material that can be seen on the wire, which would include server and client random data. Another for "secret" material such as the private parts of DH parameters. Wow that's an incredibly simple solution. I feel like that general approach (where possible split client facing vs internal states) could be applied to many other places as well. Are there any problems with the additional initial entropy requirements to maintain separate RNGs (two per connection)? Or is it globally static, internal vs external?
- blattimwind 9y ago
  RNG state entropy is not a resource that is exhausted by using the RNG. But even if it were, and assuming entropy limitations are relevant in this context (which I'd argue they are not), the total entropy requirement would not change by merely deriving the same set of values in another way. You might only need more bytes (!= entropy) from your root RNG to seed two separate RNGs. In which case you could just stretch the same number of bytes you'd normally request using e.g. HKDF. But again, it doesn't make much sense to think of entropy as something you can count or use up, really. There is no way to tell, and just a few bits (say 128) of entropy would be sufficient for almost anything...
  - 9y ago

gumby 9y ago

> In 2013, the Snowden revelations revealed the existence of a campaign to sabotage U.S. encryption systems. Is the information assurance directorate even active any more? It's interesting that they played a role (perhaps unwitting) in reducing security, or at least that their efforts to improve things were surfed by the people who gave RSA $10M. Back in the days when Brian Snow ran it I actually thought the ISD was on the side of the good guys, especially when we learned (via IBM) that their changes to the s-box had improved things.

otakucode 9y ago

All I could think of when I read 'why would the government spy on the government' was the CIA director having to admit and apologize for the CIA hacking into the servers holding documents being reviewed by the Congressional committee investigating them for their torture program... Different agencies in the government certainly have incentive and historical precedent for spying on and manipulating the others.