Subject: Re: [lamps] What do we want OIDS! Re: PKIX and related RFCs - definition of Key Packages

From: Kris Kwiatkowski <[email-masked]>
Date: Wed, 23 Jun 2021 19:42:54 +0100

Phillip,
> Of the current finalists, only one, SIKE appears to be compatible with the
> Threshold techniques I am using in the Mesh so I will be implementing that
> one irregardless of the final NIST choice. I would prefer that either IETF
> or the group itself specify an OID etc.

Looks like interesting statement. Can you explain why only SIKE is good
for Theshold techniques?

Br,
Kris

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 23 Jun 2021 15:26:13 -0400

> Looks like interesting statement. Can you explain why only SIKE is good
I did not say that SIKE was the only proposal that is good for threshold.
What I said is that it is the only one that is the only one that is
compatible with the techniques I am using in the Mesh.

Being a bear of very little brain, I cannot see how to extend the lattice
and code stuff to support the threshold techniques I use. But SIKE is a
Diffie Hellman scheme and and so are the schemes I use in the Mesh. So
unless torsion points behave in very different ways, I should be able to
beat SIKE into a form I can use.

Now given that I have only been looking at this for a few days and this is
new math for me, in SIKE, Alice's private key is phiA and her public key is
the corresponding torsion basis (Pa, Qa, Ra).

All I need to get threshold key distribution to work is to find operators @
and # such that

if phiA = phiX @ phiY then  (Pa, Qa, Ra) =  (PX, QX, RX) #  (PY, QY, RY)

I don't know what they are at this point, my first approach to working out
what they might be was to send a note to the authors. Failing that, I will
start looking at their code.

---

From: "Markku-Juhani O. Saarinen" <[email-masked]>
Date: Thu, 24 Jun 2021 05:15:19 +0100

Phillip,

Threshold schemes can probably be built from Isogeny assumptions but they
are likely to be quite different from SIKE (See e.g. Threshold version of
CSI-FiSh, PKC 2020 ..  https://eprint.iacr.org/2019/1288.pdf ). I'd
consider them to be highly experimental at this stage.

Also, note that SIKE is not a NIST Finalist, but an alternate Round 3
candidate. So it will not be standardized among the first batch. See NISTIR
8309 Sect 3.9 for their specific rationale, but generally, it is just "too
new" for them: https://doi.org/10.6028/NIST.IR.8309

> beat SIKE into a form I can use.

Note that technically SIKE is a KEM with a CCA transforn. Arguably calling
the CPA component, SIDH, a Diffie-Hellman is a bit of a misnomer as well
(David Jao attributed the acrony to an "anonymous wikipedia editor" when
asked -- anyway the name has stuck). It does not have the algebraic
properties typically associated with DH, such as commutativity. Obviously
no group operator / discrete log like that as it is a PQ algorithm. The
"KE" letters indicate that SIKE should be viewed is just as a KEM.

So, Isogeny-based cryptography may allow threshold schemes to be
constructed but parameter selection will be no doubt quite different from
the requirements of the NIST competition.

Cheers,
- markku

Dr. Markku-Juhani O. Saarinen <[email-masked]> PQShield, Oxford UK.