Subject: Re: [Cfrg] FW: Review of draft-irtf-cfrg-zss*

From: Laura Hitt <[email-masked]>
Date: Thu, 30 Jan 2014 15:02:49 -0600

Dear Watson,

Thank you for your review of these drafts.  My apologies for the delayed
reply, this email got buried in the onslaught of replies to this list on
and around Christmas about other matters.

First, regarding the existence of the two drafts--I had actually combined
two separate drafts (on supersingluar curves and on BN curves) into one
draft, titled "draft-irtf-cfrg-zss-02". All others should be
ignored/expire, as they are encapsulated in this one.

I have now fixed the typo you found, thank you.  It will appear corrected
in the next version I upload.

Regarding the issue of the intermediate assumptions on the hash function
being open: Do you have any suggestion on how to tie this down?  I don't
believe it's customary to specify a particular hash function, but do you
recommend placing certain stipulations on properties the hash must satisfy,
to help alleviate your concerns?

Regarding the security tables: The NIST tables are the standard reference
used in many papers, but do you have a reference for alternative entries in
the security table you'd prefer I use?

Thank you,

Laura

-----Original Message-----
> From: Cfrg [mailto:[email-masked]] On Behalf Of Watson Ladd
> Sent: Tuesday, December 24, 2013 11:39 AM
> To: [email-masked]
> Subject: [Cfrg] Review of draft-irtf-cfrg-zss*
>
> Dear all,
> These two drafts define a signature scheme based on pairings over BN and
> supersingular curves. Actually, the setting is a general pairing of Type
> III, with no hashing to group required.
> The signature scheme reduces to a k-DH style assumption in the ROM, and I
> haven't cooked up a dirty hash that can break it. Intermediate assumptions
> on the hash function to get a reduction are open. This is not a Fiat-Shamir
> transform of a ZKP, so the standard heuristics are not quite sufficient.
>
> The standardization does not pick a curve or a hash.
>
> There is a typo that leads to the representation of points on E' not being
> defined: F_p in that section should be replaced by "any field".
>
> Supersingular curves have small embedding degree: this forces the use of
> uncompetitively large primes.
>
> BN curves have embedding degree 12. This means a tower of degree 3, then
> 4. In such a tower the discrete logarithm problem can be solved quicker
> than over a prime field of the same size. I am currently searching the
> literature for the exact coefficients, but I do not feel the table in the
> draft is correct.
>
> This signature scheme promises shorter signatures than schemes of
> schnorr-style. However, in practice the failure to use point compression
> means Ed25519 is shorter. It's also much faster to verify, as pairings are
> expensive.
>
> If the k-DH complexity and discrete log complexities can be tied down
> better, I would have no objection to publishing this as an RFC.
>
> Sincerely,
> Watson Ladd
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>