Rephrased TLS 1.3 recommendation.

TODO_review

@@ -312,6 +312,116 @@ Detailed comments below:
 # probably show up only in 2024.)
 #
 > Fixed. Now we refer to C programming language initializers.
+> We also added JSON version of the test vectors.
 
 (I do not have time to check the test vectors right now.)
 
+
+
+******************************************************************************************
+******************************************************************************************
+******************************************************************************************
+
+Hello All,
+
+I spent a couple of days re-reading the CPace draft 10 (
+https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-cpace-10) the 2021
+security analysis paper by Abdella, Haase,
+and Hesse (https://eprint.iacr.org/2021/114.pdf) and the process critique
+paper by Hao (https://eprint.iacr.org/2021/839.pdf)
+In particular, I looked at how CPace could be securely integrated into a
+protocol like TLS 1.3.
+
+----
+#In 2019, we reviewed the original CPace proposal with colleagues at Inria>
+#Prosecco and our review raised three points on the original proposal:
+#
+#1) CPace uses a unique connection identifier (CI) in the first message from
+#  the initiator to the responder to prevent relay attacks.
+#  It was not clear to us how this unique CI could be computed without
+#  adding a round-trip to the protocol.
+#
+# 2) CPace relies on a unique session identifier (sid) for multi-session
+#    security. This sid is also used in the first protocol message.
+#    Again, it was not clear to us how the two parties could agree on an sid
+#    without adding a round-trip to the protocol.
+#
+# 3) It was unclear whether key confirmation was needed or not.
+
+# It is worth noting that 1) and 2) are also pointed out as potential CPace
+# defects in Hao’s critique.
+
+----
+# After reviewing the latest CPace draft, I can confirm that these questions
+# are now answered in the text:
+
+# Connection Identifier (CI)
+# - Section 3.1 now says that the CI is *optional*.
+# - In response to our review, the authors said that the CI could use network
+#   addresses (IP addresses and ports) which do not require a round-trip
+# - The authors also say that CI is not needed if the application protocol
+# provides key confirmation, which e.g. TLS 1.3 does
+> We have further clarified the intended use of CI regarding party identity strings
+> in the light of the crypto2024 paper and recommend party identities to be included
+> in CI (with preference) or alternatively in ADa and ADb.
+
+# Session Identifier (sid)
+# - Section 3.1 now says that the sid is *optional*.
+# - This section recommends that the two parties should jointly establish an
+#   sid before the connection (which does imply an extra round-trip, at least
+#   for TLS 1.3)
+# - It also says that the initiator can unilaterally generate a fresh sid and
+# send it to the responder (which would not require an extra round-trip).
+> The aspect of the session identifer has been analyzed in the recent crypto2024 paper
+> and it has been confirmed that CPace can be proven secure also without pre-agreed sid.
+> This is now also stated in the text.
+
+#Key Confirmation
+# - Section 9.4 explicitly describes how to obtain Explicit Key Confirmation
+#   if needed
+# - Protocols like TLS 1.3 already provide key confirmation.
+
+----
+Given the above clarifications, the following security questions still
+remain:
+
+# - The multi-session security of CPace relies on a “jointly” generated
+#   unique sid.
+#   Does this proof still hold if the initiator unilaterally generates the
+#   sid?
+#   Couldn’t the responder be vulnerable to replay attacks in this setting?
+#   How would one adapt the proof to account for unilateral “sid”s?
+> The aspect of the session identifer has been analyzed in the recent crypto2024 paper
+> and it has been confirmed that CPace can be proven secure also without pre-agreed sid.
+> This is now also stated in the text.
+
+
+# - What is the recommended way of integrating CPace into (say) TLS 1.3?
+#   Does the ISK take the role of (EC)DHE shared secret in the key schedule?
+#   Does the ISK become an additional input that is combined with an (EC)DHE
+#   shared secret?
+#   The definition and format of transcript in CPace is not exactly the same
+#   as the TLS handshake transcript.
+#   Are these two to be merged? If so, the test vectors of CPace would no
+#   longer work.
+> We added an explicit section with recommendations on how to integrate CPace
+> in TLS 1.3.
+> Originally we meant to leave the flexibility for implementers to use their
+> own network encoding format for CPace such that the transcripts of TLS and
+> CPace may match. However after considering the feedback of Thomas Pornin we
+> agreed that it is better to enforce a specific form of the transcript even
+> if that adds some level of redundancy for protocols such as TLS 1.3. 
+> The advantage is that this way we will have inter-operability even if a higher-
+> level protocol uses different types of encodings on the network layer.
+
+# It if of course not expected that the CPace draft should answer these
+# questions with concrete designs and formal proofs,
+# but it would be useful to the reader and implementor to learn the answers
+# to these questions and know the pitfalls of
+# embedding CPace incorrectly into an application protocol.
+#
+
+# Best regards,
+# Karthik
+
+

draft-irtf-cfrg-cpace.md

@@ -713,7 +713,7 @@ As noted already in {{protocol-section}} it is RECOMMENDED to process ISK
 by use of a suitable strong key derivation function KDF (such as defined in {{?RFC5869}}) first,
 before using the key in a higher-level protocol.
 
-## Key confirmation
+## Key confirmation {#sec-key-confirmation}
 
 In many applications it is advisable to add an explicit key confirmation round after the CPace protocol flow. However, as some applications
 might only require implicit authentication and as explicit authentication messages are already a built-in feature in many higher-level protocols (e.g. TLS 1.3) the CPace protocol described here does not mandate
@@ -742,6 +742,32 @@ One suitable option that works also in the parallel setting without message orde
 
 - Let the receiving party check the remote authentication tag for the correct value and abort in case that it's incorrect.
 
+## Integrating CPace in higher-level protocols such as TLS1.3
+
+When integrating CPace into a higher-level protocol such as TLS1.3 {{RFC8446}} it is recommended to let the intermediate key ISK
+take over the role of the shared secret that for other cipher suites
+might be generated by Diffie-Hellman key exchange. Note that unlike a Diffie-Hellman shared secret ISK will also
+mutually authenticate the protocol partners.
+For providing explicit authentication, it is recommended to add a key confirmation round along the lines in {{sec-key-confirmation}},
+such as e.g. done in the "Finished" messages in TLS1.3.
+
+If an embedding protocol uses more than two messages (e.g. four message TLS1.3 {{RFC8446}} flows involving
+a hello-retry message and a repeated client-hello message) it is suggested
+that the CPace layer only considers the two messages used for the CPace run. I.e. it is suggested that
+authenticating the full message sequence involving also the additional messages that might preceed the two CPace messages
+is done under the responsibiity of the embedding protocol.
+This could be done by integrating the full protocol transcript as part of a final explicit key confirmation round (as commonly done by TLS 1.3).
+Alternatively information on communication rounds preceeding the CPace flows can also be integrated as part of the CI field, as this will authenticate
+the information and will not require both communication partners to keep state information regarding preceeding messages until after the CPace run.
+
+In case of TLS 1.3 it is suggested to integrate Ya into the client-hello message and Yb into the server-hello message. Also party identifiers
+may be added to the client-hello and server-hello messages as part of extension fields.
+It is recommended to use the full octet stream encoding of the
+client-hello message as parameter ADa. Likewise the encoding of the server-hello would be used for the parameter ADb.
+This approach has the drawback that the public points Ya and Yb might show up duplicated in the hashing operation for
+CPace's transcript strings but has the advantage of simplicity and the advantage that all meta-information in the extension fields within the
+client- and server hello fields will become authenticated as part of the ISK.
+
 ## Calculating a session identifier alongside with the CPace run {#sec-sid-output}
 
 If CPace was run with an empty string sid available as input, both parties can produce a session identifier string
@@ -829,6 +855,7 @@ We would like to thank the participants on the CFRG list for comments and advice
 
 
 
+
 # CPace function definitions
 
 
@@ -1548,23 +1575,49 @@ qb: 993c6ad11c4c29da9a56f7691fd0ff8d732e49de6250b6c2e80003ff4629a175
 
 ~~~
 
-    ###eyJJbnZhbGlkIFkwIjogIkFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
-    ###QUFBQUFBQUFBQUFBQUE9IiwgIkludmFsaWQgWTEiOiAiQVFBQUFBQUFBQUFB
-    ###QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQT0iLCAiSW52YWxpZCBZ
-    ###MiI6ICI3UC8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
-    ###LzM4PSIsICJJbnZhbGlkIFkzIjogIjRPdDZmRHRCdUs0V1Z1UDY4Wi9FYXRv
-    ###SmpldWNNckg5aG1JRkZsOUp1QUE9IiwgIkludmFsaWQgWTQiOiAiWDV5VnZL
-    ###TlFqQ1N4MExGVm5JUHZXd1JFWE1SWUhJNkcyQ0pPM2RDZkVWYz0iLCAiSW52
-    ###YWxpZCBZNSI6ICI3Zi8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
-    ###Ly8vLy8vLzM4PSIsICJJbnZhbGlkIFk2IjogIjJ2Ly8vLy8vLy8vLy8vLy8v
-    ###Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLzg9IiwgIkludmFsaWQgWTciOiAi
-    ###N3YvLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8zOD0i
-    ###LCAiSW52YWxpZCBZOCI6ICIyLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
-    ###Ly8vLy8vLy8vLy8vLy84PSIsICJJbnZhbGlkIFk5IjogIjJmLy8vLy8vLy8v
-    ###Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLzg9IiwgIkludmFsaWQg
-    ###WTEwIjogInpldDZmRHRCdUs0V1Z1UDY4Wi9FYXRvSmpldWNNckg5aG1JRkZs
-    ###OUp1SUE9IiwgIkludmFsaWQgWTExIjogIlRKeVZ2S05RakNTeDBMRlZuSVB2
-    ###V3dSRVhNUllISTZHMkNKTzNkQ2ZFZGM9In0=
+    ###eyJJbnZhbGlkIFkwIjogWzAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAs
+    ###IDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAs
+    ###IDAsIDAsIDAsIDAsIDAsIDAsIDBdLCAiSW52YWxpZCBZMSI6IFsxLCAwLCAw
+    ###LCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAw
+    ###LCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwXSwg
+    ###IkludmFsaWQgWTIiOiBbMjM2LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwg
+    ###MjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwg
+    ###MjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwg
+    ###MjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAxMjddLCAiSW52
+    ###YWxpZCBZMyI6IFsyMjQsIDIzNSwgMTIyLCAxMjQsIDU5LCA2NSwgMTg0LCAx
+    ###NzQsIDIyLCA4NiwgMjI3LCAyNTAsIDI0MSwgMTU5LCAxOTYsIDEwNiwgMjE4
+    ###LCA5LCAxNDEsIDIzNSwgMTU2LCA1MCwgMTc3LCAyNTMsIDEzNCwgOTgsIDUs
+    ###IDIyLCA5NSwgNzMsIDE4NCwgMF0sICJJbnZhbGlkIFk0IjogWzk1LCAxNTYs
+    ###IDE0OSwgMTg4LCAxNjMsIDgwLCAxNDAsIDM2LCAxNzcsIDIwOCwgMTc3LCA4
+    ###NSwgMTU2LCAxMzEsIDIzOSwgOTEsIDQsIDY4LCA5MiwgMTk2LCA4OCwgMjgs
+    ###IDE0MiwgMTM0LCAyMTYsIDM0LCA3OCwgMjIxLCAyMDgsIDE1OSwgMTcsIDg3
+    ###XSwgIkludmFsaWQgWTUiOiBbMjM3LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1
+    ###NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1
+    ###NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1
+    ###NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAxMjddLCAi
+    ###SW52YWxpZCBZNiI6IFsyMTgsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAy
+    ###NTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAy
+    ###NTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAy
+    ###NTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NV0sICJJbnZh
+    ###bGlkIFk3IjogWzIzOCwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwg
+    ###MjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwg
+    ###MjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwg
+    ###MjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMTI3XSwgIkludmFsaWQg
+    ###WTgiOiBbMjE5LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUs
+    ###IDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUs
+    ###IDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUs
+    ###IDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTVdLCAiSW52YWxpZCBZOSI6
+    ###IFsyMTcsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1
+    ###LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1
+    ###LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1
+    ###LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NV0sICJJbnZhbGlkIFkxMCI6IFsy
+    ###MDUsIDIzNSwgMTIyLCAxMjQsIDU5LCA2NSwgMTg0LCAxNzQsIDIyLCA4Niwg
+    ###MjI3LCAyNTAsIDI0MSwgMTU5LCAxOTYsIDEwNiwgMjE4LCA5LCAxNDEsIDIz
+    ###NSwgMTU2LCA1MCwgMTc3LCAyNTMsIDEzNCwgOTgsIDUsIDIyLCA5NSwgNzMs
+    ###IDE4NCwgMTI4XSwgIkludmFsaWQgWTExIjogWzc2LCAxNTYsIDE0OSwgMTg4
+    ###LCAxNjMsIDgwLCAxNDAsIDM2LCAxNzcsIDIwOCwgMTc3LCA4NSwgMTU2LCAx
+    ###MzEsIDIzOSwgOTEsIDQsIDY4LCA5MiwgMTk2LCA4OCwgMjgsIDE0MiwgMTM0
+    ###LCAyMTYsIDM0LCA3OCwgMjIxLCAyMDgsIDE1OSwgMTcsIDIxNV19
 
 ~~~
 
@@ -2026,6 +2079,78 @@ Test vectors for scalar_mult with nonzero outputs
     50ffd9a9148a9b75c349fac43d64bec49a6e126cc92cbfbf353961
 ~~~
 
+
+####  Testvectors as JSON file encoded as BASE64
+
+~~~
+
+    ###eyJJbnZhbGlkIFkxIjogWzAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAs
+    ###IDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAs
+    ###IDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAs
+    ###IDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAs
+    ###IDBdLCAiSW52YWxpZCBZMiI6IFsxLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAw
+    ###LCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAw
+    ###LCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAw
+    ###LCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAw
+    ###LCAwLCAwXSwgIkludmFsaWQgWTMiOiBbMjU0LCAyNTUsIDI1NSwgMjU1LCAy
+    ###NTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAy
+    ###NTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAy
+    ###NTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTQsIDI1NSwgMjU1LCAy
+    ###NTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAy
+    ###NTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAy
+    ###NTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTVdLCAiSW52YWxpZCBZ
+    ###NCI6IFsyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwg
+    ###MjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwg
+    ###MjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwg
+    ###MjU1LCAyNTUsIDI1NCwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwg
+    ###MjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwg
+    ###MjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwg
+    ###MjU1LCAyNTUsIDI1NV0sICJJbnZhbGlkIFk1IjogWzAsIDAsIDAsIDAsIDAs
+    ###IDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAs
+    ###IDAsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDI1NSwgMjU1LCAyNTUsIDI1NSwg
+    ###MjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwg
+    ###MjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NSwg
+    ###MjU1LCAyNTUsIDI1NSwgMjU1LCAyNTUsIDI1NV0sICJWYWxpZCAob24gY3Vy
+    ###dmUpIjogeyJzIjogWzE3NSwgMTM4LCAyMCwgMzMsIDEzOSwgMjQyLCAxNjIs
+    ###IDYsIDQxLCAzOCwgMjEwLCAyMzQsIDE1NSwgMTQzLCAyMjgsIDIzMiwgMTgy
+    ###LCAxMjksIDExNSwgNzMsIDE4MiwgMjM3LCA0NywgMjM1LCAzMCwgOTMsIDEw
+    ###MCwgMjE1LCAxNjQsIDgyLCA2MywgMjEsIDI1MiwgMjM4LCAxOTksIDE1LCAx
+    ###NzcsIDE3LCAyMzIsIDExMiwgMjIwLCA4OCwgMjA5LCAxNDUsIDIzMCwgMTA2
+    ###LCAyMCwgMjExLCAyMzMsIDIxMiwgMTMwLCAyMDgsIDY4LCA1MCwgMjAyLCAy
+    ###MjFdLCAidV9jdXJ2ZSI6IFsxNzEsIDEyLCAxMDQsIDIxNSwgMTE0LCAyMzYs
+    ###IDQ2LCAxODUsIDIyMiwgMzcsIDE5NiwgMTUxLCAwLCAyMjgsIDEwOSwgOTks
+    ###IDM3LCAyMzAsIDEwOSwgMTA2LCAxNjMsIDE1NywgMTIzLCAxMDEsIDIzNSwg
+    ###MTMyLCAxNjYsIDE0MCwgODUsIDEwNSwgMjEyLCAxMjMsIDIxNSwgMjcsIDY1
+    ###LCAyNDMsIDIyNCwgMjEwLCAxNiwgMjQ0LCA3OCwgMjAsIDEwOSwgMjM2LCAx
+    ###MzcsIDM4LCAxNzcsIDExNiwgMTcyLCAxNzksIDI0OSwgNjQsIDE2MCwgMTg0
+    ###LCA0NCwgMTcxXSwgInJlc19jdXJ2ZSI6IFs1OSwgMTUsIDE2OSwgMTg4LCA2
+    ###NCwgMTY2LCAyNTMsIDE5OSwgMTQwLCAxNTgsIDYsIDI1NSwgMTIyLCA4NCwg
+    ###MTkzLCA2NywgMTk3LCAyMTMsIDQ3LCA1NCwgODYsIDcsIDUsIDU5LCAyNDAs
+    ###IDEwMSwgMTExLCA4MSwgNjYsIDQsIDE1MCwgNDEsIDk1LCAxNDUsIDEwLCAx
+    ###NiwgMjcsIDU2LCAyMzcsIDE5MywgMTcyLCAyMTEsIDE4OSwgMzYsIDE1LCAy
+    ###MTMsIDkzLCAyMDMsIDEyMiwgNTQsIDUsIDgzLCAxODQsIDE2NywgOTgsIDEy
+    ###Nl19LCAiVmFsaWQgKG9uIHR3aXN0KSI6IHsicyI6IFsxNzUsIDEzOCwgMjAs
+    ###IDMzLCAxMzksIDI0MiwgMTYyLCA2LCA0MSwgMzgsIDIxMCwgMjM0LCAxNTUs
+    ###IDE0MywgMjI4LCAyMzIsIDE4MiwgMTI5LCAxMTUsIDczLCAxODIsIDIzNywg
+    ###NDcsIDIzNSwgMzAsIDkzLCAxMDAsIDIxNSwgMTY0LCA4MiwgNjMsIDIxLCAy
+    ###NTIsIDIzOCwgMTk5LCAxNSwgMTc3LCAxNywgMjMyLCAxMTIsIDIyMCwgODgs
+    ###IDIwOSwgMTQ1LCAyMzAsIDEwNiwgMjAsIDIxMSwgMjMzLCAyMTIsIDEzMCwg
+    ###MjA4LCA2OCwgNTAsIDIwMiwgMjIxXSwgInVfdHdpc3QiOiBbMjAxLCAxMjks
+    ###IDIwNSwgMzAsIDMxLCAxMTQsIDIxNywgMTk1LCA5MiwgMTI1LCAxMjQsIDI0
+    ###NiwgMTkwLCA2NiwgMTAzLCA4NywgMTkyLCAyMjAsIDEzMCwgNiwgMTYyLCAy
+    ###NTIsIDI1MCwgODYsIDc0LCAxNDIsIDExOCwgMjQsIDE5MiwgNjAsIDE0LCA5
+    ###NywgMjQ5LCAxNjIsIDIzNSwgMjgsIDYyLCAxMywgMjE3LCAxMjUsIDExMCwg
+    ###MTU1LCAxNiwgMTYsIDI0NSwgMjM3LCAyMDgsIDUxLCAxNTEsIDE2OCwgNjMs
+    ###IDkwLCAxNDUsIDc2LCAxNzksIDI1NV0sICJyZXNfdHdpc3QiOiBbMjA4LCAx
+    ###NjIsIDE4NywgMTI2LCAxNTYsIDkyLCA0NCwgOTgsIDExOSwgMTQ3LCAyMTYs
+    ###IDUyLCA0NywgMzUsIDE4MywgODksIDI1NCwgMTI1LCAxNTgsIDUxLCAzMiwg
+    ###MTY4LCA5MiwgMTY0LCAyNTMsIDk3LCA1NSwgOTksIDQ5LCA4MCwgMjU1LCAy
+    ###MTcsIDE2OSwgMjAsIDEzOCwgMTU1LCAxMTcsIDE5NSwgNzMsIDI1MCwgMTk2
+    ###LCA2MSwgMTAwLCAxOTAsIDE5NiwgMTU0LCAxMTAsIDE4LCAxMDgsIDIwMSwg
+    ###NDQsIDE5MSwgMTkxLCA1MywgNTcsIDk3XX19
+
+~~~
+
 ##  Test vector for CPace using group ristretto255 and hash SHA-512