IRC channel logs

2019-12-30.log

back to list of logs

<oriansj>I need everyone to keep me honest (so that bad people have no reason to bride nor threaten me)
<oriansj>dddddd: the link you shared has a line which interests me "This display’s on-glass circuits are entirely constructed of transistors large enough to be 100% inspected using a bright light and a USB microscope."
<oriansj>Why don't we just build our trusted root CPU using that?
<oriansj>we only need 20K transistors for a 64bit CPU
<oriansj> https://original.sharpmz.org/z80glass.htm
<oriansj>we just need to find a company willing to sell us those sort of chips
<oriansj>or more precisely willing to make chips for us on that process
<NieDzejkob>as far as hardware bootstrap goes, I've recently chatted with someone about the possibility of using EEPROM or SRAM chips as any other combinatorial logic chip, which could greatly reduce the chipcount of a discrete CPU
<NieDzejkob>(the SRAMs would have to be loaded by separate circuitry on boot, but are available in higher frequencies)
<xentrac>yeah, I've thought about the SRAM approach too
<oriansj>NieDzejkob, xentrac: well it presents the same sort of potential risks that one would get using standard FPGAs. At that point you might as well just use a standard FPGA (like iCE40)
<oriansj>Which honestly many people in the crypto world argue allows one to leverage the chinese room approach to trust; when it comes to implementing their designs upon an FPGA.
<oriansj>Me, I wish I could just use an off the shelf ink jet printer to print plastic transistors so we can not even debate the levels of trust involved but that isn't viable
<oriansj>So I'll take a simple close second (glass microchips that we can optically verify)
<oriansj>we only need trusted hardware on bootstraps and secured systems
<xentrac>I think standard SRAM chips are higher volume than standard FPGAs
<xentrac>I think trusted hardware is more important for bootstraps, but it's desirable to secure all systems
<oriansj>xentrac: well atleast DDC applies to hardware as well
<xentrac>due diligence checking?
<NieDzejkob>diverse double compilation?
<janneke>NieDzejkob: yes :)
<oriansj>xentrac: nope NieDzejkob got it right. Now mind you it forces us to have everything but the hardware as known good and have a single piece of trusted hardware to compare against. Unfortunately because hardware doesn't have a simple checksum option, we have a bit of a scale problem that software doesn't...
<oriansj>not to mention we have to worry about: https://web.eecs.umich.edu/~taustin/papers/OAKLAND16-a2attack.pdf
***ng0_ is now known as ng0
***Server sets mode: +cnt
***Server sets mode: +cnt
<oriansj>ultimately, it is the sort of problems we are aware of and might keep an eye on but I am hoping someone else beats me to the punch so I don't have to do everything myself there too.