The issue is not so much how small and fast you can make one instance of the algorithm, but rather, how it scales from small/slow to fast/big. An algorithm like a hash or block cipher gets baked into many silicon contexts, like instructions, or memory datapaths, or offload processors, or IO datapaths. The size/speed/power requirements of these different contexts varies.
Keccek is harder to divide down into smaller execution chunks in hardware than skein. Skein has an add-xor core operation that is repeated width-wise and depth-wise. So you can easily scale it in width, depth and pipeline depth in order to meet the needs of the situation.
Yes, but the NIST competition method to define new algorithms that yielded AES and SHA3 seems to have focused more attention on the algorithms, so the odds of them being broken is reduced. SHA-0 and SHA-1 were essentially handed to the world on a plate, with little outside analysis.
So I have greater confidence in AES and SHA-3 that I did in the older algorithms. Hence me pushing to put such algorithms into CPU silicon.
> the NSA value hardware speed far more than software speed
I don't think this is true for NIST though. Witness the results of the SHA competition. Keccak sucks in hardware compared to Skein. Skein is lovely to implement in hardware. Ultimately the sponge construction is what won it.
They certainly ignored my advice on hardware implementation.
The software speed of the SHA algorithms is somewhat moot in the medium terms because over the medium term, crypto primitives (encryption, hashing, RNGs etc) are moving to hardware and moving to an instruction model instead of a device+device_driver model.
So the hardware implementations available to software through instructions will be faster than software implementations and have much better security properties in terms of attack surface and side channels. Modern crypto tends to fall to side channels and implementation error before it falls to crypto attacks and hardware is the best place to solve these problems.
Basically, we've started putting standards based crypto primitives in hardware, on the CPU die, presented through the instruction interface (E.G. AES-NI, RdRand, RdSeed) to provide for more secure crypto on PCs. This is our publicly stated intent going forward. So who cares how many cycles it takes when there's a constant time instruction available that is faster?
I was arguing that the cultural design of the tests were the tool of racial discrimination. If the tests had been launching many of the 'wrong type' into the officer ranks, the tests would have been changed. The cultural sensitivity of the test was a feature not a bug.
I'm channeling my wife here. She has a PhD in education and as a result knows all the research on testing. It still goes on. E.G. State standardized tests in Oregon recently given to kids living on a reservation. It contained math word problems concerning elevators. There was not an elevator on the whole res, many had never seen on, they had no clue about the details of operating an elevator.
The IQ test was not designed to be an absolute measure. It was developed by Alfred Binet as a way to rank between a group of children in a special education context. It gives only a relative measure between that group and does not give any absolute measurement of intelligence nor is it valid to compare IQs between different groups. The IQs assigned are only valid within the tested group.
The transition to it being an absolute measurement was pushed by the US military to test and measure recruits. This was a colossal screw up.
>Actually, 100% of the electrical power flowing into the CPU should be converted into heat. No place else for it to go.
Nope. Some of the current flows back out of the pins and is dissipated in the receiving circuit on another chip. The pin drivers consume a fair chunk of the current when they're wiggling at full pelt.
There has never been any argument about what the canonical form should be (0118 999 881 999 119 7253). The argument is about the short form (999, 911,112 etc.)
If someone wants to make a low cost, low wattage server board with all the servery goodness (ecc, failover, vt etc.) afforded by the S1200 I'm pretty sure intel would be happy to sell them the chips.
>How can lots of slow processors be better than a few fast ones with virtualization on top?
More physical contexts => less context switch overhead => can handle multiple simultaneous sessions more efficiently provided that those sessions are not individually compute or memory intensive.
It just looks like a crane int he picture, but when people walked by, it was the sort of crane that made people stop and say "By golly, that's a big crane!"
I happen to live next door to the Ronler Acres Intel Fantasy Fab Land. Somebody most definitely did built that, because for 6 months there was a 'kin huge Lampson Transilift visible out the back window. http://www.splatzone.com/lampson/
Slashdot Mirror
The issue is not so much how small and fast you can make one instance of the algorithm, but rather, how it scales from small/slow to fast/big. An algorithm like a hash or block cipher gets baked into many silicon contexts, like instructions, or memory datapaths, or offload processors, or IO datapaths. The size/speed/power requirements of these different contexts varies.
Keccek is harder to divide down into smaller execution chunks in hardware than skein.
Skein has an add-xor core operation that is repeated width-wise and depth-wise. So you can easily scale it in width, depth and pipeline depth in order to meet the needs of the situation.
Yes, but the NIST competition method to define new algorithms that yielded AES and SHA3 seems to have focused more attention on the algorithms, so the odds of them being broken is reduced. SHA-0 and SHA-1 were essentially handed to the world on a plate, with little outside analysis.
So I have greater confidence in AES and SHA-3 that I did in the older algorithms. Hence me pushing to put such algorithms into CPU silicon.
> [Fastest Encryption] Is this: source_byte_to_encrypt XOR some_random_byte.
No it isn't. The complex part is the generation of 'some_random_byte'. Check out SP800-90A,B & C. Those are not efficient algorithms.
> the NSA value hardware speed far more than software speed
I don't think this is true for NIST though. Witness the results of the SHA competition. Keccak sucks in hardware compared to Skein. Skein is lovely to implement in hardware. Ultimately the sponge construction is what won it.
They certainly ignored my advice on hardware implementation.
The software speed of the SHA algorithms is somewhat moot in the medium terms because over the medium term, crypto primitives (encryption, hashing, RNGs etc) are moving to hardware and moving to an instruction model instead of a device+device_driver model.
So the hardware implementations available to software through instructions will be faster than software implementations and have much better security properties in terms of attack surface and side channels. Modern crypto tends to fall to side channels and implementation error before it falls to crypto attacks and hardware is the best place to solve these problems.
At the recent NIST RBG Workshop http://www.nist.gov/itl/csd/ct/rbg_workshop2012.cfm
I presented a short talk on where Intel is going. http://csrc.nist.gov/groups/ST/rbg_workshop_2012/johnston.pdf
Basically, we've started putting standards based crypto primitives in hardware, on the CPU die, presented through the instruction interface (E.G. AES-NI, RdRand, RdSeed) to provide for more secure crypto on PCs. This is our publicly stated intent going forward. So who cares how many cycles it takes when there's a constant time instruction available that is faster?
14nm in planar transistors? That will leak more than Betty White's knickers.
Welcome the finfet overlords into your life.
Reverse engineering Rob Malda would prove that Rob Malda isn't NP complete, he's NP-Easy. So P = NPE.
>This seems bad. My ISP should not be interfering with traffic.
It is bad. Especially if you want to have actually mitm secure email with certs at both ends. This is a whole lot easier if you control the MTA.
DJ
I was arguing that the cultural design of the tests were the tool of racial discrimination. If the tests had been launching many of the 'wrong type' into the officer ranks, the tests would have been changed. The cultural sensitivity of the test was a feature not a bug.
I'm channeling my wife here. She has a PhD in education and as a result knows all the research on testing. It still goes on. E.G. State standardized tests in Oregon recently given to kids living on a reservation. It contained math word problems concerning elevators. There was not an elevator on the whole res, many had never seen on, they had no clue about the details of operating an elevator.
Whatever was keeping it alive? Racism? The standardized testing industry?
Yes, exactly those two things. The first in the military, the second in 'education' for want of a better term.
Interestingly the US military's version of the IQ test proved bizarrely effective at sorting black from white, which many argue was the intent.
The IQ test was not designed to be an absolute measure. It was developed by Alfred Binet as a way to rank between a group of children in a special education context. It gives only a relative measure between that group and does not give any absolute measurement of intelligence nor is it valid to compare IQs between different groups. The IQs assigned are only valid within the tested group.
The transition to it being an absolute measurement was pushed by the US military to test and measure recruits. This was a colossal screw up.
Google it. It's all there.
Still waiting for mine. But its due any day now. I might pop out to the mailbox and see.
Yes, yes and yes.
>Actually, 100% of the electrical power flowing into the CPU should be converted into heat. No place else for it to go.
Nope. Some of the current flows back out of the pins and is dissipated in the receiving circuit on another chip. The pin drivers consume a fair chunk of the current when they're wiggling at full pelt.
It depends on whether or not you have a rotary dial phone.
We do.
>Bullshit. Intel doesn't lay out CPUs by hand and hasnt' for years.
Bullshit. Parts are drawn by hand, other parts are not as engineering need dictates. This I know.
>pick a job in which you can't be replaced by a computer.
Like designing computers.
>The article says that she was earlier told that two was the limit
I was not told that when I sought to buy three. I'm an immigrant also, but I was polite. The limit may be a function of how annoying the customer is.
There has never been any argument about what the canonical form should be (0118 999 881 999 119 7253). The argument is about the short form (999, 911,112 etc.)
>How do they compare to ARM 64 chips?
S1200: Exists
ARM 64: Doesn't exist
If someone wants to make a low cost, low wattage server board with all the servery goodness (ecc, failover, vt etc.) afforded by the S1200 I'm pretty sure intel would be happy to sell them the chips.
>How can lots of slow processors be better than a few fast ones with virtualization on top?
More physical contexts => less context switch overhead => can handle multiple simultaneous sessions more efficiently provided that those sessions are not individually compute or memory intensive.
Found a picture of the one I saw..
http://www.flickr.com/photos/67292116@N00/6139404916/
It just looks like a crane int he picture, but when people walked by, it was the sort of crane that made people stop and say "By golly, that's a big crane!"
>Intel, you didn't build that!
I happen to live next door to the Ronler Acres Intel Fantasy Fab Land.
Somebody most definitely did built that, because for 6 months there was a 'kin huge Lampson Transilift visible out the back window.
http://www.splatzone.com/lampson/