<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 27, 2022 at 11:54 AM Ron Garret <<a href="mailto:ron@flownet.com" target="_blank">ron@flownet.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"><div><br><div><div>On Aug 25, 2022, at 12:24 PM, Phillip Hallam-Baker <<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr"><div style="font-size:small">[Before we start, use language X instead is not an answer here.]</div><div style="font-size:small"><br></div><div style="font-size:small">We all know array bounds checking etc. is a good thing to have to write any application code. But the cost of abstracting away memory management is that cryptographic code has the very particular property that we want to ensure data is cleared AFTER USE rather than BEFORE REUSE.</div><div style="font-size:small"><br></div><div style="font-size:small">A lot of applications written in high level languages are vulnerable to attacks when someone uses portable assembly language, aka C to write a program that allocates large chunks of memory and then greps through it looking for 'good stuff'.</div><div style="font-size:small"><br></div><div style="font-size:small">So the question is how to ensure this does not happen by implementing disposal mechanisms THAT DO NOT GET OPTIMIZED AWAY.</div><div style="font-size:small"><br></div><div style="font-size:small">See here is the thing. I can check my code and check my code but I can only check the current version of the compiler/optimizer. And some of the things I know the C# optimizer is now doing are pretty hard core. Yes, when generating assemblies, it can optimize across assembly boundaries now.</div><div style="font-size:small"><br></div><div style="font-size:small">I am pretty sure most other high level languages suffer from the same thing unless there is a mechanism to explicitly state 'do not optimize'. Same goes for things like the Montgomery ladder which isn't as reliably constant time as some people might imagine. </div><div style="font-size:small"><br></div><div style="font-size:small">Has anyone got pointers to ways to make sure this is done right?</div></div></blockquote><br></div><div>This is a Really Hard Problem that goes beyond the language level.  Nowadays these kinds of optimizations happen *in hardware*.  Even in assembly language there is often no way to guarantee that if you write a word to memory that anything actually happens beyond the L0 cache.  It is simply not possible to draw a reliable security perimeter around a *process* on modern hardware.  This is one reason secure enclaves have become a thing.</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Worse may be better in this case.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I spent the past fortnight implementing Kyber and Dilithium in C#. Hence bringing it up. Looks to me like a hardware implementation on chip is actually pretty straightforward. The costliest is Dilithium which requires about 64KB of memory plus a SHA3 core and a multiplier.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">On chip hardware is the only way we are going to get security against the likes of ROWHAMMER and SPECTRE.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The big issue would be how to trust an on chip crypto cpu.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Threshold makes that a lot easier. The application layer generates a key pair {x.p, x}, the HSM has a keypair {y.p, y} built in that cannot be extracted (could be randomized/cleared though). The composite key {(x.P+y.P, x+y} is used to do all the crypto. The application can just hand off the additional share key to the co-processor to compute on.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">We don't have PQC Threshold yet but it may be possible for Kyber at least. The private key shares become huge (over 8KB) because you have to send the expanded matrix about. I haven't tried to make that work yet but it would be good if we could at least get threshold key generation working.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">PHB</div></div></div></div>