[Cryptography] We need a new encryption algorithm competition.

Jerry Leichter leichter at lrw.com
Sun Mar 16 16:50:10 EDT 2014


On Mar 16, 2014, at 3:45 PM, Krisztián Pintér <pinterkr at gmail.com> wrote:
An ever-growing percentage of fielded machines will have
>> hardware support for AES, making reaching even approximate parity
>> using a pure software implementation of some other algorithm extremely difficult to achieve.
> 
> this is the best argument *against* putting direct algo support in
> CPUs. i deem the AES-NI instruction set rather harmful for the
> industry.
That's a battle we lost long before we ever knew we were fighting it.  The very notion that there should be a standard, universal encryption algorithm - a notion that made it into public awareness with DES, and was so well established by the time of the AES design contest that it wasn't even questioned - guaranteed that, eventually, something like AES-NI would exist.  (In fact, early on, DES accelerator chips were a big deal, because software implementations couldn't keep up with emerging network technologies - like the original 10Mb/sec Ethernet.  The long period in which we did crypto entirely in software may soon appear to be an anomaly.)

It's interesting to note that (a) NSA always seemed to believe in hardware-based crypto - the DES initial and final permutations appear to play no role other than making software implementations harder; (b) NSA also has never believed in just one cipher.  We know publicly of several families of ciphers specialized for different purposes, though we know little or nothing about the details.  Of course, NSA has the funds and control needed to mix multiple algorithms with hardware implementation:  They can afford to recall and replace hardware as needed.

> it would be much better if we put general purpose
> instructions that help crypto. like huge register space (in the 8000
> bit range), versatile parallelism, support for GF field operations
> (prime and binary), better support for big num arithmetic, on-chip key
> storage, etc. just like GPU designers sit down with game developers
> and survey what they want, CPU developers should sit down with
> cryptographers.
Don't hold your breath.  No one would see a clear market need for such a thing - after all, everyone uses AES, don't they?

On the other hand, we *do* have GPU's.  If we took some reasonable common subset of GPU functionality as a given ... how would we design a cipher that used it to attain very high performance?  (Note that this is the opposite of the efforts we've already seen to compute *existing* ciphers as quickly as possible in a GPU - and often in unusual configurations that work for attacks but don't help normal usage.)
                                                        -- Jerry



More information about the cryptography mailing list