Dual_EC_DRBG is *not* mandatory under FIPS 140-2. As of today (January 1), some of the older RNGs are no longer permitted for new FIPS validations, effectively leaving you with only SP800-90A (DRBG). However, there are four different DRBGs contained within 800-90A. Nothing says you need to implement all four of them. One is good enough. Out of the four, only one of them (Dual_EC) is considered suspect.

I didn't know those were the rules. Are they well-known and well-understood? I've been out in fields in the middle of nowhere with two different people who were flying drones well above 400ft - nobody made any mention of a 400ft limit. I'm just curious.

Nothing stops these UAVs from flying in the same airspace as planes carrying people - all it takes is a little software malfunction. They are small and hard to see, aren't in radio contact with air traffic controllers, and don't show up on radar. There's a reason the government is concerned about them, and I suspect it's not about supressing truth.

Does the author actually know anything about cryptography? When the slides make reference to 128-bit and 256-bit, they are talking about *strength*, not number of bits. A 512-bit hash produces something with 256 bits of strength. In addition, let's keep in mind that the NSA has zero interest in making crypto weaker. Their interest (speaking of the SIGINT people, not the IAD people) would be in backdoors that allow them, and only them, to decrypt something while nobody else can. Nothing to see here, move along.

"Got a meeting with colleagues on the other side of the world? 4 a.m. means 4 a.m. for everyone." Yeah, and I have no idea if anyone will be awake at 4 a.m. in that part of the world when I'm scheduling the meeting unless I consult my handy "sleeping hours around the world" chart. Or we can keep things the way they are now, where I know that 4 a.m. in India is a bad time to schedule a meeting.

As a longtime Cisco competitor, I can tell you that that is their mentality, and they are right. There are a huge number of IT departments that buy Cisco just because it says Cisco, and refuse to consider anything else. Whether it's for purchasing convenience, politics, job protection, or just reasons of laziness, there are people who just buy what their Cisco rep wants them to buy. If you manage to actually get into a bakeoff test at these places, network engineers will actively try to sabotage the non-Cisco gear in an attempt to get it to fail, and thus provide justification for spending 50% more on the Cisco gear because "it's the only product that meets our stringent requirements." It is a sad thing to watch, but a fact of life if you compete against Cisco. The trick is recognizing those places early in the sales process and adjusting your efforts accordingly so you don't waste too much time.

The difference between open source and closed source software: Here's a security flaw, and on Slashdot some guy can analyze what happened and why. If this were Windows with the same problem, Slashdot would be alive with "Go figure, another security flaw in M$, when are they going to learn to write secure software?" Moral of the story: If you are going to have security vulnerabilities, make sure Slashdot readers can analyze the source code!