On May 6, 2008, at 1:14 AM, James A. Donald wrote:
Perry E. Metzger wrote:
> 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.
Ben Laurie wrote:
Rice's theorem says you can't _always_ solve
Perry E. Metzger wrote:
> 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.
Ben Laurie wrote:
Rice's theorem says you can't _always_ solve this problem. It says
nothing about figuring out spe
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 t
Florian Weimer <[EMAIL PROTECTED]> writes:
> * Perry E. Metzger:
>
>> Marcos el Ruptor <[EMAIL PROTECTED]> writes:
>
>>> 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 component
Ben Laurie <[EMAIL PROTECTED]> writes:
> I think that's blatantly untrue. For example, if I look at an AND
> gate, I can be absolutely sure about its security properties.
An AND gate isn't Turing Equivalent.
> Rice's theorem says you can't _always_ solve this problem. It says
> nothing about fig
Perry E. Metzger wrote:
Marcos el Ruptor <[EMAIL PROTECTED]> writes:
To be sure that implementation does not contain back-doors, one needs
not only some source code but also a proof that the source code one
has is the source of the implementation.
Nonsense. Total nonsense. A half-decent reverse
* Perry E. Metzger:
> Marcos el Ruptor <[EMAIL PROTECTED]> writes:
>> 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/EP
At Sun, 04 May 2008 20:14:42 -0400,
Perry E. Metzger wrote:
>
>
> Marcos el Ruptor <[EMAIL PROTECTED]> writes:
> > All this open-source promotion is a huge waste of time. Us crackers
> > know exactly how all the executables we care about (especially all
> > the crypto and security related program
Marcos el Ruptor wrote:
> If you want a guarantee or a proof, better ask all the
> reverse engineers you know to take a closer look at
> the program and tell you if there is a backdoor,
> anything malicious or anything sneaky or suspicious.
If it was easy to find deliberate flaws, it would be
eve
>>> but also a proof that the source code one has is the source of the
implementation.
This is an unsolved problem for code in tamper-resistant devices. There are
precious few procedures to, for example, determine that the CAC card that
was issued to Pfc. Sally Green this morning bears any rela
Marcos el Ruptor <[EMAIL PROTECTED]> writes:
>> To be sure that implementation does not contain back-doors, one needs
>> not only some source code but also a proof that the source code one
>> has is the source of the implementation.
>
> Nonsense. Total nonsense. A half-decent reverse engineer does
To be sure that implementation does not contain back-doors, one needs
not only some source code but also a proof that the source code one
has is the source of the implementation.
Nonsense. Total nonsense. A half-decent reverse engineer does not
need the source code and can easily determine the
On Thu, 1 May 2008, zooko wrote:
> I would think that it also helps if a company publishes the source
> code and complete verification tools for their chips, such as Sun has
> done with the Ultrasparc T2 under the GPL.
To be sure that implementation does not contain back-doors, one needs
not only
13 matches
Mail list logo
