Security Review of Differences

[brentzundel]

The work on the specification is progressing well, but there seem to be a number of changes being considered that will cause this specification to deviate from the published and peer-reviewed academic papers.

While there may be more, I am concerned in particular about:
#19
#37
#70
#78

If these changes, or any others, are made which result in a deviation from the security proofs of the source material, then new security proofs need to be written before this spec is submitted as a draft to IETF.

[tplooker]

Thanks Brent I think we need to be careful to seperate where there are true deviations from academic literature VS ones where the literature was just not aiming to define anything at that layer, for example #78 is not a deviation from academic literature its just merely a mechanism to ensure cipher suite domain separation

[andrewwhitehead]

I think that deterministic signatures also have to be evaluated in the context of the unforgeability proof.

[tplooker]

For example #62 from @mikelodder7 should be included.

[mikelodder7]

62 is computing the same thing as before it’s just removing the same check from being performed twice. It doesn’t need a security proof

[BasileiosKal]

I do also agree. From the above IMO #19 has the biggest need for a security analyses. The reason I feel confident to keep using the proposed change is that it doesn't really change the security proofs of the original academic material (both the unforgeability and the zero knowledge proof of knowledge work the same).

Also note that the construction on section 5 of the original paper considers as the issuers public key only w and all other generators are created for all parties from a "common reference string functionality" and not from the issuer (similarly to what that issue proposes).

For some of the other issues, a security proof was written and is currently discussed for #70 although it does need reviews, #37 is essentially just a commitment the same with the ones considered in the original paper and as @tplooker noted, i don't see what security proof #78 will need.

[BasileiosKal]

62 is computing the same thing as before it’s just removing the same check from being performed twice

I think @tplooker meant the changes to the equations going in the SPK from the ones in the paper, not the duplicate checks part (which i do like).

[mikelodder7]

AFAIK there are no changes to the SPK that I made and should already match the original paper

[BasileiosKal]

AFAIK there are no changes to the SPK that I made and should already match the original paper

I think the first equation is different as i mentioned here. This is maybe better discussed elsewhere, (like #69 or maybe in a call?), but not saying that the math are not balanced, just that right now the first equation of the SPK is different (i think its Abar - D = - A' * e - H0 *r2, which is not simply the negation of what the paper uses). Whenever the change was introduced, it may need a security analyses (although it may be easier to update to use the same equations as in the paper).

[tplooker]

We are awaiting review of some new academic work that has be produced that re proves formal security for the scheme in a setting that is very close to what this draft documents. Furthermore we expect wider security review at the CFRG during the subsequent standardisation process. For now we will keep this issue open until progress is made on those two paths.

[BasileiosKal]

Discussed on WG call on 20th of Mar. Will revisit after we review and potentially use the updates from the latest academic works.

[tplooker]

With the publication of the new academic paper in EURO crypt and the pending updates to our draft to formally align it, once these have been applied, the intention is to close this issue.

[BasileiosKal]

Discussed on the WG call on the 17th of July. Will review and discuss closing this next week.

[BasileiosKal]

Discussed on the WG call on the 28th of Aug. Draft using latest academic work. Closing.