Re: [Cfrg] FW: New Version Notification for draft-mattsson-cfrg-det-sigs-with-noise-00.txt

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Mar 11, 2020 at 11:15 AM John Mattsson <[e-mail]>
wrote:

> Hi Philip,
>
> I think the current discussions (NISTIR 8214A and your drafts) to
> standardize different threshold schemes are very interesting and I think
> they will be practical in a lot situations.
>
> However, I don't think draft-hallambaker-threshold-sigs-02.html and
> draft-mattsson-cfrg-det-sigs-with-noise-02 should or need to be aligned. I
> think they are quite independent. The mechanisms in
> draft-hallambaker-threshold-sigs-02.html do not seem suitable to deploy
> today in constrained IoT devices as:
>
> - The schemes are relatively heavy (for constrained IoT) as they increase
> the number of Elliptic curve point multiplications.
>

If you are doing threshold, the use of Kocher blinding is free because the
blinding can be distributed across the implementations.


> - The schemes require significant modifications to the implementation.
>

My scheme requires a non-deterministic signature. I can make use of your
scheme to do that. So I cam make my draft dependent on yours. It is
obviously not desirable to do the reverse.


> - The schemes are not for ECDSA
>

The math works for ECDSA as well. The reason I didn't include it in my
draft is that is a NIST spec, and NIST has announced work in this area. So
I am anticipating they will provide their own spec in due course. If not,
we can do a draft here if there is demand. But for the time being, best to
focus on the CFRG signatures.

The other reason for not doing ECDSA is that nobody is paying me to do this
stuff right now. It is clear that in the short term threshold ECDSA is of
great interest so we can secure code signing. If someone wants to support
my work, I will be more than happy to work out how to apply the schemes to
that algorithm and how to make use of it. My company does not require
ECDSA, we only use the CFRG curves and as Barzini put it, "we are not
communists".


> - The protection against fault attacks (active side-channel attacks) is to
> my understanding not well studied while the construction suggested in
> draft-mattsson-cfrg-det-sigs-with-noise-02 is analyzed and recommended in a
> lot of recent papers.
>

Which looks like an argument to reference your draft in mine.


> - The work to standardize threshold signatures will probably take some
> time.
>

Very much so.


> Today, we have a situation where a lot of IoT devices have are or planning
> to implement deterministic ECC signatures. Most IoT deployments today use
> ECDSA, but EdDSA is getting some footprint in new deployments. IoT devices
> are often vulnerable to side-channel and fault injection attacks and my
> current view is that such IoT devices should not use purely deterministic
> ECC signatures. For this reasons, there is a strong need to as soon as
> possible standardize a very lightweight solution for both ECDSA and EdDSA
> that does not require substantial changes to the implementation.
>

One issue that we both need to address is whether we cut new signature IDs
for the non deterministic variants. I would like us to do that as soon as
possible for the CFRG curves.

There is an application that depends on Sig(A, k) == Sig (A, k) for all
messages A and k. In particular, BitCoin assumes the uniqueness of
signatures to avoid double spending. That is (allegedly) what caused the
collapse of MtGox

We don't need to decide how we do non deterministic to roll out identifiers
for the non deterministic sig values. And threshold sigs can share those
identifiers.