This is the same buggy piece of crap that led to root exploit on many Android phones, since of course a media player needs privileged access to the kernel.

http://bits-please.blogspot.co...

But don't worry, that was a fluke, I'm sure the opaque blob for the PC is written by their best men, and not the scum of the earth who failed their McDonalds job interview.
The complete loss of security to all their users is a small price to pay to eradicate unlicensed copying of movies once and for all!

What a non-story. The flaws in Dual EC DRBG were widely published shortly after release.

The backdoor was first published by Dan Shumow and Niels Ferguson in August 2007.

Bruce Schneier wrote the same year:

This was common knowledge if you had more than a passing interest in cryptography. I think TFA is mistaken when it says that it didn't get enough attention. The reason academics didn't take it more seriously is that it was seen as so obvious, it was mostly harmless shenanigans.

You would only use it in a serious cryptographic product if you were an incompetent crackhead, or if the NSA had stuffed your ass full of money.

Incidentally, RSA, the large security firm, shipped it in a serious cryptographic product for years and years.

They don't, really. The great thing about notaries as opposed to CAs is that you can use as many of them as you want, and the client decides how to handle discrepancies and outages. So a browser could ship preconfigured with 8 independent notaries, and alert the user if more than four of them were down, or if any single one of them disagreed with the rest.

In the same way, CAs can still act as authoritative notaries for domains they have signed. But now if they misbehave they can be instantly delisted, and users will fall back on the standard Convergence protection.

I disagree. The "proof of work" busywork is wasteful and makes it hard to prove any real security. The Bitcoin protocol scales poorly and consumes disproportionate resources.

I am sure it is possible to do both the ledger and the currency distribution more elegantly than Bitcoin does.

For instance, a IOU system like Ripple could facilitate a Hawala-like transaction network without the meaningless weapons race caused by allocating new coins proportionally to hashing power.

Or zero-knowledge protocols could be used to vastly enhance the anonymity of transactions.

Bitcoin is an interesting proof of concept, but "as elegant as a decentralised digital transactions system could be" is overselling it by far.

Hadn't heard about AF_BUS before...
I found the rationale, and a summary of the argument against.

I get that doing multicast in userspace isn't optimal, but I'm a bit mystified what people are doing with D-Bus that would require any kind of performance. Wasn't D-Bus supposed to be a simple pub-sub system for notification of events and the like?

No it won't. It is still easy to make collisions with a known prefix or suffix. You would have to include a random component.
Even if that was a feasible workaround, it's hardly a common best practice, nor should it be.

He discovered this vulnerability himself, and wrote the attack code; he is by definition not a script kiddie. Never mind that he's a professor and published cryptographer.

This has nothing to do with being experimental software. This is not a bug, it is a weakness in the design. Furthermore, the bad behaviour will not manifest by accident - you have to deliberately provoke it.
This is the type of problem that isn't fixed before someone finds and reports it -- like Junod did.

Please cease your inane babbling.

Also be sure to check out the brilliant paper recently published by Hakin9 in their issue on Nmap.

The authors detail the working of their DARPA Inference Cheking Kludge Scanner (DICKS), and cite such prominent references as
Z. Sun, "Towards the synthesis of vacuum tubes," Journal of Concurrent, Extensible Technology, vol. 84, pp. 1-19, Feb. 2005.
C. Hoare, J. Wilkinson, and D. Ritchie, "Contrasting Scheme and Internet QoS using SluicyMash," Journal of Flexible, Omniscient Epistemologies, vol. 20, pp. 154-194, Feb. 2000

Some excerpts:

"Obviously, event-driven modalities and web browsers are based entirely on the assumption that extreme programming and digital-to-analog converters are not in conflict with the deployment of massive multiplayer online role-playing games."

"We show our method's real-time evaluation in Figure 1. We consider a framework consisting of n flip-flop gates. Such a claim might seem counter intuitive but is derived from known results. Next, NMAP does not require such a theoretical emulation to run correctly, but it doesn't hurt. This seems to hold in most cases. We use our previously enabled results as a basis for all of these assumptions. This seems to hold in most cases."

"Figure 1.3: The 10th-percentile latency of NMAP, as a function of popularity of IPv7"

Er, or even <script src="foo" iamnotadocumentwriteusingidiot="1">

Some web browsers just render the page assuming that included scripts won't call document.write(), and then render the page again when the scripts have loaded, in case they do.
I think Chrome does this, and Opera has it as an experimental option in opera:config ("Delayed script execution").
It speeds up things a lot, especially if you aren't blocking ads. Many sites spend most of their loading time just waiting for ad servers.

There ought to be an attribute or something that webmasters could use to explicitly request XHTML semantics... Something like

Tying NaCl to a specific architecture was a very bad move in the first place, and PNaCl doesn't help a lot.
LLVM bitcode isn't intended to be a platform-independent transport of code - it isn't frozen, so you'll have to tie yourself to a specific LLVM version, while LLVM is still improving a lot with each release.
Neither is it very portable - it isn't endian independent, and it reflects details of the ABI, which means you can't even portably call C functions. It's really just a compiler IR.

See also e.g. this post.

I can certainly see reasons that you'd want to tie a VM to the browser instead of being stuck with ECMAScript for every situation, but you need to bring a real, portable VM to the table. LLVM isn't it, and the idea of putting architecture dependent binaries on the web is patently ridiculous, as should be obvious just from the time NaCl spent as x86 only. Imagine if web site owners had to recompile their site for every new architecture that became supported. "This site is best viewed on a x86"

A CA could be one such authentication step. Consider a network of independent notaries to which the CAs could securely push public certificates and tie them to a domain name.
Now you have to compromise the CA (or a sufficient number of the notaries, some perhaps run by the CAs themselves), and you have to perform the MITM upstream, not downstream, so the perspectives-like notaries will still see a consistent view.

What does this gain you over storing the cert signature itself in DNSSEC?

Nothing prevents a notary from taking extra steps to verify the authenticity of a certificate. That is one of the advantages of the concept: other methods of authentication can be added in a modular way.
In some ways the notary system gives you the security of the strongest of the notaries you trust, and the CA system gives you the security of the weakest of the CAs you trust.