[CFRG] Re: Where should test vectors live?

[Björn Haase <[e-mail]>]

Hy Carsten,

thank you for the pointer. It seems that actually the line-wrap seemingly *is* handled already with the kramdown environment we are currently using.
I.e. we actually could add longer lines that automatically get wrapped.
However, we might get problems with automatically reading the wrapped text result automatically for re-constructing the test vectors.

My present idea is that for the time being, we might be best off with not directly including JSON but including BASE64-Snipplets encoding the JSON files as part of the appendix subsections:

One might be first have a section for the "humans" with a hex encoding of the test vectors followed by a section with the
corresponding data with a base64 encoding of a JSON dictionary.

I.e. in addition to a human readable section like

Inputs
    H   = SHA-512 with input block size 128 bytes.
    PRS = b'Password' ; ZPAD length: 109 ; DSI = b'CPace255'
    CI = b'oc\x0bB_responder\x0bA_initiator'
    CI = 6f630b425f726573706f6e6465720b415f696e69746961746f72
    sid = 7e4b4791d6a8ef019b936c79fb7f2c57
Intermediate results:
    generator_string(G.DSI,PRS,CI,sid,H.s_in_bytes):
    (length: 172 bytes)
      0843506163653235350850617373776f72646d000000000000000000
      00000000000000000000000000000000000000000000000000000000
      00000000000000000000000000000000000000000000000000000000
      00000000000000000000000000000000000000000000000000000000
      000000000000000000000000000000001a6f630b425f726573706f6e
      6465720b415f696e69746961746f72107e4b4791d6a8ef019b936c79
      fb7f2c57
    hash generator string: (length: 32 bytes)
      92806dc608984dbf4e4aae478c6ec453ae979cc01ecc1a2a7cf49f5c
      ee56551b
    decoded field element of 255 bits: (length: 32 bytes)
      92806dc608984dbf4e4aae478c6ec453ae979cc01ecc1a2a7cf49f5c
      ee56551b
  Outputs:
    generator g: (length: 32 bytes)
      64e8099e3ea682cfdc5cb665c057ebb514d06bf23ebc9f743b51b822
      42327074


One would first generate a json file with the corresponding test vectors (which cannot be integrated as-is in an RFC)

{
    "PRS": "UGFzc3dvcmQ=",
    "CI": "b2MLQl9yZXNwb25kZXILQV9pbml0aWF0b3I=",
    "sid": "fktHkdao7wGbk2x5+38sVw==",
    "g": "ZOgJnj6mgs/cXLZlwFfrtRTQa/I+vJ90O1G4IkIycHQ=",
}

As the JSON encoding might have too long lines, one would not be adding the plain JSON file but a base64 encoding of the above JSON file, such as

  ### Cgp7CiAgICAiUFJTIjogIlVHRnpjM2R2Y21RPSIsCiAgICAiQ0kiOiAiYjJNTFFsOXlaWE
  ### 53YjI1a1pYSUxRVjlwYm1sMGFXRjBiM0k9IiwKICAgICJzaWQiOiAiZmt0SGtkYW83d0di
  ### azJ4NSszOHNWdz09IiwKICAgICJnIjogIlpPZ0puajZtZ3MvY1hMWmx3RmZydFJUUWEvSS
  ### t2SjkwTzFHNElrSXljSFE9IiwKfQogIAo=

.

The advantage of doing so is that it is completely clear from the human-readable context for *which* actual
cipher suite or settings the test vectors apply. The end-user has a binary encoding at hand that can be made
easily machine-readable.

JSON seems to be the most portable format. In case of CPace I already have received requests for JSON test vectors.

What do you think? Does anybody wee a way to avoid the additional Base64 encoding layer, such that JSON
Content could be directly integrated in a RFC as-is?

Yours,

Björn




Mit freundlichen Grüßen | Best Regards 

Dr. Björn Haase 


Senior Expert Electronics | TGREH Electronics Hardware

Endress+Hauser Liquid Analysis

Endress+Hauser Conducta GmbH+Co. KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
Phone: [phone]
[e-mail] |  www.ehla.endress.com 





Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella

 
Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (https://www.endress.com/de/cookies-endress+hauser-website) nach.

 



Disclaimer: 

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.
 


-----Ursprüngliche Nachricht-----
Von: Carsten Bormann <[e-mail]>
Gesendet: Freitag, 20. September 2024 09:27
An: Björn Haase <[e-mail]>
Cc: Watson Ladd <[e-mail]>; Christopher Patton <[e-mail]>; CFRG <[e-mail]>
Betreff: Re: [CFRG] Where should test vectors live?

On 20. Sep 2024, at 08:49, Björn Haase <bjoern.haase=[e-mail]> wrote:
>
> So far we have integrated ANSI-C test vectors in the draft. I did try to do similarly for JSON, however it seems that for JSON we will not be able to follow the “max number of characters per line” requirement
> for I-D and RFC.

You can use RFC 8792 to handle that requirement.
(kramdown-rfc-extract-sourcecode automatically reverses that processing, and kramdown-rfc has several ways to automatically apply the processing where needed only.)

Grüße, Carsten

[1]: https://www.rfc-editor.org/rfc/rfc8792
"RFC 8792: Handling Long Lines in Content of Internet-Drafts and RFCs”