[Cryptography] Moving forward on improving HTTP's security

Arnold Reinhold agr at me.com
Wed Nov 20 12:39:22 EST 2013


On Wed, 20 Nov 2013 00:53:20, Far' wrote:
> On Tue, Nov 19, 2013 at 10:52 PM, Bear <bear at sonic.net> wrote:
>> Honestly, I think the best we can do for secure crypto devices is
>> to develop and publish schematics and parts shopping guides for
>> build-your-own kits.  Along with parts testing guides and software
>> so you can be absolutely sure each component of the device is doing
>> exactly what it's supposed to do.
>> 
> I don't think we're there yet, but eventually we will be.
> 
> Trustable computing is computing that possesses an auditable bootstrap
> path from trustable sources. That is why efforts like those of Alan
> Kay, Ian Piumarta, etc., or the DARPA CRASH-SAFE program, matter.
> 
> Of course, in the next step of the trust war, to avoid overly easy
> pattern recognition and subversion of the initial bootstrap elements,
> you need not just a fixed schematics, but a random generator of
> schematics that are equivalent at a high-level, but hard to recognize
> and latch on at a low-level, thereby making a recognizer hard to hide
> in the lower-level substrate that you're building upon. Happily, we're
> not that far along the arms race yet.
> 

One of my pet ideas is to build an FPGA-based CPU with an S-box in its instruction decoder, so each instance of the CPU would have a different instruction set. Ideally the CPU would have a fixed size op code field in the instruction format, so any instruction could have any op code, and an op code space bigger than the number of operations implemented.  The S-box would be populated when each FPGA was loaded and the binary image of its software would be translated for that instance's S-box at the same time. A remote attacker would have no way to create a binary module that the CPU would execute. Of course one would have to make sure the software did not include a high level interpreter that could execute malware. Software upgrades would involve reprogramming the FPGA with a new random S-box, unless records were kept of the fielded S-boxes. If peripheral support circuits were implemented on the FPGA as well, there would be few places for malicious silicon to hide. 

Arnold Reinhold


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131120/1973175c/attachment.html>


More information about the cryptography mailing list