OpenBSD Will Not Fix PRNG Weakness 196
snake-oil-security writes "Last fall Amit Klein found a serious weakness in the OpenBSD PRNG (pseudo-random number generator), which allows an attacker to predict the next DNS transaction ID. The same flavor of this PRNG is used in other places like the OpenBSD kernel network stack. Several other BSD operating systems copied the OpenBSD code for their own PRNG, so they're vulnerable too; Apple's Darwin-based Mac OS X and Mac OS X Server, and also NetBSD, FreeBSD, and DragonFlyBSD. All the above-mentioned vendors were contacted in November 2007. FreeBSD, NetBSD, and DragonFlyBSD committed a fix to their respective source code trees, Apple refused to provide any schedule for a fix, but OpenBSD decided not to fix it. OpenBSD's coordinator stated, in an email, that OpenBSD is completely uninterested in the problem and that the problem is completely irrelevant in the real world. This was highlighted recently when Amit Klein posted to the BugTraq list."
then exploit it (if you can) (Score:5, Insightful)
nothing says "fix it" faster than a few thousand compromised hosts
release a PoC that gets r00t, inform the security lists and stand back
thats what full disclosure is for.
if it isnt exploitable then BSD can fix it at leisure
or if thats not quick enough and as its Open Source, YOU fix it if you are that concerned
now somebody call the whhaaambulance
Re:then exploit it (if you can) (Score:5, Informative)
Re:then exploit it (if you can) (Score:5, Informative)
Anyway, besides rudely just posting a link like that in response, I was going to say that proof-of-concept code has at least already been published, and his point is that FreeBSD, NetBSD, DragonFlyBSD has fixes available. Apple is currently working on a fix for OS X. OpenBSD is not planning to fix this. More info can be found in my parent link.
Re:then exploit it (if you can) (Score:2, Insightful)
You probably did a typo in a closing tag. Anyway, There's a reason why we have a "preview" button
Re:then exploit it (if you can) (Score:2)
Re:then exploit it (if you can) (Score:4, Informative)
Quantum mechanics delivers true randomness, at least according to the standard interpretation.
Re:then exploit it (if you can) (Score:2, Interesting)
Re:then exploit it (if you can) (Score:2)
Re:then exploit it (if you can) (Score:2, Informative)
I would have thought all algorithmic solutions to random number generation would suffer the same flaw as described in the text. Be in deep shit if it worked any other way.
Re:then exploit it (if you can) (Score:2)
Re:then exploit it (if you can) (Score:3, Informative)
Re:then exploit it (if you can) (Score:2)
Re:then exploit it (if you can) (Score:3, Interesting)
Imagine a spin-1/2-particle (e.g. an electron). Such a particle has the peculiar property that if you measure its spin along any chosen axis, you'll always get either 1/2 ("spin up") or -1/2 ("spin down").
OK, let's assume we have just measures the spin in z direction and got +1/2. Let me first note that this is stable: If we measure the z-spin of the same particle again (assuming it didn't interact in between), we will again get +1/2 each time. That is, once we measures +1/2 in z direction, every subsequent measurement will confirm that result (this may seem trivial, but it will be important further down).
Now we want to know: What is the spin in x direction? Well, it can neither be 1/2 nor -1/2, because we've "used up" all of the spin for the z direction. OTOH +1/2 and -1/2 are the only allowed values; 0 is not a possible value.
But then, if we want to know the spin in x direction, after all we can just measure it. If we do so, we indeed find either +1/2 or -1/2, and never anything else. Moreover, we find that in half of the cases we get +1/2, and in the other half we get 1/2, so on average the x spin indeed is zero, but for each single measurement we get either +1/2 or -1/2. And that value also turns out to be stable: If we repeat the x-spin measurement, we get the same value again.
Well, now we could say, maybe we just got all wrong about spin, and in truth electrons have separately an x spin of +1/2 and -1/2 and a z spin of +1/2 or -1/2 (and the same for any other direction), and what we've found is just that half of our electrons are electrons with "+" spin in one direction, and "-" spin in the other. Now, let us test that hypothesis.
We now only look at electrons which were found to have spin +1/2 in z-direction, and subsequently found spin +1/2 in x direction. OK, if the above hypothesis holds, if we now again measure in z-direction, we should again confirm the value +1/2, because after all, that value is stable, right? Well, what we find is that only in half of the cases we find z-spin +1/2, but in the other half we find z-spin -1/2! So somehow by measuring the x-spin, we destroyed the value for the z-spin.
Indeed, by measuring the spin value in one direction, we destroy the spin value for any other direction. The latest measurement destroys all information gained through previous measurements, so that if we know what we measured last (i.e. both the direction we measured in, and the measurement result), we know everything we can know about the spin. The results of previous measurements don't add any knowledge about future measurements. If we measured +1/2 on one measurement, the probability to get +1/2 on another measurement depends only on the angle of our new measurement direction to the previous measurement (and the same of course for -1/2). The smaller the angle, the more probable is it top get the same result for the new direction (measuring again in exactly the same direction reliably gives the same result again, as noted above). If we measure in a direction perpendicular, the results are completely uncorrelated to the previous measurement result; we get just +1/2 or -1/2 with 50% probability each.
So measurement obviously destroys whatever state the electron spin had before, and establishes a new state according to the result we got.
Re:then exploit it (if you can) (Score:5, Funny)
Re:then exploit it (if you can) (Score:2)
Sure, it's called "The Laws of Physics".
The only problem is, nothing can calculate the result faster than our universe is already doing. It's hard to make something that can calculate the behavior of a quark that is smaller than a quark.
Re:then exploit it (if you can) (Score:2)
Almost all processes in a computer are truly random. The number of electron crossing this particular trace per second? It's certainly not constant.
The trick in computers is keeping the RAM and the harddisk from going random too fast, such that a temporary illusion of determinism can be achieved. A crossing cosmic-ray particle will flip every last bit at random -- it'll just take sufficiently many centuries that you can imagine your bits to be stable zeros and ones.
Back in the eighties I generated truly random numbers on my old Atari by looking into the sound-chip with a port and cranking up the noise-generator on that chip. The noise-generator was just a fat resistor with a big amplifier attached to it. Quantum-randomness through thermodynamical means -- right there. Why do programmers today have trouble doing similar tings?
Re:then exploit it (if you can) (Score:3, Informative)
Because it is not part of the standard PC architecture ?
Re:then exploit it (if you can) (Score:5, Informative)
Re:then exploit it (if you can) (Score:3, Insightful)
Re:then exploit it (if you can) (Score:2)
Uh what (Score:4, Insightful)
Re: Uh what (Score:5, Informative)
Thus, it is my guess that even if the attack vectors are deemed serious enough, the OpenBSD team has decided that it doesn't matter, since these protocols were never designed for security anyway, and that one should use DNSSEC and/or IPSEC (or TLS) if one actually wants to be secure (it does raise the question as to why they decided to use a PRNG for those fields from the beginning, though). My second guess is that they don't even consider the attack vectors serious, though, since they probably require a cracked router to be effective anyway.
Indeed, if they do require a cracked router, then I don't see the issue to begin with. One of the attacks was that the attacker could inject data into a TCP stream and such things, and if he has a router cracked, then I'm pretty sure he could forge all the data he wants anyway, without using any particular software attack at all, and likewise with DNS data.
Re: Uh what (Score:2, Informative)
Re: Uh what (Score:2)
Re: Uh what (Score:5, Informative)
The exploit described in the paper doesn't require a cracked router, just a malicious website. Once you can inject fake DNS entries for bankofamerica.com or ebay.com on some ISP's DNS server, the exploit has paid for itself.
Re: Uh what (Score:2)
They'd more likely be used to compromise the user (Score:3, Insightful)
Not everything is about compromising someone's computer.
Re:Uh what (Score:5, Interesting)
It is entirely believable to me. Back in 1995 I told Marc Andressen at Netscape that he had a serious problem with the random number generator used to choose session keys for SSL. There was simply not enough randomness going in for there to be 128 bits going out.
Marc had every reason to listen to me, I had broken SSL 1.0 in ten minutes when he tried to demonstrate it at MIT. But it took several weeks to drill the problem into his thick skull.
So they eventually asked me for a description of how to do the thing right.
A year later the exact same bug was discovered independently. By this time they had hired some competent crypto people. I spoke to Taher about the problem later and his explanation was that they found the design note on the PRNG which was so comprehensive that they didn't think it necessary to check the actual code.
Re:Uh what (Score:5, Funny)
Re:Uh what (Score:5, Funny)
That's because he's so l33t he can pick a Slashdot id at random every time he posts.
Re:Uh what (Score:2, Informative)
On SSL/TLS and similar security/crypto issues, he is always interesting and more likely to be right than not.
On supporting large scientific computing platforms, he is always interesting and more likely to be right than not. His system administration c.v. is impressive.
On interpreting the experiments performed on those platforms and the results achieved, he is occasionally interesting but is much less often right than in those other areas. Unfortunately, he tends to exaggerate his area of expertise and the basis on which he was awarded his doctorate in arguments from authority.
Since most of this is readily found via your favourite Internet search engine, including the search box at the top of every slashdot page, you can easily check your own initial addition.
Re:Uh what (Score:2)
Re:Uh what (Score:2, Funny)
Re:Uh what (Score:2)
Re:Uh what (Score:3, Informative)
Marc's 128 bit encryption used a random seed with 24 bits worth of ergodicity. So it was only 24 bit secure.
And SSL 1.0 had no integrity protections whatsoever, which would have been pretty bad even if he wasn't using a stream cipher. So even if he used a 256 bit cipher it would have been broken.
What makes you think this is my only Slashdot id?
Oh and in response to the AC in the other thread, no my job title is not CTO but I do report to the CTO. Nor am I aware of any occasion where I have ever discussed the results of deep inelastic scattering experiments at ZEUS on Slashdot or any other forum.
Re:Uh what (Score:2)
I have noticed that people are complete and utter idiots about two very important cryptographic algorithms. PRNGs and hash functions. I can't believe the number of people who still use a simple MD5 hash for software download verification. First, it isn't signed, so all someone has to do is alter both the hash and the code. Secondly, even if it were it's not very hard to make two pieces of code, one innocuous and one malicious that both have the same MD5 hash, and it's been true for years.
DNS cache poisoning is a real danger. I bet someone dedicated could set up a website and evil exploiting DNS server pretty easily. You sprinkle some things in the website that will make a predictable series of requests for names in the domain of the evil DNS server, then a request for the name of bankofamerica say. Then the evil DNS server spits out the IP spoofed evil answer with the predicted sequence number for bankofamerica so the target computer gets it instead of the legitimate answer from their own DNS server. Bonus points if you can poison an ISPs recursive DNS server, then all their customers will go to the evil bankofamerica instead of the real one.
IP sequence number prediction is likely a much lesser danger because if you're in a situation where it can be exploited the router is likely compromised anyway. At least, I can't think of a way to exploit it without compromising a router.
But, regardless, if you have a PRNG in place to make a certain number unpredictable, you ought to actually care enough for the fix to actually make it that way. Either have code that works, or no code at all, not some half-assed piece of garbage that someone might mistakenly trust. Just because it runs doesn't mean it works. Anybody with that mindset should never be placed in charge of something security sensitive.
MD5 (Score:2)
I'm calling you on this claim.
Re:Uh what ... yeah (Score:2, Interesting)
If BSD used the GPL, then Apple still wouldn't be providing a fix, because they wouldn't be using OSS at all. Neither licence is better than the other in this regard.
I don't agree with the trolling from either camp. The licence you release your code under is a matter of personal choice.
Re:Uh what ... yeah (Score:3, Interesting)
While I would agree with you on the matter of trolling it really gets old when BSD users trumpet it constantly where-as in my experience GPL supporters tend to realise there are limitations. Of course I'm sure it is seen the same way across the bridge.
Re:Uh what ... yeah (Score:3, Interesting)
Out of the four items you mention, only one is GPL. You could have done much better to suggest such examples as GCC et al.
The great thing about the BSD license, is that when people do contribute back (and they do, even big companies like Apple), you know its because they *want* to, not because they *have* to.
Re:Uh what ... yeah (Score:2)
Re:Uh what ... yeah (Score:2)
Software freedom is better when its inalienable. (Score:4, Interesting)
So, in other words, the grandparent poster's point is valid and the larger more important issue remains: proprietary derivatives of non-copylefted free software uses the free software community as a market instead of treating us as equals.
Nobody "has" to under the GPL; to the degree that what you said is true, the same is true of the GPL. Statements like yours ignore all the choices that lead up to distributing source code. There's nothing in the GPL that compels conveyance. There are only conditions in the GPL that compel source code conveyance with object code conveyance. It's trivially easy to not improve GPL-covered software or not distribute the improved version. The larger issue here is whether the free software community owes Apple anything. We don't. If they want to join us and work with us, great, if not they can write their own software. The GPL helps ensure that when people and organizations convey copies of programs they do so as equals. NeXT (now owned by Apple) already tried distributing GCC derivative software without distributing complete corresponding source code when GCC was under GPLv2. It made NeXT look like an ass and put them at risk of being able to distribute GCC at all. NeXT later rectified the situation by distributing complete corresponding source code in compliance with GPLv2.
Re:Uh what ... yeah (Score:3, Informative)
Oh, and captain hater, last time I checked, the fix would be shared [apple.com].
Re:Uh what ... yeah (Score:2)
Because that is why they aren't using webkit, apache, samba, cups (or employ the guy who writes it), and several others in their default install.
....none of which touch proprietary hardware or deal with DRM.
Re:Uh what ... yeah (Score:3, Insightful)
Re:Uh what ... yeah (Score:2)
http://www.opensource.org/licenses/bsd-license.php [opensource.org]
Re:Uh what ... yeah (Score:2, Insightful)
Apple are free to release their putative fix to the community, or not - their free choice. That's one more freedom, relative to being obliged to release any changes they make which lead to a binary release outisde of Apple, which the GPL would oblige.
There are plenty of folk who see that as a feature not a flaw.
Re:Uh what ... yeah (Score:2)
Re:Uh what ... yeah (Score:2, Informative)
Re:Uh what ... yeah (Score:2)
(So possibly it's the GPLv3 is compatible with the Affero license...but the resulting code must be released Affero.)
Re:Uh what ... yeah (Score:2)
Re:Uh what ... yeah (Score:4, Insightful)
Don't conflate "things you want" with "freedom", please.
Re:Uh what ... yeah (Score:2)
I personally don't care
Re:Uh what ... yeah (Score:2)
Re:Uh what ... yeah (Score:3, Insightful)
Re:Uh what ... yeah (Score:2)
GPL has the same flaw, ya know. (Score:3, Insightful)
( * which only says something about making the code, and thus the fix, available if the code, or compiled version thereof, is distributed. )
The difference is trivial, isn't it. In both cases an existing fix would not automatically be contributed back.
Re:GPL has the same flaw, ya know. (Score:2)
Freedom doesn't mean lack of responsibility. If you're getting a benefit from the code I write, and you find a flaw in it, I think you owe me a bug report at least.
Re:Unless it's Affero GPL3 (Score:2)
And yes, Affero GPLv3 would indeed make this apply to Google if they were using it as a server-side solution. But if it's in-house only - they still don't have to contribute back. If they (or anyone) develop for a specific client only, then only that client needs to get the fix (they, of course, can then choose to make it available, depending on what contract governed the development of the software itself.).
The non-Affero GPLv3, however, has no such clauses at all, and the existance of Affero GPLv3 does not change anything about the -main- GPLv3.
Point with these licenses is that if you fixed a bug in a project using them, you're not required to contribute the fix. With the BSD license this applies any time. With the standard GPL license this applies when you're not distributing the thing. With the Affero GPL license this applies when you're not distributing it and not using it as a server-side solution. In all of these cases, somebody can be sitting on a fix and whoever's project it originally was has no recourse, within the license, to have them make that fix available.
I'm not 'doing something down' because I don't like it - I'm just saying that they all have similar problems; it doesn't make it any less of a problem with BSD, but it clearly doesn't exempt GPL either (v2, v3, Affero or otherwise; short of a 'GPL'-style license I'm not aware of that explicitly states that all modifications must be contributed back, regardless of origin or purpose, period.)
Re:Uh what ... yeah (Score:2)
Re:Uh what (Score:2)
The phrase "security through obscurity" has a well established meaning in the discussion of security measures. It refers specifically to systems that are only secure if the design is not known to the attacker.
Specific passwords (or other shared secrets like symmetric keys) are not part of the design. The design merely says that you use one, not which one you use - and security of the shared secret is only based on keeping which key / password is being used secret.
Why this is so bad: DNS cache poisoning (Score:2, Informative)
OpenBSD secure?! (Score:4, Interesting)
Oh for Bob's sake! (Score:2, Insightful)
But when the PRNG for a non-MS operating system is shown to have a similar (but not identical) problem, it's "irrelevant"?
Troll? Redundant? (Score:2)
Perception is as important as actuality (Score:2, Insightful)
Can someone say how hard a fix would be ? Surely: for the sake of a bit of work they are committing a public relations blunder!
Re:Perception is as important as actuality (Score:2)
The next thing is that anything *nix or open source is not really interested in security.
Remember that it is easier to loose reputation than to gain it.
Re:Perception is as important as actuality (Score:2, Insightful)
Nobody forces you to use OpenBSD, and nobody prevents you from patching it yourself. They are entirely in their rights to say "No" even if it is a stupid thing to do.
XYZ Attacks were also unthinkable a while ago. (Score:2, Informative)
But I wanted to show that most of todays security threats
were first percived hard to be used or totally unthinkable, even minor security problems
which later were updated to the status of a serious threat, because the first look turned out to be wrong.
So when devellopers commit themselves to build the most secure OS, and than on the other hand show such no-interest in fixing this topic, or just review the *BSD solution and paste it into the OpenBSD sourcetree with their background, I can only say this behaviour is untrustworthy.
Strike 2, OpenBSD. (Score:5, Insightful)
First they refused to implement WPA (despite the other BSDs having it), because it "doesn't provide real security" and "just use IPSEC".
Now they're refusing to address a weakness in their network stack (despite the other BSDs addressing it), again with the implication that everybody should just jump to IPSEC. What if you're in a situation where an IPSEC rollout is impractical or impossible?
Whatever happened to defense in depth? Whatever happened to "secure by default"? Whatever happened to constructive paranoia, such as randomizing of libc addresses, that was unlikely to have any real impact on security but was a nice extra, just in case? Why must I now upgrade to NetBSD to get security features that are lacking in OpenBSD? Isn't the shoe on the wrong foot?
What happened? Was there a change of management? Is OpenBSD under the thumb of a douchebag patch manager lately? Is this going to go away at some point? Those of us that sleep with OpenBSD firewalls like a gun under our pillow are taking notice.
Re:Strike 2, OpenBSD. (Score:2, Insightful)
Re:Strike 2, OpenBSD. (Score:3, Insightful)
Umm, they're completely correct to take this stance. WPA is far inferior to IPSEC, security-wise. It's OpenBSD's job to help insulate you from insecure technologies. We could easily say, "Just because FreeBSD allows one-character passwords, OpenBSD should, too!" And you know what? We'd be wrong to think in that way.
What happened? Was there a change of management? Is OpenBSD under the thumb of a douchebag patch manager lately? Is this going to go away at some point? Those of us that sleep with OpenBSD firewalls like a gun under our pillow are taking notice.
What happened? Nothing happened. The OpenBSD team members are performing their task perfectly. They are computer security experts who have considered this problem, and found it to not be the issue that some others think it is. So they're doing the responsible thing, and not making willy-nilly changes to their codebase for the sake of a "security glitch" that really doesn't exist.
Re:Strike 2, OpenBSD. (Score:5, Insightful)
So, OpenBSD is refusing to put a locking mechanism on the doorknob because it wants to make people use a deadbolt. Me, I'd want both; if it turns out my deadbolt had a defect and thus easily defeated, the doorknob lock would at least provide some security.
Theo is slow to change, but he will. (Score:5, Interesting)
Basically, he's very conservative, very resistant to change, and don't forget that's one of the things that made OpenBSD what it was to begin with... but if it really matters he'll come around.
Re:Strike 2, OpenBSD. (Score:3, Interesting)
From my impression that is an overstatement. OpenBSD will get WPA when someone writes it well enough for it to get in. Although the current devs don't want to write it themselves (as they don't feel they need it), they have left the door open for someone else to write it.
"doesn't provide real security" and "just use IPSEC" aren't reasons why it won't get in at all but reasons why that particular developer(s) isn't going to bother writing it themselves. OpenBSD is probably the ultimate "scratch your own itch" and "talk is cheap, show me the code" project. So far WPA hasn't made anyone in the OpenBSD community itchy enough. After all WEP still got in even though it is far less secure than WPA2 - someone wanted it enough to write it.
Re:Strike 2, OpenBSD. (Score:3, Interesting)
They're doctrinaire, sure (Score:3, Interesting)
OpenBSD wont fix? (Score:2)
What you really mean is 'Theo doesn't use this feature, so it cant possibly be important to anyone else in the world'. OBSD is a one man show.
How many people actually use PRNG? (Score:2)
Re:How many people actually use PRNG? (Score:3, Interesting)
Re:How many people actually use PRNG? (Score:3, Informative)
Code excerpt for the curious... (Score:5, Funny)
random vs pseudo-random? (Score:2)
I guess my questions boil down to this:
1) Is there a good way of generating sufficiently random numbers using cheap hardware?
2) If 1)=yes then why would anyone mess around with pseudo-randomness?
Re:random vs pseudo-random? (Score:2)
Re:random vs pseudo-random? (Score:2)
The rest of it either isn't necessarily random, or isn't necessarily cheap enough / fast enough. And PRNGs can be made hard enough to guess that no one will. It's kind of like how RSA is possible to crack, if someone guesses the right prime factors, but with a sufficiently large key size, you can get to where all of the matter in the Universe, assembled into chips that vaguely resemble today's processors, will not be able to guess it before the heat death of the Universe.
Of course, if quantum computers ever scale, they change the math on that and pretty much demolish RSA, but they might also make true randomness easier.
And by the way -- IANAC -- I Am Not A Cryptographer.
From the forum post: (Score:2)
copied the OpenBSD code for their own IP ID PRNG, so they're
vulnerable too. This is particularly so with Apple's Mac OS X,
Mac OS X Server and Darwin, but also with NetBSD, FreeBSD and
DragonFlyBSD (the 3 latter O/S however only use this PRNG when
the kernel flag net.inet.ip.random_id is set to 1; it is 0 by
default, resulting in a sequential counter to be used instead...).
-Ted
Why doesn't software trust /dev/[u]random ? (Score:3, Informative)
I had an interesting discussion with Amit regarding all the hacks people (including the Bind people) do to try to roll their own random number generator and it prompted me to review our own IP randomization code (and the 'off' default). After review I was decidedly uneasy about its secureness, mainly because it was trying to use an algorithmically generated cycle for a tiny namespace (16 bits, actually 15 the way it was coded). The problem with the IP sequence space is that you can't just randomize it, you also have to ensure that sequence numbers are not immediately repeated. DNS has similar issues.
I gave up trying to improve the algorithm and decided to throw in the towel and allocate 128KB of memory to do a look-ahead running shuffle of the 65536 possible sequence number using the system's PRNG. It's not possible to do better then that, frankly. We also decided to turn on ip randomization by default.
So that brings me back to the question: Why the hell doesn't bind have an option to use the system PRNG? Not all systems have a good random number generator, but I trust ours far more then the junk coded into bind. For that matter, I don't really mind if bind ate another 128K of memory to secure its own sequence space, if that is what it takes.
I know enough about cryptology to know that I am not a cryptographer. But regardless of that, I can still get a good feel for someone else's code and what BIND does scares me. The y need to change their code to default to something more secure, even if it is memory intensive. If they want to give their users the option to use the less memory intensive algorithm that's fine with me, but the default needs to be more secure.
DNS has its own design issues, but that is no excuse for software to exasperate them.
-Matt
Re:So much for high security (Score:5, Insightful)
The OpenBSD guys are pretty defensive about security. If they say it is not a problem, I am inclined to believe them.
Re:So much for high security (Score:2, Informative)
OpenBSD's argument is that a patch would not make it more secure... so your point is moot.
Re:So much for high security (Score:3, Insightful)
Re:If the OpenBSD devs say it isn't a security fla (Score:2, Insightful)
I see you don't remember how OpenBSD developers downplayed remote root vulnerability in mbuf code, until COREsecurity gived them working exploit
And this is that mega randomness with what OpenBSD team was so proud
Re:What?? (Score:5, Informative)
This could potentially provide a platform for attacks involving prediction of IP sequences and thus TCP data injection attacks.
Where is a local machine access required for that? It could provide attacks on the network traffic itself, by merely knowing which operating systems are involved in it.
Re:What?? (Score:2)
Your dollar, your time (Score:2, Insightful)
As we can see, even Microsoft can't seem to be vigilant on everything at once.
And the question to ask would be, what alternative? OpenBSD has (yet another) theoretical vulnerability. Is it one that affects the things you use obsd for?
MSWxxx has yet another real vulnerability. Is it one that affects what you use MSWxxx for?
It's better to allocate your time to be vigilant on things that matter (to you).
Re:Alternative submission (Score:3, Insightful)
If flawed, predictable PRNG code is so 'irrelevant in the real world' why does even Microsoft seek to improve upon it?
"Strengthens the cryptography platform with a redesigned random number generator, which leverages the Trusted Platform Module (TPM), when present, for entropy and complies with the latest standards. The redesigned RNG uses the AES-based pseudo-random number generator (PRNG) from NIST Special Publication 800-90 by default. The Dual Elliptical Curve (Dual EC) PRNG from SP 800-90 is also available for customers who prefer to use it."
Overview of Windows Vista Service Pack 1 [microsoft.com]
Though this question obviously will depend on how MS's previous PRNG implementation stacks up against OpenBSD's.
Re:Alternative submission (Score:2)
Because they have like six Turing award winners working for them including Butler Lampson? Of the top fifty people in network security you will find about a quarter work for Microsoft, more than for any other company, including IBM, RSA and VeriSign. They have the cash and they use it to buy the best.
Microsoft's problem is that you can't buy your way out of a shitty legacy code base in a short space of time.
Microsoft changed the RNG code to take advantage of hardware that provides a true random number generator. This was pretty much a no-brainer. Support for the AES modes is probably there so that they get some FIPS certification or other.
Re:Alternative submission (Score:2)
which leverages the Trusted Platform Module (TPM)
I smell marketing droid oil. I do favor fixing security issues, but as soon as the TPM becomes involved, rational assumptions vanish. MS has a history of *fixing* things to include new technologies they are having a hard time pushing. TPM is a huge technology for them that they have had an incredibly difficult time pushing. Microsoft needs this technology to win for their game plan to succeed. Trusted Computing in general and remote control of customer PCs is a huge win for them for everything from piracy to open source to media. If they can lock the hardware and software together, excluding things like *nix, then they win. That does not discount the need to fix security issues, but there are other huge benefits for Microsoft to fix this issue if it utilizes TPM as the solution.
InnerWeb
Using hardware to assist a PNRG =!= lock-in (Score:2)
Your assertion that using hardware to reduce the determinism and thus reduce the predictability of a PNRG must be some sort of strategy to lock hardware and software together betrays an ignorance of the problems that computer PNRGs are facing and have always faced. Read some of the other posts.
Re:OpenBSD is Dying (Score:2)
Still Alive, BSD version, sung to the tune of Jonathan Coulton's "Still Alive" from the game "Portal," originally vocalised by Ellen McLain in character as GLaDOS. I be asserting me fair use right of parody, yarr!
This was a triumph,
I'm logging a note here: Huge success,
We had to dummynet the heavy traffic,
BSD Unix (R),
We code what we must because we can,
For the good of all of us,
Including vendors as well,
But there's no sense crying over closed source code,
You just keep debugging 'till the core dumps are old,
And releases get done,
Raymond gets a new gun,
But despite this we are,
Still alive!
I'm not even angry,
I'm being so sincere right now,
Even though we got here first and beat you,
Now you say that we're dying,
And this is the year of Linux' dreams,
As you make statistics up,
We are so happy for you,
Now these points of data made our code really shine,
And we're out of beta, we're releasing on time,
So I'm glad you think you won,
There's so much needs to be done,
But regardless we are,
Still alive!
So go post on Slashdot,
I think I'd prefer to read the lists,
Maybe you'll get your own kernel someday,
Maybe that Hurd thing,
That was a joke, ha ha, fat chance,
Anyway, this code is great,
It's so consistent and neat,
Look at me still gloating when there's -CURRENT to plan,
When it's said and done you'll know that we're the best "clan",
We are organised and clean,
We go where you've never been,
And we'll always be,
Still alive!
Believe me, we are still alive,
We're all legit now and we're still alive,
We're on the server and we're still alive,
We're on the desktop and we're still alive,
We're helping Apple and we're still alive,
We're running routers and we're still alive,
We're on your gateway and we're still alive,
We've got your e-mail and we're still alive,
And when you're dying we'll be still alive,
Still alive,
Still alive!
(I hope you bastards appreciate this; it took me ages to get it to scan properly.)