[Cryptography] Other obvious issues being ignored?

[Jerry Leichter]

> This is drifting a little away from strictly being about cryptography,
> but something like a standardized "#pragma nooptimize" attached to a
> function to tell the compiler to not optimize the code in that
> function at all but rather do as close to a one-to-one mapping from
> the source code to machine language constructs, would probably go a
> long way....
This grossly understates the problem.  Modern machines *don't match C's model".  There *is* no one-to-one mapping.  Actually, there wasn't really one even when C was designed:  Registers were a fundamental part of the real machines even then, and don't appear in the C abstract model at a all.  (Yes, there has always been a "register" declaration, and way, way back, people actually wrote code that knew how pcc would map things declared "register" to actual machine registers and use that to interface to assembly code.  But that wasn't portable even in those days.)

C is not glorified assembler.  It could kind of be treated that way back in the days of PDP-11's and roughly similar machines, but those days are long gone.  Even then, there were machines that were a very poor match the C - e.g., the CDC6600, where getting good performance required planning out memory accesses and functional unit usage in ways that could not be expressed in C.  (Today's machines have closely related issues but in a much more significant way.  On a 6600, a memory access cost you approximately as much time as three Boolean operations; a branch at least four times.  The analogous numbers today can be in the tens to hundreds depending on what level of cache you hit.)

Yes, the first requirement of crypto code is that it be correct.  But way up there on the other requirements is that it be fast enough for its intended use. In many applications, that's a significant constraint.  Sure, you can treat pretty much any machine as having a simple memory-to-memory architecture.  If nothing else, you can write an emulator for such a machine, and write all your crypto code to the emulator's interface, rather than the underlying machine's.  (You could argue that using Java byte code with a pure interpreter - disable all the JIT stuff - is one way to get there, though even the base Java model has unexpected complexities, particularly in memory synchronization.)

Will the result run fast enough to be useful?  Try it and find out.

                                                        -- Jerry