<div dir="ltr"><span style="font-size:12.8000001907349px">>Is this world about hardware talking to hardware?  If so, why should the</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>software world care?</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">></span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>If the world of hardware requires to talk the software world, what is</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>the balance whereby we make things worse for software, while making</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>things fast for (some) hardware buyers?</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">></span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>It's clear that in the hardware world, the economic incentives are much</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>more clearly aligned.  People actually get paid for each unit delivered!</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>  But it's also the case that hardware world pushing a more efficient</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>solution - for them - can create externalities that cause costs for the</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>software world.</span><br style="font-size:12.8000001907349px"><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">Well, I see three worlds. I see the microcontroller software world (it seems unavoidable that people are going to be wearing $10 CPUs with the computational capacity of an eleven year old desktop and the security of Windows XP), the microcontroller hardware world, and the multi-hundred dollar CPU world.</span><br style="font-size:12.8000001907349px"><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">Ultimately, Speck, Threefish, or ChaCha, fufills the needs of all three well.</span><br style="font-size:12.8000001907349px"><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">But there's a problem with the multi-hundred buck CPU world, fancy cryptographic instruction sets are most efficient when combined with complex branch prediction and parallelizable modes of operation, and it creates a certain degree of inertia. There is a middle ground. One could replace a core with an FPGA cryptographic coprocessor. Cryptography, unlike most CPU instructions, doesn't need to calculate an operation within one microsecond. A millisecond, like the GPU, is fast enough (and is smaller than network jitter). Want RC4? You can have it at x gigabits per second. Want rijndael? You can have it at x gigabits per second. Want serpent? Also available at a gigabit per second rate. Etc, etc. Afterall, modern CPUs have more transistors than the GTX 260.</span><br style="font-size:12.8000001907349px"><br style="font-size:12.8000001907349px"><br style="font-size:12.8000001907349px"><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">And there are other non-cryptographic applications that require fast compact ciphers. Many GPUs uses a hardware LCG for random numbers, which are biased and inefficient. Fast non-cryptographic random number generation is a concern, for simulation, and gaming. Ciphers shouldn't be totally standardized, there ought to be optional variants of operation for lesser threat models. One only needs 2^64 security against linear cryptanalysis to protect against script kiddies if one is programming a game. To prevent a collision of seeds, one should also have a seed state of at least 2^80, if one is using randomly generated seeds.</span><br style="font-size:12.8000001907349px"><br style="font-size:12.8000001907349px"><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">Also. There was a mention of cipher keying for different round versions by some person.</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">Doesn't Simon and Speck differentiate in it's family of ciphers using word size and round constants?</span><br></div>