4 ms·

Interesting post. One thing stood out to me: > The performance of older processes is also not sufficient for the latest cryptographic systems, such as Post Qua

Interesting post. One thing stood out to me: > The performance of older processes is also not sufficient for the latest cryptographic systems, such as Post Quantum algorithms or Multiparty Threshold ECDSA with Identifiable Aborts. On the upside, one could understand the design down to the transistor level using this process. It would be great to see support for PQ and MPC algorithms, but what would make that easier would be SE programmability with access to the base primitives. The specific title reference implies GG-20 (which the original paper is broken, revealed in later papers such as the Alpha-Rays attack), so that would suggest a need for an SE that could expose field element arithmetic (both for DKG and signature creation) and support for Paillier, but even just having the former would be a major boon, as you could implement MPC protocols that rely only on base DLog assumptions like DKLs18 and 19 which use oblivious transfer (albeit with some matrix operations). Any news on this that can be shared at this time?

bunnie 4y ago
One goal of an open-SDK SE is for all the base primitives to be open, precisely because stuff like GG-20 gets broken. I don't think it's realistic to think that we're at a point where we could burn such a novel and complicated class of algorithms into a chip, and expect it to have no revisions. The specific citation was provided because MPC algorithms span a pretty big range of computational difficulty, depending on the features you require and the primitives you assume. Narrowing it down to an exemplar algorithm (even if broken) helps pin the analysis to a given complexity range. It's also interesting to note that some MPC algorithms assume some amount of secure and real-time communication with an oracle to assist with key distribution, which means you're possibly having to stuff a TLS stack into the SE.

bunnie 4y ago

One goal of an open-SDK SE is for all the base primitives to be open, precisely because stuff like GG-20 gets broken. I don't think it's realistic to think that we're at a point where we could burn such a novel and complicated class of algorithms into a chip, and expect it to have no revisions. The specific citation was provided because MPC algorithms span a pretty big range of computational difficulty, depending on the features you require and the primitives you assume. Narrowing it down to an exemplar algorithm (even if broken) helps pin the analysis to a given complexity range. It's also interesting to note that some MPC algorithms assume some amount of secure and real-time communication with an oracle to assist with key distribution, which means you're possibly having to stuff a TLS stack into the SE.