OpenSparc -- the open source chip (except for the crypto parts)

[Matt Blaze]

>> Nonsense. Total nonsense. A half-decent reverse engineer does not
>> need the source code and can easily determine the exact operation of
>> all the security-related components from the compiled executables,
>> extracted ROM/EPROM code or reversed FPGA/ASIC layout
>
> I'm glad to know that you have managed to disprove Rice's
> Theorem. Could you explain to us how you did it? I suspect there's an
> ACM Turing Award awaiting you.
>
> Being slightly less sarcastic for the moment, I'm sure that a good
> reverse engineer can figure out approximately what a program does by
> looking at the binaries and approximately what an ASIC does given
> good equipment to get the layout. What you can't do, full stop, is
> know that there are no unexpected security related behaviors in the
> hardware or software. That's just not possible.
>


In particular, while it's certainly true than an expert can often  
discover
unexpected security-related behavior by careful examination of source
(or object) code, the absence of such a discovery, no matter how
expert the examination, is no guarantee of anything, for general  
software
and hardware designs.

And on a slight tangent, this is why it was only with great  
reluctance that
I agreed to participate in the "top-to-bottom" voting system reviews
conducted last year by California and Ohio.  If flaws were found (as  
they
were), that would tell us that there were flaws.  But if no flaws had
been found, that would tell us nothing about whether any such flaws were
present.  It might just have been that we were bad at our job, that the
flaws were subtle, or that something prevented us from noticing  
them.  Or
maybe there really are no flaws. There'd be no way to no for sure.

I ultimately decided to participate because I suspected that it was  
likely,
based on the immaturity of the software and the apparent lack of  
security
engineering in the design process for these systems, that we would find
vulnerabilities.  But what happens when those are fixed?  Should we then
conclude that the system is now secure?  Or should we ask another set
of experts to take another look?

After some number of iterations of this cycle, the experts might stop  
finding
vulnerabilities.  What can we conclude at that point?

It's a difficult question, but the word "guarantee" almost certainly
does not belong in the answer (unless preceded by the word "no").

-matt


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com