[CFRG] Re: [EXT] Re: Adoption Call: Sigma Protocols

[Cathie Yun <[e-mail]>]

It's awesome to see all this support and interest, thanks for the responses!

The sigma proofs construction maps almost exactly to the proof
constructions in existing drafts[1], where the proofs in those drafts are
wire-incompatible with the sigma spec not because of use case specific
optimizations, but mostly due to arbitrary decisions such as serialization
order.

To Bas and Christopher’s questions about adoption, the ARC draft
(draft-yun-cfrg-arc) plans to adopt the sigma protocol spec - Chris shared
this at the IETF122 meeting. The draft currently has its own schnorr
compiler[2] for creating the credential proofs, which is redundant with the
sigma spec. I think specs like this are a great example of where we can
promote reusability of cryptographic building blocks, in the same way we
have elliptic curve specs and not every cfrg draft has to define their own
elliptic curve within the draft.

Regarding the curve choice, we chose P384 out of an abundance of caution
(similar to Uri's reasoning), but are happy to support P256 if there is a
strong need / argument for it.

[1] 6 drafts (draft-yun-cfrg-arc, draft-irtf-cfrg-bbs-signatures,
draft-kalos-bbs-blind-signatures,
draft-irtf-cfrg-bbs-per-verifier-linkability, draft-ladd-privacypass-bbs)
and 2 RFCs (RFC8235, RFC9497) relying on Σ-protocols, all specified in
different ways.
[2]
https://chris-wood.github.io/draft-arc/draft-yun-cfrg-arc.html#name-schnorr-compiler

Thanks,
Cathie Yun


On Wed, Apr 30, 2025 at 12:02 PM Blumenthal, Uri - 0553 - MITLL <
[e-mail]> wrote:

> That said, the draft itself is short and well-scoped. I support adoption
> on the basis that it will at the very least be an excellent informative
> reference for others.
>
>
>
> +1
>
>
>
> A quick question for the authors: Why start with P-384? Would P-256 have
> too low of a security margin? If so, what attack are we worried about?
>
>
>
> I personally would prefer implementing as few (different) hash-functions
> as practically possible. At least some applications/deployments/customers
> *require* SHA384 or SHA512. While there are applications for which SHA256
> is sufficient – including it would imply the need to implement *both*:
> SHA256 *and* SHA384. While requiring *only* SHA384 (or only SHA512) would
> ensure that all the needs are addressed.
>
>
>
> What do you think about starting with the recently published decaf448 doc
> (RFC 9496)?
>
>
>
> See above. 😉
>
>
>
> Thanks
>
>
>
>
>
> On Thu, Apr 17, 2025 at 11:31 PM Stanislav V. Smyshlyaev <
> [e-mail]> wrote:
>
> Dear CFRG participants,
>
> This message is starting a 4-week adoption call on "Sigma Protocols"
> draft, draft-orru-zkproof-sigma-protocols (
> https://datatracker.ietf.org/doc/draft-orru-zkproof-sigma-protocols/) that
> will end on April 16th 2025.
>
> More information about the draft:
> https://mailarchive.ietf.org/arch/msg/cfrg/TkvxLDfjUZvFvh4DcbyLiraa4wM/
>
> Please send your feedback in reply to this email or directly to CFRG
> chairs <[e-mail]> <[e-mail]>.
>
> Best regards,
>
> Stanislav (for CFRG chairs)
>
>
>
>
>
>
>
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>