I hate ACPI and avoid it at all costs. But I'm fully aware that if you removed ACPI, you would have to replace it with something. My Apple 2 has a scheme for mapping ROMs on cards into memory and calling them at boot time based on descriptors in the ROMs. It has to exist in some form.
Not on target systems I don't control. Can I plug my new thing into the USB port of a Samsung phone? Not if I have to replace the kernel. The thing is locked.
You can arrange your own machines how ever you like, but if you're building things to work on everyone's machines, then you need to test it in many contexts that you don't control.
Declarative firmware only gets you so far. You can say 'Register to do X is at this address' but without software than knows what the hell to do with X you don't have a solution. Without an open interface spec, you can't write the software.
That's why open interface specifications are a prerequisite for a bottom-up auditable code set.
I can compile up my own kernel and test my device against it. But I can't go and deploy my device on the myriad computer/OS configurations out there if I need stuff compiled into the kernel. ACPI solves a problem. If your solution that replaces ACPI doesn't solve the problem ACPI solves while also solving the trojan-via-firmware problem, then it's useless. ACPI is horrible, and I'm all for replacing it with something better but I'm not seeing a proposal that does both.
I design hardware. I could wait for someone to accept my changes into the Linux Kernel before I start testing it, or I could write some firmware accessible through ACPI.
What Shutters wants is irrelevant. What he needs is open interface specifications to the hardware.
No. I was pointing out that a PRNG isn't an entropy extractor and a PRNG with a long period still isn't an entropy extractor.
An entropy extractor has to throw out less data than it takes in in order to increase the per bit entropy. A PRNG does the opposite. It takes in a seed and throws out more data than the length of the seed.
The world has moved on and left you behind. The most effective silicon validation team I know is in Bangalore. We employ people in Bangalore because they're good.
To be fair, I tried googling "what is a good entropy extraction algorithm" and I got back a combination of nonsense and mathematical mumbo jumbo. Maybe Bing would give better results but I would feel dirty trying.
This isn't a fight between Mandt and Apple. This is Apple being expected to 'do the right thing'. Using an LCG for extraction isn't close to the right thing.
No. You prove your extractor function is strong. If you don't do that you have nothing.
Dodis et al. proved that CBC-MAC is a strong extractor and that is what we use in our products as a result.
LCGs are not shown to be strong extractors to my knowledge. I can see how LCGs might fail completely if the input data isn't IID. Yuval Peres whiteners are in a similar state. There are proofs of its extraction properties, but only for IID data and you cannot get IID data out of the real world.
>I'm aware of the intel RNG that uses additional info
No. It does not use 'additional info', personalization strings or derivation function. There are no external inputs when it's running. It's the simplest instantiation of an SP800-90A AES-CTR-DRBG possible.
Who told you it uses additional info? They were talking out of their arse.
The article incoherently addresses entropy extraction, not matters of PRNGs but the author doesn't appear to understand the difference. However the 'issue' is still an issue. Predictable output is bad in this context.
What amazes me is when designers flap around looking for 'random looking' things in memory and interrupts to munch together to get entropic numbers when it's in a phone with a radio next to it which as directly sampling noise and is entirely capable of making it available to the OS for used in seeding PRNGs.
Slashdot Mirror
Please don't. I'll be going for a university engagement and a bunch of rowdy football travelers are going to gum up the flights and push prices up.
I hate ACPI and avoid it at all costs. But I'm fully aware that if you removed ACPI, you would have to replace it with something. My Apple 2 has a scheme for mapping ROMs on cards into memory and calling them at boot time based on descriptors in the ROMs. It has to exist in some form.
Not on target systems I don't control. Can I plug my new thing into the USB port of a Samsung phone? Not if I have to replace the kernel. The thing is locked.
You can arrange your own machines how ever you like, but if you're building things to work on everyone's machines, then you need to test it in many contexts that you don't control.
ACPI solves a problem
And creates half a dozen worse problems in the process.
Which bit of "ACPI is horrible, and I'm all for replacing it with something better" did you miss?
Declarative firmware only gets you so far. You can say 'Register to do X is at this address' but without software than knows what the hell to do with X you don't have a solution. Without an open interface spec, you can't write the software.
That's why open interface specifications are a prerequisite for a bottom-up auditable code set.
I'm talking about the device not the kernel.
I can compile up my own kernel and test my device against it. But I can't go and deploy my device on the myriad computer/OS configurations out there if I need stuff compiled into the kernel. ACPI solves a problem. If your solution that replaces ACPI doesn't solve the problem ACPI solves while also solving the trojan-via-firmware problem, then it's useless. ACPI is horrible, and I'm all for replacing it with something better but I'm not seeing a proposal that does both.
I design hardware. I could wait for someone to accept my changes into the Linux Kernel before I start testing it, or I could write some firmware accessible through ACPI.
What Shutters wants is irrelevant. What he needs is open interface specifications to the hardware.
No. I was pointing out that a PRNG isn't an entropy extractor and a PRNG with a long period still isn't an entropy extractor.
An entropy extractor has to throw out less data than it takes in in order to increase the per bit entropy. A PRNG does the opposite. It takes in a seed and throws out more data than the length of the seed.
The world has moved on and left you behind. The most effective silicon validation team I know is in Bangalore. We employ people in Bangalore because they're good.
A long period length does not make a good extractor.
I was the chubby guy at the front ranting about theoretical models.
To be fair, I tried googling "what is a good entropy extraction algorithm" and I got back a combination of nonsense and mathematical mumbo jumbo.
Maybe Bing would give better results but I would feel dirty trying.
good quote, crappy book.
If they'd used one of the many extractors with proven properties, they would know exactly how strong it was.
That's because SP800-90B and C are still in draft form.
Weren't you at the NIST RNG Workshop helping to get them finished? Thought not.
This isn't a fight between Mandt and Apple. This is Apple being expected to 'do the right thing'. Using an LCG for extraction isn't close to the right thing.
That's a chip design problem. Power on dependencies matter.
No. You prove your extractor function is strong. If you don't do that you have nothing.
Dodis et al. proved that CBC-MAC is a strong extractor and that is what we use in our products as a result.
LCGs are not shown to be strong extractors to my knowledge. I can see how LCGs might fail completely if the input data isn't IID. Yuval Peres whiteners are in a similar state. There are proofs of its extraction properties, but only for IID data and you cannot get IID data out of the real world.
>Either way, the proof of a good (P)RNG is in statistical analysis of the output.
No. The proof of a PRNG is in mathematical analysis of the algorithm.
The proof of the implementation is in test vectors and known answer tests.
This is true. Not something that can be said of most posts under this article.
>I'm aware of the intel RNG that uses additional info
No. It does not use 'additional info', personalization strings or derivation function. There are no external inputs when it's running. It's the simplest instantiation of an SP800-90A AES-CTR-DRBG possible.
Who told you it uses additional info? They were talking out of their arse.
More like replacing ad-hoc PRNGs with a standard's compliant ones that enjoys some consensus amongst cryptographers that it's fit for purpose.
Did you finish Portal 1 and 2?
Don't confuse British conservatism with US conservatism. They are not the same things at all.
The article incoherently addresses entropy extraction, not matters of PRNGs but the author doesn't appear to understand the difference.
However the 'issue' is still an issue. Predictable output is bad in this context.
What amazes me is when designers flap around looking for 'random looking' things in memory and interrupts to munch together to get entropic numbers when it's in a phone with a radio next to it which as directly sampling noise and is entirely capable of making it available to the OS for used in seeding PRNGs.
It's not just Apple. They all do it.