<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">I am close to release, but getting a lot of pushback from people who demand 'Quantum resistant' crypto. And none of the candidates for the NIST PQC competition do threshold. So here is my plan.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">At the option of the user, documents MAY be encrypted under a combination of threshold key release and Ford-Weiner key release.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I assume that anyone who is concerned about Quantum Crypto is going to run their own key service. So I am not going to be overly worried about the risk of the key service holding the data owner to ransom etc. But I am still going to worry about the possibility that the key server admin might be an insider threat.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The goal is a system in which the key service is not a point of compromise for confidentiality unless they have access to a quantum computer.</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">The technical implementation is straightforward and does not depend on any PQC algorithm (but these could be useful for later editions.)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I add two new cryptography options to the key service 'encrypt to secret key' and 'decrypt to secret key'. </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">To encrypt a document to a quantum hardened group Alice</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Requests a symmetric encryption token k_s with identifier i_s from the service</div><div class="gmail_default" style="font-size:small">Performs a Key Exchange to the Group public key to obtain k_g</div><div class="gmail_default" style="font-size:small">Uses k_s || k_g as the input to the KDF.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So decrypting the document requires the use of BOTH the symmetric token and the group decryption..</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">To decrypt, Bob:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Requests the decryption token k_s</div><div class="gmail_default" style="font-size:small">Requests the Group decryption contribution k_gs</div><div class="gmail_default" style="font-size:small">Performs its own Group decryption against its own share k_g0</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">use k_s || (k_gs <a class="gmail_plusreply" id="gmail-plusReplyChip-2">+</a> k_go) as the input to the KDF.</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">[Russ Housley proposed something to LAMPS that got me thinking on this.]</div><div class="gmail_default" style="font-size:small"><br></div></div></div></div></div>