<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Sep 11, 2026 at 12:22 AM cheater cheater <<a href="mailto:cheater00social@gmail.com">cheater00social@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> You can store databases on an untrusted device, but it's tricky.<br>
<br>
What's wrong with signing a piece of data and storing it on a flash<br>
chip? The cpu would know if it's been tampered with. Why would I need<br>
to hide data in random accesses?<br></blockquote><div><br></div><div>Where I saw this type of technology used, the lists got *big*.  The solutions I knew of were:<br>  1. Have enough memory with the secure module to hold the whole list.   Always a problem after ~5 years  <br>  2. Stream the entire list through the secure CPU.  Takes time.</div><div>  3. Have a query protocol with an untrusted local cpu that has much larger memory.  These protocols are tricky.  For example, you must clearly understand what happens if the untrusted computer responds with "nope, I don't have that".  To help prevent this, hide your intentions in a storm of requests.</div><div><br>Generally (1) was the choice because ... "gosh, sounds like you need to upgrade to our latest model!"</div><div><br></div><div> </div></div></div>