Hi Ben:
The conference papers (for which the titles and all other details are
spelled out in the internet draft) are available online, via a single
mouse click:
SAC 2005. https://link.springer.com/content/pdf/10.1007%2F11693383_21.pdf
A. Antipa, D.R. Brown, R. Gallant, R. Lambert, R. Struik, S.A. Vanstone,
“Accelerated Verification of ECDSA Signatures,” in /Proceedings of
Selected Areas of Cryptography – SAC 2005/, B. Preneel, S. Tavares,
Eds., Lecture Notes in Computer Science, Vol. 3897, pp. 307-318, Berlin:
Springer, 2006.
SAC 2010.
https://link.springer.com/content/pdf/10.1007%2F978-3-642-19574-7_9.pdf
R. Struik, “Batch Computations Revisited: Combining Key Computations and
Batch Verifications,” in/Proceedings of Selected Areas of Cryptography –
SAC 2010/, A. Biryukov, G. Gong, D.R. Stinson, Eds., Lecture Notes in
Computer Science, Vol. 6544, pp. 130-142, Berlin-Heidelberg: Springer, 2011
For equivalence of ECDSA and ECDSA* signature validity criteria, see p.
2 of the SAC 2005 paper (Theorem 2); QED
For putting ECDSA* into ECDSA form via (r,s) to (r,-s) change, if need
be, see, e.g., Section 4.3 of the SAC 2010 paper. QED
Since the suggested Fast-Verify friendly ECDSA format is also a valid
ECDSA signature, any forgery of ECDSA Fast Verify would constitute a
forgery of ECDSA (i.e., if the suggested speed-up would break things,
then ECDSA would be bad too). QED
For experimenting with ECDSA in JWS format, simply try and validate the
RFC 7515 example (Appendix A.3) and do the same with (r,s) replaced by
(r,-s):
a) Example with (r,s) signature:
eyJhbGciOiJFUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSApmWQxfKTUJqPP3-Kg6NU1Q
b) Same, but now with (r,-s) signature
eyJhbGciOiJFUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmU69fgrc8OPGycO0lD3tat_FoFp57SETepkeks4eL_QfA
The full details (step-by-step) are also in Appendix Q.3.4 of the lwig
curve draft:
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-22#appendix-Q.3.4
I hope this helps, Rene
On 2021-11-08 11:45 a.m., Benjamin Kaduk wrote:
Hi Rene,
I'm not opposed to a presentation; what I'm opposed to is setting up
unrealistic expectations that are doomed to disappoint.
If you are specifically asking the WG for a WG-consensus-document
allocating codepoints, the answer is "sorry, we can't do that right now --
go to CFRG first". If you are coming to the WG with a message "I know that
the WG will not accept work items using something that the WG can't tell
from 'new crypto' until there's external signoff, e.g., from the CFRG, on
the crypto, but I think the WG might be interested in this functionality
and I would like the WG's help ensuring that the CFRG answers the questions
the WG needs answered", that is a great thing to do and I'd support
spending meeting time on it (assuming that there is time after what is
needed for covering adopted WG items).
To clarify, when I asked about "more specific links/references" I was
thinking of, e.g., an http URL to an entry in the conference proceedings,
or perhaps a bibliography-entry-style reference. I am not confident that I
would find the items you are referring to, otherwise (versus some other
entry from the same conference). The only URLs I see in your previous
posting are to a 2009 NIST workshop
(https://csrc.nist.gov/csrc/media/events/cryptographic-key-management-workshop-2009/documents/rene_struik_kmwjune09_5min.pdf)
and a secdispatch posting
(https://mailarchive.ietf.org/arch/msg/secdispatch/FXnznttsnNvlYcu_PX70itFJO_A/);
in particular I do not see any links to the peer-reviewed SAC proceedings
of 2005 and 2010 that you mentioned.
I am not confident that I can frame a specific precise question during the
hustle of the IETF meeting week. I should also reiterate that I am not
looking for a "second opinion", but rather the consensus conclusion of an
open and public body qualified to assess the work. It may well be that
posting a link to Ilari's follow-up and a couple "+1" in reply would
suffice (I haven't read Ilari's message in detail yet), but if I were to
make a de novo request to CFRG, it would look something like this:
I am proposing to the COSE WG that they make use of
"verification-friendly ECDSA" [link] that adjusts the outputted signature
in order to convey parity information about the ephemeral signing key R
(which is what facilitates the efficiency gains in verification). COSE
currently has codepoints and associated processing procedures for
unmodified ECDSA. If verification-friendly ECDSA is to be used with
COSE, new codepoints will be needed so as to indicate to recipients that
the more efficient verification procedures are usable. Other than having
the new codepoints to indicate that the feature is available, are there
any other changes to the COSE protocol (and the constituent ECDSA
verification procedures) that are needed in order to retain a secure
system while using the new functionality? In particular (but not
exclusively), is it safe to allow both the regular ECDSA verification
procedures and the optimized ones to be used with these new codepoints?
Is there any additional information that would need to be conveyed in the
protocol that was not previously needed? Are there any new security
considerations that would need to be documented?
Thanks,
Ben
On Sun, Nov 07, 2021 at 12:51:48PM -0500, Rene Struik wrote:
Hi Ben:
If only for raising awareness of progress since ECDSA was first
introduced, I think a presentation would be useful.
"Be liberal about what you accept..." should also apply to presentations
that, for the first time in a very long time, have something with
significant performance potential to offer.
BTW - I presented all pointers to one-line proofs in my previous email,
including presentations in peer-reviewed conferences (2005, 2010), at
NIST (2009), etc.
What question do you need to get answered (please be precise, so that
this can be a one-round solicitation request), and I will get a 2nd
opinion on that before Wednesday.
Rene
On 2021-11-07 12:44 p.m., Benjamin Kaduk wrote:
Hi Rene,
While you may be an experienced enough cryptographer to be comfortable
asserting that there is "no new crypto" in these procedures, I contend that
being able to make that assessment does actually require some
cryptographic knowledge. In particular, the question is not just that
(r,s) and (r,-s) are either both valid solutions to the ECDSA signing
equation or both not solutions; rather, it is whether making use of this
property has any interaction with the ECDSA assumptions that must be taken
into account for use in a protocol scenario. While the fact that it is a
transform solely on public data suggests that there should not be any risk,
I, for one, am not willing to risk the reputation of the IETF on just my
own personal analysis of this case.
Furthermore, for a WG-consensus decision we never rely on just one
individual's analysis and review, and I lack confidence that the COSE WG
has sufficient cryptographic expertise to form a consensus assessment that
aligns with your individual assessment. Likewise, the SECDISPATCH session
at IETF 111 produced a conclusion that the IETF security area as a whole is
unlikely to have that expertise, and suggested that CFRG would be an
appropriate place to reach a consensus conclusion in an open and public
forum that these techniques do not require any special handling in order to
be safely used in protocols designed to use regular ECDSA.
Is there anything blocking you from raising this question at the CFRG
yourself? If it's just a matter of how to frame the question that is
believed to be relevant for IETF usage of the technique, I think we can
assist with that. The previous publication at SAC would, of course, be a
useful input for the CFRG discussion (are there more specific
links/references available?), though the IETF-78 presentation may be less
so -- lots of things can get presented at an IETF session, including those
which end up being a bad idea.
Finally, in your follow-up you also note:
As to your question "what will be the purpose of the presentation?", the
answer is that one would like to have a simple code point to facilitate
fast verification, both in single- and batch-settings.
If the goal is solely to have *a* codepoint, there does not seem to be a
need to involve the WG at all, at least initially. It appears that the
relevant IANA registries have ranges available for allocation based solely
on the "Expert Review" procedure, which is something you can request
directly from IANA without any IETF WG involvement.
There may be other reasons to present to the WG, such as gaining visibility
of the technique to the broader community, getting a codepoint from the
"standards action" ranges, etc., but just having a codepoint does not
require a presentation to the WG.
Thanks,
Ben
On Sun, Nov 07, 2021 at 10:38:22AM -0500, Rene Struik wrote:
Hi Ivaylo:
I do not understand what the role of the CFRG is with this: should they
confirm that if (r,s) is a valid ECDSA signature for message m with
signing key Q, then so is (r,-s)? Or, is there more to this?
FYI - the ECDSA signing equation is e:=h(m)=s*k-d*r (mod n), where
r:=x(R) (mod n), R:=k*G, Q:=d*G, so r=x(R)=x(-R) and e=s*k-d*r (mod n) =
(-s)*(-k) - d*r (mod n). QED.
Is the idea to have this one-line verification being blessed by someone
from CFRG (which I consider myself also part of), Scott Fluhrer or
anyone who can do modular arithmetic could do this one-line check. As I
already indicated in my email of July 27, 2021 [2],
As already indicated in the email below (July 21st), the draft does not
contain new crypto and only uses a public and reversible (r,s) to (r,-s)
signature transformation, if need be. This should therefore allow for a very
quick start-to-finish project, where enabling this simply depends on defining
code points or another unique cross-reference and getting this out of the door.
This was published in the peer-reviewed SAC 2005 conference, used in SAC
2010 again, presented at IETF-78 (July 2010, i.e., 11 years ago!),
presented at NIST in 2009 [1]. What more does one need?
I think the time is there to move forward on this extremely simple
suggestion and get this done. IETF should be able to move fast if there
is no reason to let things linger forever.
Rene
Ref: [1]
https://csrc.nist.gov/csrc/media/events/cryptographic-key-management-workshop-2009/documents/rene_struik_kmwjune09_5min.pdf
[2]
https://mailarchive.ietf.org/arch/msg/secdispatch/FXnznttsnNvlYcu_PX70itFJO_A/
On 2021-11-06 6:13 p.m., Ivaylo Petrov wrote:
Hello Rene,
Thank you for your email! It was brought to my attention that during
IETF 111 secdispatch
(https://datatracker.ietf.org/meeting/111/materials/minutes-111-secdispatch-00)
it was decided no code points to be assigned before the CFRG reviews
the document. Could you clarify if that has already concluded and if
not, what will be the purpose of the presentation?
Thanks,
Ivaylo
*Ivaylo Petrov*
CONFIDENTIALITY NOTICE: This email may contain confidential and
privileged material for the sole use of the intended recipient(s).
It is strictly forbidden to share any part of this message with any
third party, without the written consent of the sender.
If you have received this message by mistake, please notify the sender
immediately by email and delete the message and any file attached to
it. Thank you!
On Fri, Nov 5, 2021 at 7:03 PM Rene Struik<[email protected]> wrote:
Dear Ivaylo:
I would like to ask for a presentation slot for the COSE/JOSE
meeting Wednesday next week.
Title: code points for fast-verification friendly ECDSA
Presenter: Rene Struik
For context, please see my email of Tue Nov 2, 2021 below.
Best regards, Rene
On 2021-11-02 12:36 p.m., Rene Struik wrote:
Dear Ivaylo:
I presented a mechanism for putting ECDSA signatures into a
format that facilitates verification speed-ups, both in
single-verify and batch verification settings [1]. While this
technique (known for more than 1 1/2 decades) is generally
applicable, I believe this would be especially useful to
implement with JOSE and perhaps COSE right now, given
Covid-vaccination records using ES256 in the smart healthcard
specifications [3] (proposed with IATA, etc.). For the main idea,
see [1]. For a JSON Web signature example, see [2].
Do you think I could briefly present? I would like to ask for a
code point for JOSE and others down the road.
I think I could simply present the example of [2] and some
applications.
Best regards, Rene
ref: [1]
https://datatracker.ietf.org/doc/html/draft-struik-secdispatch-verify-friendly-ecdsa-00#section-9.3
[2]https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-22#appendix-Q.3.4
[3]https://smarthealth.cards/
On 2021-10-31 10:06 a.m., Ivaylo Petrov wrote:
Hello all,
This is a call for agenda items for our session at IETF 112.
Please
send them to the chairs and/or this list.
We have a slot for Wednesday, November 10, 2021 Session II
(14:30-15:30 UTC).
Thank you,
--
COSE WG Chairs
Matthew, Mike and Ivaylo
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
--
email:[email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
--
email:[email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
--
email:[email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
--
email:[email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
