[prev in list] [next in list] [prev in thread] [next in thread]
List: cfrg
Subject: Re: [Cfrg] FW: Review of draft-irtf-cfrg-zss*
From: Laura Hitt <LHitt () 21CT ! com>
Date: 2014-01-30 21:02:49
Message-ID: CALvuEy5o55AvfLSUfk7jxedk1j4jNGVG01vY1RJi=UH2NKeLRQ () mail ! gmail ! com
[Download RAW message or body]
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:cfrg-bounces@irtf.org] On Behalf Of Watson Ladd
> Sent: Tuesday, December 24, 2013 11:39 AM
> To: cfrg@irtf.org
> 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
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>
[Attachment #3 (text/html)]
<div dir="ltr">
<p class="">Dear Watson,</p>
<p class="">Thank you for your review of these drafts.<span style> </span>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.</p>
<p class="">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.
</p><p class="">I have now fixed the typo you found, thank you. It will appear \
corrected in the next version I upload.<br></p>
<p class="">Regarding the issue of the intermediate assumptions on
the hash function being open: Do you have any suggestion on how to tie this
down?<span style> </span>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?
</p><p class="">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?<span style> \
</span></p>
<p class="">Thank you,</p>
<p class="">Laura</p>
<div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
-----Original Message-----<br>
From: Cfrg [mailto:<a href="mailto:cfrg-bounces@irtf.org">cfrg-bounces@irtf.org</a>] \
On Behalf Of Watson Ladd<br>
Sent: Tuesday, December 24, 2013 11:39 AM<br>
To: <a href="mailto:cfrg@irtf.org">cfrg@irtf.org</a><br>
Subject: [Cfrg] Review of draft-irtf-cfrg-zss*<br>
<br>
Dear all,<br>
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.<br> 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.<br>
<br>
The standardization does not pick a curve or a hash.<br>
<br>
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".<br> <br>
Supersingular curves have small embedding degree: this forces the use of \
uncompetitively large primes.<br> <br>
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.<br>
<br>
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.<br>
<br>
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.<br> <br>
Sincerely,<br>
Watson Ladd<br>
_______________________________________________<br>
Cfrg mailing list<br>
<a href="mailto:Cfrg@irtf.org">Cfrg@irtf.org</a><br>
<a href="http://www.irtf.org/mailman/listinfo/cfrg" \
target="_blank">http://www.irtf.org/mailman/listinfo/cfrg</a><br> \
</blockquote></div><br></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic