[Cryptography] NIST Workshop on Elliptic Curve Cryptography Standards

[Ryan Carboni]

>Is this world about hardware talking to hardware?  If so, why should the
>software world care?
>
>If the world of hardware requires to talk the software world, what is
>the balance whereby we make things worse for software, while making
>things fast for (some) hardware buyers?
>
>It's clear that in the hardware world, the economic incentives are much
>more clearly aligned.  People actually get paid for each unit delivered!
>  But it's also the case that hardware world pushing a more efficient
>solution - for them - can create externalities that cause costs for the
>software world.

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.

Ultimately, Speck, Threefish, or ChaCha, fufills the needs of all three
well.

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.



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.


Also. There was a mention of cipher keying for different round versions by
some person.
Doesn't Simon and Speck differentiate in it's family of ciphers using word
size and round constants?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150517/8ff15cbc/attachment.html>