Earlier quoted context omitted.
>If the hardware is more resistant to hardware and software attacks, it seems odd to then deem it less secure just because you don't get source code that isn't guaranteed to correspond to a given binary. It may be, but there's no guarantee it behaves the way it claims to. There's no guarantee it's not backdoored. There are powerful actors involved in these areas. >There's so much literature on how this methodology fa…
> It may be, but there's no guarantee it behaves the way it claims to. There's no guarantee it's not backdoored. There are powerful actors involved in these areas. It renders your point about source code moot though, doesn't it. Security is ultimately the art of trust propagation. > Care to cite some of this literature? The most famous discourse here is the "untrustworthy compiler problem." Most famous citation is by…
I don't see how that follows. If I can audit the source code and confirm that the same code is running on the device, the weak link is reduced to my ability to aduit it (combined with everyone else who's auditing it as well and might publish their findings).
>The most famous discourse here is the "untrustworthy compiler problem."
I thought this might be what you're talking about, but this is ridiculous. Do you really think that the Yubikey folks have backdoored my copy of gcc? Dude.