[Cryptography] Intel experimental tool....

D. Hugh Redelmeier hugh at mimosa.com
Tue Apr 29 12:26:04 EDT 2014


| From: Tom Mitchell <mitch at niftyegg.com>

| Tools like this are interesting.
| 
|     http://goparallel.sourceforge.net/experimental-tool-cuts-complexity-code/
| 
| If Cryptography code can be reduced in complexity yet return the same
| result then the resulting code might present a model that is easier to
| attack than the author of the code or crypto model/standard might
| think.

I'm not sure what you are seeing in that blurb that I'm not.

It's all about code, lifted by one kind of abstraction.  Details are a
bit fuzzy (since it is a short puff piece).

Algebra is a much higher and more powerful abstraction.

Machines (and humans) can do algebra better than program optimization
partly because algebraic transformations are unencumbered by nasty
details like side-effects and bounded representations.

I don't see a new threat here.  At least not to systems with a sound
theoretical basis (i.e. algebraic).

(I'm using the word "algebraic" in a somewhat loose "you know what I
mean" way.)

| With modern large clusters the logic of some decryption/ encryption
| pairs might be proved fragile especially if it can be reduced to FPGA
| logic gates.

I think that you are saying that computational difficulty can be
reduced, surprising the designer.  Either it is visible at the
algebraic level or it is a constant-factor implementation detail.

| This is true for optimizing compilers as well -- this is in contrast
| to a compiler
| that optimizes some reuse object safety code away because it is not
| used (exposing bits to an attacker).

I'm not sure what you are saying here.  Perhaps that "what the
compiler has the machine doing" doesn't match "what the programmer
thinks the machine is doing".  Or even: the programmer knows what he
wants the machine to do but cannot direct the compiler to get this to
happen.  

When you have concerns that are not expressable in the programming
languange semantics, you are in trouble.  C's "volatile" is a tool
that many seemed to think would solve their problem.  Unfortunately,
everyone read into the semantics what they wanted.  It actually
doesn't promise enough to meet most folks expectation.

Heck, even at the machine language level you cannot get the memory
destruction that you may want: think of caching and the details like
snooping, cache-line width, etc.  Also speculative execution.  And
flash memory.  Swapping.  SMM. ...


More information about the cryptography mailing list