3 ms·

The post makes it sound like the nonce size increase was a decision made by "Juniper" after a careful consideration by a committee of grayhaired security expert

by eps 8y ago

The post makes it sound like the nonce size increase was a decision made by "Juniper" after a careful consideration by a committee of grayhaired security experts. More likely than not it was done by a random dev because 32 is the smallest power of 2 that's close to 20 and it increased their Smartbit throughput metrics by a fraction of percent and because it aligned shit better in the packet. As elegant as this conspiracy theory is, it's likely not true. It is an elegant one though, I'll give it that.

matthewdgreen 8y ago
One of the researchers here. We wrote a paper about this that you might be interested in: https://eprint.iacr.org/2016/376.pdf https://eprint.iacr.org/2016/376.pdf The nonce size isn't a particularly significant element of the "conspiracy theory" here. Those things are worth looking at because they would rule out exploitability. If one requires a conspiracy theory in this case, it would be based on the following amazing facts: 1. In addition to the pseudorandom generator (PRNG) described in FIPS certification docs, all Juniper ScreenOS devices shipped with a second unannounced public-key pseudorandom number generator (Dual_EC_DRBG) that works in parallel with the certified PRNG. 2. This generator is well known to be easy to backdoor if one replaces the standard NIST parameters with custom parameters, and this has been known since well before the generator was added in ScreenOS. 3. Amazingly, the standard NIST parameters have been replaced with new parameters, and no justification for these new parameters was provided by Juniper -- after the presence of the generator was revealed (in 2013) or after they were hacked some years later. 4. Many years after initially shipping this generator, and due to a very public de-certification of the Dual_EC_DRBG generator, Juniper quietly admitted use of that generator and parameters, but declined to remove it -- claiming that post-processing by the (official) PRNG would prevent the backdoor from being exploited. 5. Except that due to a frankly amazing coding error, the second (avowed) RNG never actually runs, ensuring that raw output from the flawed Dual EC generator is transmitted. This renders the alleged backdoor exploitable. 6. There are a number of other conditions that must be present for this flaw to be efficiently exploitable (this is one of the places where nonces come in) and every single exploitability condition is present. 7. Many years later, some outside hacker comes along, replaces the (Juniper-derived) PRNG parameters with their own parameters, and despite no further code changes the manufacturer admits that this enables a passive decryption attack on all ScreenOS devices. I don't think you need much of a conspiracy theory to ask what the heck is going on with this. Issues like the nonces aren't really proof of a conspiracy; they are things one would look for to determine whether there were specific barriers that would prevent exploitation. You can draw any conclusions you want from all of this, but it's really about as bad a fact pattern as you're ever going to see.

by eps 8y ago

matthewdgreen 8y ago

One of the researchers here. We wrote a paper about this that you might be interested in: https://eprint.iacr.org/2016/376.pdf https://eprint.iacr.org/2016/376.pdf The nonce size isn't a particularly significant element of the "conspiracy theory" here. Those things are worth looking at because they would rule out exploitability. If one requires a conspiracy theory in this case, it would be based on the following amazing facts: 1. In addition to the pseudorandom generator (PRNG) described in FIPS certification docs, all Juniper ScreenOS devices shipped with a second unannounced public-key pseudorandom number generator (Dual_EC_DRBG) that works in parallel with the certified PRNG. 2. This generator is well known to be easy to backdoor if one replaces the standard NIST parameters with custom parameters, and this has been known since well before the generator was added in ScreenOS. 3. Amazingly, the standard NIST parameters have been replaced with new parameters, and no justification for these new parameters was provided by Juniper -- after the presence of the generator was revealed (in 2013) or after they were hacked some years later. 4. Many years after initially shipping this generator, and due to a very public de-certification of the Dual_EC_DRBG generator, Juniper quietly admitted use of that generator and parameters, but declined to remove it -- claiming that post-processing by the (official) PRNG would prevent the backdoor from being exploited. 5. Except that due to a frankly amazing coding error, the second (avowed) RNG never actually runs, ensuring that raw output from the flawed Dual EC generator is transmitted. This renders the alleged backdoor exploitable. 6. There are a number of other conditions that must be present for this flaw to be efficiently exploitable (this is one of the places where nonces come in) and every single exploitability condition is present. 7. Many years later, some outside hacker comes along, replaces the (Juniper-derived) PRNG parameters with their own parameters, and despite no further code changes the manufacturer admits that this enables a passive decryption attack on all ScreenOS devices. I don't think you need much of a conspiracy theory to ask what the heck is going on with this. Issues like the nonces aren't really proof of a conspiracy; they are things one would look for to determine whether there were specific barriers that would prevent exploitation. You can draw any conclusions you want from all of this, but it's really about as bad a fact pattern as you're ever going to see.