idnits 2.17.1 draft-ietf-jose-cfrg-curves-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 7, 2016) is 2850 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-THIS' is mentioned on line 317, but not defined ** Downref: Normative reference to an Informational RFC: RFC 7748 == Outdated reference: A later version (-08) exists of draft-irtf-cfrg-eddsa-05 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-eddsa (ref. 'I-D.irtf-cfrg-eddsa') Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Liusvaara 3 Internet-Draft Independent 4 Intended status: Standards Track July 7, 2016 5 Expires: January 8, 2017 7 CFRG ECDH and signatures in JOSE 8 draft-ietf-jose-cfrg-curves-04 10 Abstract 12 This document defines how to use the Diffie-Hellman algorithms 13 "X25519" and "X448" as well as the signature algorithms "Ed25519" and 14 "Ed448" from the IRTF CFRG elliptic curves work in JOSE. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 8, 2017. 33 Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Key type "OKP" . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. Signatures . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.1.1. Signing . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1.2. Verification . . . . . . . . . . . . . . . . . . . . 4 57 3.2. ECDH-ES . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.2.1. Performing the ECDH Operation . . . . . . . . . . . . 5 59 4. Security considerations . . . . . . . . . . . . . . . . . . . 5 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 61 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 64 7.2. Informative References . . . . . . . . . . . . . . . . . 8 65 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 8 66 A.1. Ed25519 Private Key . . . . . . . . . . . . . . . . . . . 8 67 A.2. Ed25519 Public Key . . . . . . . . . . . . . . . . . . . 9 68 A.3. JWK Thumbprint Canonicalization . . . . . . . . . . . . . 9 69 A.4. Ed25519 Signing . . . . . . . . . . . . . . . . . . . . . 9 70 A.5. Ed25519 Validation . . . . . . . . . . . . . . . . . . . 10 71 A.6. ECDH-ES with X25519 . . . . . . . . . . . . . . . . . . . 11 72 A.7. ECDH-ES with X448 . . . . . . . . . . . . . . . . . . . . 12 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 75 1. Introduction 77 Internet Research Task Force (IRTF) Crypto Forum Research Group 78 (CFRG) selected new Diffie-Hellman algorithms ("X25519" and "X448"; 79 [RFC7748]) and signature algorithms ("Ed25519" and "Ed448"; 80 [I-D.irtf-cfrg-eddsa]) for asymmetric key cryptography. This 81 document defines how those algorithms are to be used in JOSE in 82 interoperable manner. 84 This document defines the conventions to be used in the context of 85 [RFC7515], [RFC7516] and [RFC7517]. 87 While the CFRG also defined two pairs of isogenous elliptic curves 88 that underlie these algorithms, these curves are not directly 89 exposed, as the algorithms laid on top are sufficient for the 90 purposes of JOSE and are much easier to use. (Trying to apply ECDSA 91 to those curves leads to nasty corner-cases and produces odd 92 results.) 93 All inputs to and outputs from the the ECDH and signature functions 94 are defined to be octet strings, with the exception of outputs of 95 verification function, which are booleans. 97 1.1. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 "JWS Signing Input" and "JWS Signature" are defined by [RFC7515] 105 "Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static" 106 is defined by [RFC7518], section 4.6 108 The JOSE key format ("JSON Web Key (JWK)") is defined by [RFC7517], 109 and thumbprints for it ("JSON Web Key (JWK) Thumbprint") in 110 [RFC7638]. 112 2. Key type "OKP" 114 A new key type (kty) value "OKP" (Octet Key Pair) is defined for 115 public key algorithms that use octet strings as private and public 116 keys. It has the following parameters: 118 o The parameter "kty" MUST be "OKP". 120 o The parameter "crv" MUST be present and contain the subtype of the 121 key (from "JSON Web Elliptic Curve" registry). 123 o The parameter "x" MUST be present and contain the public key 124 encoded using the base64url [RFC4648] encoding. 126 o The parameter "d" MUST be present for private keys and contain the 127 private key encoded using the base64url encoding. This parameter 128 MUST NOT be present for public keys. 130 Note: Do not assume that there is an underlying elliptic curve, 131 despite the existence of the "crv" and "x" parameters. (For 132 instance, this key type could be extended to represent DH algorithms 133 based on hyperelliptic surfaces.) 135 When calculating JWK Thumbprints [RFC7638], the three public key 136 fields are included in the hash input lexicographic order: "crv", 137 "kty", and "x". 139 3. Algorithms 141 3.1. Signatures 143 For purpose of using EdDSA for signing data using "JSON Web Signature 144 (JWS)" ([RFC7515]), algorithm "EdDSA" is defined here, to be applied 145 as value of "alg" parameter. 147 The following key subtypes are defined here for use with EdDSA. 149 "crv" EdDSA Variant 150 Ed25519 Ed25519 151 Ed448 Ed448 153 The key type used with these keys is "OKP" and the algorithm used for 154 signing is "EdDSA". These subtypes MUST NOT be used for ECDH-ES. 156 The EdDSA variant used is determined by the subtype of the key 157 (Ed25519 for "Ed25519" and Ed448 for "Ed448"). 159 3.1.1. Signing 161 Signing for these is preformed by applying the signing algorithm 162 defined in [I-D.irtf-cfrg-eddsa] to the private key (as private key), 163 public key (as public key) and the JWS Signing Input (as message). 164 The resulting signature is the JWS Signature. All inputs and outputs 165 are octet strings. 167 3.1.2. Verification 169 Verification is performed by applying the verification algorithm 170 defined in [I-D.irtf-cfrg-eddsa] to the public key (as public key), 171 the JWS Signing Input (as message) and the JWS Signature (as 172 signature). All inputs are octet strings. If the algorithm accepts, 173 the signature is valid; otherwise, the signature is invalid. 175 3.2. ECDH-ES 177 The following key subtypes are defined here for purpose of "Key 178 Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static" (ECDH- 179 ES). 181 "crv" ECDH Function Applied 182 X25519 X25519 183 X448 X448 185 The key type used with these keys is "OKP". These subtypes MUST NOT 186 be used for signing. 188 [RFC7518] Section 4.6 defines the ECDH-ES algorithms "ECDH- 189 ES+A128KW", "ECDH-ES+A192KW", "ECDH-ES+A256KW" and "ECDH-ES". 191 3.2.1. Performing the ECDH Operation 193 The "x" parameter of the "epk" field is set as follows: 195 Apply the appropriate ECDH function to the ephemeral private key (as 196 scalar input) and the standard basepoint (as u-coordinate input). 197 The base64url encoding of the output is the value for the "x" 198 parameter of the "epk" field. All inputs and outputs are octet 199 strings. 201 The Z value (raw key agreement output) for key agreement (to be used 202 in subsequent KDF as per [RFC7518] section 4.6.2) is determined as 203 follows: 205 Apply the appropriate ECDH function to the ephemeral private key (as 206 scalar input) and receiver public key (as u-coordinate input). The 207 output is the Z value. All inputs and outputs are octet strings. 209 4. Security considerations 211 Security considerations from [RFC7748] and [I-D.irtf-cfrg-eddsa] 212 apply here. 214 Do not separate key material from information about what key subtype 215 it is for. When using keys, check that the algorithm is compatible 216 with the key subtype for the key. To do otherwise opens the system 217 up to attacks via mixing up algorithms. It is particularly dangerous 218 to mix up signature and MAC algorithms. 220 Although for Ed25519 and Ed448, the signature binds the key used for 221 signing, do not assume this, as there are many signature algorithms 222 that fail to make such a binding. If key-binding is desired, include 223 the key used for signing either inside the JWS protected header or 224 the data to sign. 226 If key generation or batch signature verification is performed, a 227 well-seeded cryptographic random number generator is REQUIRED. 228 Signing and non-batch signature verification are deterministic 229 operations and do not need random numbers of any kind. 231 The JWA ECDH-ES KDF construction does not mix keys into the final 232 shared secret. While in key exchange such could be a bad mistake, 233 here either the receiver public key has to be chosen maliciously or 234 the sender has to be malicious in order to cause problems. In either 235 case, all security evaporates. 237 The nominal security strengths of X25519 and X448 are ~126 and ~223 238 bits. Therefore, using 256-bit symmetric encryption (especially key 239 wrapping and encryption) with X448 is RECOMMENDED. 241 5. Acknowledgements 243 Thanks to Michael B. Jones for his comments on an initial pre-draft 244 and editorial help. 246 Thanks to Matt Miller for some editorial help. 248 6. IANA considerations 250 The following is added to the "JSON Web Key Types" registry: 252 o "kty" Parameter Value: "OKP" 253 o Key Type Description: Octet string key pairs 254 o JOSE Implementation Requirements: Optional 255 o Change Controller: IESG 256 o Specification Document(s): Section 2 of [RFC-THIS] 258 The following is added to the "JSON Web Key Parameters" registry: 260 o Parameter Name: "crv" 261 o Parameter Description: The subtype of keypair 262 o Parameter Information Class: Public 263 o Used with "kty" Value(s): "OKP" 264 o Change Controller: IESG 265 o Specification Document(s): Section 2 of [RFC-THIS] 267 o Parameter Name: "d" 268 o Parameter Description: The private key 269 o Parameter Information Class: Private 270 o Used with "kty" Value(s): "OKP" 271 o Change Controller: IESG 272 o Specification Document(s): Section 2 of [RFC-THIS] 274 o Parameter Name: "x" 275 o Parameter Description: The public key 276 o Parameter Information Class: Public 277 o Used with "kty" Value(s): "OKP" 278 o Change Controller: IESG 279 o Specification Document(s): Section 2 of [RFC-THIS] 281 The following is added to the "JSON Web Signature and Encryption 282 Algorithms" registry: 284 o Algorithm Name: "EdDSA" 285 o Algorithm Description: EdDSA signature algorithms 286 o Algorithm Usage Location(s): "alg" 287 o JOSE Implementation Requirements: Optional 288 o Change Controller: IESG 289 o Specification Document(s): Section 3 of [RFC-THIS] 290 o Algorithm Analysis Documents(s): [I-D.irtf-cfrg-eddsa] 292 The following is added to the "JSON Web Key Elliptic Curve" registry: 294 o Curve Name: "Ed25519" 295 o Curve Description: Ed25519 signature algorithm keypairs 296 o JOSE Implementation Requirements: Optional 297 o Change Controller: IESG 298 o Specification Document(s): Section 3 of [RFC-THIS] 300 o Curve Name: "Ed448" 301 o Curve Description: Ed448 signature algorithm keypairs 302 o JOSE Implementation Requirements: Optional 303 o Change Controller: IESG 304 o Specification Document(s): Section 3 of [RFC-THIS] 306 o Curve name: "X25519" 307 o Curve Description: X25519 function keypairs 308 o JOSE Implementation Requirements: Optional 309 o Change Controller: IESG 310 o Specification Document(s): Section 3.2 of [RFC-THIS] 311 o Analysis Documents(s): [RFC7748] 313 o Curve Name: "X448" 314 o Curve Description: X448 function keypairs 315 o JOSE Implementation Requirements: Optional 316 o Change Controller: IESG 317 o Specification Document(s): Section 3.2 of [RFC-THIS] 318 o Analysis Documents(s): [RFC7748] 320 7. References 322 7.1. Normative References 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, 326 DOI 10.17487/RFC2119, March 1997, 327 . 329 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 330 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 331 . 333 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 334 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 335 2015, . 337 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 338 DOI 10.17487/RFC7517, May 2015, 339 . 341 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 342 DOI 10.17487/RFC7518, May 2015, 343 . 345 [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) 346 Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 347 2015, . 349 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 350 for Security", RFC 7748, DOI 10.17487/RFC7748, January 351 2016, . 353 [I-D.irtf-cfrg-eddsa] 354 Josefsson, S. and I. Liusvaara, "Edwards-curve Digital 355 Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-05 356 (work in progress), March 2016. 358 7.2. Informative References 360 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 361 RFC 7516, DOI 10.17487/RFC7516, May 2015, 362 . 364 Appendix A. Examples 366 To the extent possible, the examples use material taken from test 367 vectors of [RFC7748] and [I-D.irtf-cfrg-eddsa]. 369 A.1. Ed25519 Private Key 371 {"kty":"OKP","crv":"Ed25519", 372 "d":"nWGxne_9WmC6hEr0kuwsxERJxWl7MmkZcDusAxyuf2A" 373 "x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"} 375 The hexadecimal dump of private key is: 377 9d 61 b1 9d ef fd 5a 60 ba 84 4a f4 92 ec 2c c4 378 44 49 c5 69 7b 32 69 19 70 3b ac 03 1c ae 7f 60 380 And of the public key is: 382 d7 5a 98 01 82 b1 0a b7 d5 4b fe d3 c9 64 07 3a 383 0e e1 72 f3 da a6 23 25 af 02 1a 68 f7 07 51 1a 385 A.2. Ed25519 Public Key 387 This is the public parts of the previous private key (which just 388 omits "d"): 390 {"kty":"OKP","crv":"Ed25519", 391 "x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"} 393 A.3. JWK Thumbprint Canonicalization 395 The JWK Thumbprint canonicalization of the two above examples (with 396 linebreak inserted for formatting reasons) is: 398 {"crv":"Ed25519","kty":"OKP","x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwI 399 aaPcHURo"} 401 Which has the SHA-256 hash (in hexadecimal) of 402 90facafea9b1556698540f70c0117a22ea37bd5cf3ed3c47093c1707282b4b89, 403 which results in the base64url encoded JWK Thumbprint representation 404 of "kPrK_qmxVWaYVA9wwBF6Iuo3vVzz7TxHCTwXBygrS4k". 406 A.4. Ed25519 Signing 408 The JWS protected header is: 410 {"alg":"EdDSA"} 412 This has the base64url encoding of: 414 eyJhbGciOiJFZERTQSJ9 416 The payload is (text): 418 Example of Ed25519 signing 420 This has the base64url encoding of: 422 RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc 424 The JWS signing input is (concatenation of base64url encoding of the 425 (protected) header, a dot and base64url encoding of the payload) is: 427 eyJhbGciOiJFZERTQSJ9.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc 428 Applying the Ed25519 signing algorithm using the private key, public 429 key, and the JWS signing input yields the signature (hex): 431 86 0c 98 d2 29 7f 30 60 a3 3f 42 73 96 72 d6 1b 432 53 cf 3a de fe d3 d3 c6 72 f3 20 dc 02 1b 41 1e 433 9d 59 b8 62 8d c3 51 e2 48 b8 8b 29 46 8e 0e 41 434 85 5b 0f b7 d8 3b b1 5b e9 02 bf cc b8 cd 0a 02 436 Converting this to base64url yields: 438 hgyY0il_MGCjP0JzlnLWG1PPOt7-09PGcvMg3AIbQR6dWbhijcNR4ki4iylGjg5BhVsPt 439 9g7sVvpAr_MuM0KAg 441 So the compact serialization of the JWS is (concatenation of signing 442 input, a dot, and base64url encoding of the signature): 444 eyJhbGciOiJFZERTQSJ9.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc.hgyY0il_MGCj 445 P0JzlnLWG1PPOt7-09PGcvMg3AIbQR6dWbhijcNR4ki4iylGjg5BhVsPt9g7sVvpAr_Mu 446 M0KAg 448 A.5. Ed25519 Validation 450 The JWS from above example is: 452 eyJhbGciOiJFZERTQSJ9.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc.hgyY0il_MGCj 453 P0JzlnLWG1PPOt7-09PGcvMg3AIbQR6dWbhijcNR4ki4iylGjg5BhVsPt9g7sVvpAr_Mu 454 M0KAg 456 This has 2 dots in it, so it might be valid a JWS. Base64url 457 decoding the protected header yields: 459 {"alg":"EdDSA"} 461 So this is an EdDSA signature. Now the key has: "kty":"OKP" and 462 "crv":"Ed25519", so the signature is Ed25519 signature. 464 The signing input is the part before second dot: 466 eyJhbGciOiJFZERTQSJ9.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc 468 Applying Ed25519 verification algorithm to the public key, JWS 469 signing input and the signature yields true. So the signature is 470 valid. The message is the base64url decoding of the part between the 471 dots: 473 Example of Ed25519 Signing 475 A.6. ECDH-ES with X25519 477 The public key to encrypt to is: 479 {"kty":"OKP","crv":"X25519","kid":"Bob" 480 "x":"3p7bfXt9wbTTW2HC7OQ1Nz-DQ8hbeGdNrfx-FG-IK08"} 482 The public key from the target key is (hex): 484 de 9e db 7d 7b 7d c1 b4 d3 5b 61 c2 ec e4 35 37 485 3f 83 43 c8 5b 78 67 4d ad fc 7e 14 6f 88 2b 4f 487 The ephemeral secret happens to be (hex): 489 77 07 6d 0a 73 18 a5 7d 3c 16 c1 72 51 b2 66 45 490 df 4c 2f 87 eb c0 99 2a b1 77 fb a5 1d b9 2c 2a 492 So the ephemeral public key is X25519(ephkey,G) (hex): 494 85 20 f0 09 89 30 a7 54 74 8b 7d dc b4 3e f7 5a 495 0d bf 3a 0d 26 38 1a f4 eb a4 a9 8e aa 9b 4e 6a 497 This is represented as the ephemeral public key value: 499 {"kty":"OKP","crv":"X25519", 500 "x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"} 502 So the protected header could, for example, be: 504 {"alg":"ECDH-ES+A128KW","epk":{"kty":"OKP","crv":"X25519", 505 "x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"}, 506 "enc":"A128GCM","kid":"Bob"} 508 And the sender computes as the DH Z value as X25519(ephkey,recv_pub) 509 (hex): 511 4a 5d 9d 5b a4 ce 2d e1 72 8e 3b f4 80 35 0f 25 512 e0 7e 21 c9 47 d1 9e 33 76 f0 9b 3c 1e 16 17 42 514 The receiver computes as the DH Z value as X25519(seckey,ephkey_pub) 515 (hex): 517 4a 5d 9d 5b a4 ce 2d e1 72 8e 3b f4 80 35 0f 25 518 e0 7e 21 c9 47 d1 9e 33 76 f0 9b 3c 1e 16 17 42 520 Which is the same as the sender's value (the both sides run this 521 through the KDF before using it as a direct encryption key or 522 AES128-KW key). 524 A.7. ECDH-ES with X448 526 The public key to encrypt to (with linebreak inserted for formatting 527 reasons) is: 529 {"kty":"OKP","crv":"X448","kid":"Dave", 530 "x":"PreoKbDNIPW8_AtZm2_sz22kYnEHvbDU80W0MCfYuXL8PjT7QjKhPKcG3LV67D2 531 uB73BxnvzNgk"} 533 The public key from target key is (hex): 535 3e b7 a8 29 b0 cd 20 f5 bc fc 0b 59 9b 6f ec cf 536 6d a4 62 71 07 bd b0 d4 f3 45 b4 30 27 d8 b9 72 537 fc 3e 34 fb 42 32 a1 3c a7 06 dc b5 7a ec 3d ae 538 07 bd c1 c6 7b f3 36 09 540 The ephemeral secret happens to be (hex): 542 9a 8f 49 25 d1 51 9f 57 75 cf 46 b0 4b 58 00 d4 543 ee 9e e8 ba e8 bc 55 65 d4 98 c2 8d d9 c9 ba f5 544 74 a9 41 97 44 89 73 91 00 63 82 a6 f1 27 ab 1d 545 9a c2 d8 c0 a5 98 72 6b 547 So the ephemeral public key is X448(ephkey,G) (hex): 549 9b 08 f7 cc 31 b7 e3 e6 7d 22 d5 ae a1 21 07 4a 550 27 3b d2 b8 3d e0 9c 63 fa a7 3d 2c 22 c5 d9 bb 551 c8 36 64 72 41 d9 53 d4 0c 5b 12 da 88 12 0d 53 552 17 7f 80 e5 32 c4 1f a0 554 This is packed into ephemeral public key value (linebreak inserted 555 for formatting purposes): 557 {"kty":"OKP","crv":"X448", 558 "x":"mwj3zDG34-Z9ItWuoSEHSic70rg94Jxj-qc9LCLF2bvINmRyQdlT1AxbEtqIEg1 559 TF3-A5TLEH6A"} 561 So the protected header could for example be (linebreak inserted for 562 formatting purposes): 564 {"alg":"ECDH-ES+A256KW","epk":{"kty":"OKP","crv":"X448", 565 "x":"mwj3zDG34-Z9ItWuoSEHSic70rg94Jxj-qc9LCLF2bvINmRyQdlT1AxbEtqIEg1 566 TF3-A5TLEH6A"},"enc":"A256GCM","kid":"Dave"} 568 And the sender computes as the DH Z value as X448(ephkey,recv_pub) 569 (hex): 571 07 ff f4 18 1a c6 cc 95 ec 1c 16 a9 4a 0f 74 d1 572 2d a2 32 ce 40 a7 75 52 28 1d 28 2b b6 0c 0b 56 573 fd 24 64 c3 35 54 39 36 52 1c 24 40 30 85 d5 9a 574 44 9a 50 37 51 4a 87 9d 576 The receiver computes as the DH Z value as X448(seckey,ephkey_pub) 577 (hex): 579 07 ff f4 18 1a c6 cc 95 ec 1c 16 a9 4a 0f 74 d1 580 2d a2 32 ce 40 a7 75 52 28 1d 28 2b b6 0c 0b 56 581 fd 24 64 c3 35 54 39 36 52 1c 24 40 30 85 d5 9a 582 44 9a 50 37 51 4a 87 9d 584 Which is the same as the sender's value (the both sides run this 585 through KDF before using as direct encryption key or AES256-KW key). 587 Author's Address 589 Ilari Liusvaara 590 Independent 592 Email: ilariliusvaara@welho.com