idnits 2.17.1 draft-liusvaara-jose-cfrg-curves-00.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 (December 9, 2015) is 3058 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 330, but not defined ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-curves (ref. 'I-D.irtf-cfrg-curves') == Outdated reference: A later version (-08) exists of draft-irtf-cfrg-eddsa-01 ** 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 December 9, 2015 5 Expires: June 11, 2016 7 CFRG curves and signatures in JOSE 8 draft-liusvaara-jose-cfrg-curves-00 10 Abstract 12 This document defines how to use curves and algorithms from IRTF CFRG 13 elliptic curves work (Diffie-Hellman and signatures) in JOSE. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on June 11, 2016. 32 Copyright Notice 34 Copyright (c) 2015 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 2 51 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Key type 'OKP' . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. Signatures . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1.1. Algorithms . . . . . . . . . . . . . . . . . . . . . 3 56 3.1.2. Signing . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1.3. Verification . . . . . . . . . . . . . . . . . . . . 4 58 3.2. ECDH-ES . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2.1. Performing the ECDH operation . . . . . . . . . . . . 4 60 4. Security considerations . . . . . . . . . . . . . . . . . . . 5 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 62 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 65 7.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 8 67 A.1. Ed25519 private key . . . . . . . . . . . . . . . . . . . 9 68 A.2. Ed25519 public key . . . . . . . . . . . . . . . . . . . 9 69 A.3. JWK thumbprint canonicalization . . . . . . . . . . . . . 9 70 A.4. Ed25519 Signing . . . . . . . . . . . . . . . . . . . . . 9 71 A.5. Ed25519 Validation . . . . . . . . . . . . . . . . . . . 10 72 A.6. ECDH-ES with X25519 . . . . . . . . . . . . . . . . . . . 11 73 A.7. ECDH-ES with X448 . . . . . . . . . . . . . . . . . . . . 12 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 Internet Research Task Force (IRTF) Crypto Forum Research Group 79 (CFRG) selected new elliptic curves and signature algorithms for 80 asymmetric key cryptography. This document defines how those curves 81 and algorithms are to be used in JOSE in interoperable manner. 83 This extends [RFC7517] and [RFC7518] 85 1.1. Requirements Terminology 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 1.2. Notation 93 All inputs to and outputs from the the ECDH and signature functions 94 are defined to be octet strings, with the exception of output of 95 verfication function, which is a boolean. 97 2. Key type 'OKP' 99 A new key type (kty) value "OKP" (Octet Key Pair) is defined for 100 public key algorithms that use octet strings as private and public 101 keys. It has the following parameters: 103 o The parameter "kty" MUST be "OKP". 105 o The parameter "crv" MUST be present, and contain the subtype of 106 the key (from "JSON Web Elliptic curve" registry). 108 o The parameter "x" MUST be present, and contain the public key 109 encoded using base64url [RFC4648] encoding. 111 o The parameter "d" MUST be present for private keys, and contain 112 the private key encoded using base64url encoding. This parameter 113 MUST NOT be present for public keys. 115 Note: Do not assume that there is an underlying elliptic curve, 116 despite the existence of the "crv" and "x" parameters. 118 When calculating thumbprints [RFC7638], the three public key fields 119 are included in the hash. That is, in lexographic order: "crv", 120 "kty" and "x". 122 3. Algorithms 124 3.1. Signatures 126 3.1.1. Algorithms 128 The following signature algorithms are defined here (to be applied as 129 values of "alg" parameter). All these have keys with subtype of the 130 same name: 132 alg value: subtype: The algorithm: 133 Ed25519 Ed25519 Ed25519 134 Ed25519ph Ed25519ph Ed25519ph 135 Ed448 Ed448 Ed448 136 Ed448ph Ed448ph Ed448ph 138 The key type for these keys is "OKP" and key subtype for these 139 algorithms MUST be the same as the algorithm name. 141 The keys of these subtypes MUST NOT be used for ECDH-ES. 143 [TBD: Merge the alg values into a single one that can perform signing 144 with any signature-capable OKP subtype? That would remove a source 145 of possible errors, since then the message and key could not mismatch 146 in algorithm.] 148 3.1.2. Signing 150 Signing for these is preformed by applying the signing algorithm 151 defined in [I-D.irtf-cfrg-eddsa] to the private key (as private key), 152 public key (as public key) and the JWS Signing Input (as message). 153 The resulting signature is the JWS Signature value. All inputs and 154 outputs are octet strings. 156 3.1.3. Verification 158 Verification is performed by applying the verification algorithm 159 defined in [I-D.irtf-cfrg-eddsa] to the public key (as public key), 160 the JWS Signing Input (as message) and the JWS Signature value (as 161 signature). All inputs are octet strings. If the algorithm accepts, 162 the signature is valid, otherwise it is invalid. 164 3.2. ECDH-ES 166 The following key subtypes defined here for purpose of ECDH-ES: 168 subtype: ECDH Function: 169 X25519 X25519 170 X448 X448 172 The key type used with these keys is "OKP". These subtypes MUST NOT 173 be used for signing. 175 3.2.1. Performing the ECDH operation 177 The "x" parameter of "epk" field is set as follows: 179 Apply the appropriate ECDH function to the ephemeral private key (as 180 scalar input) and the standard basepoint (as u-coordinate input). 181 The output is the value for "x" parameter of "epk" field. All inputs 182 and outputs are octet strings. 184 The Z value (raw key agreement output) for key agreement is 185 determined as follows: 187 Apply the appropriate ECDH function to the ephemeral private key (as 188 scalar input) and receiver public key (as u-coordinate input). The 189 output is the Z value. All inputs and outputs are octet strings. 191 4. Security considerations 193 Security considerations from [I-D.irtf-cfrg-curves] and 194 [I-D.irtf-cfrg-eddsa] apply here. 196 Some algorithms interact in bad ways (e.g. "Ed25519" and 197 "Ed25519ph"). For this reason, those algorithms have different 198 subtypes, so keys for each are not mixed up. 200 Do not separate key material from information what key algorithm 201 group it is for. When using keys, check that the algorithm is 202 compatible with the key algorithm group for the key. To do otherwise 203 opens system up to attacks via mixing up algorithms. It is 204 practicularly dangerous to mix up signature and MAC algorithms. 206 Do not assume that signature also binds the key used for signing, it 207 does not (there are also other widespread signature algorithms where 208 this binding fails, as such binding is not part of the definition of 209 secure signature primitive). As an example of such failure, the 210 Ed25519ph signature of X under key (Ed25519ph,Y) is identical to 211 Ed25519 signature of SHA512(X) under key (Ed25519,Y). And often it 212 takes only setting a few bits of message (easy to do by brute force) 213 to make the message valid enough to be processed in some very 214 surprising way. 216 If key generation or batch signature verification is performed, a 217 well-seed cryptographical random number generator is REQUIRED. 218 Signing and non-batch signature verification are deterministic 219 operations and do not need random numbers of any kind. 221 5. Acknowledgements 223 Mike Jones for comments on initial pre-draft. 225 6. IANA considerations 227 The following is added to JSON Web Key Types Registry: 229 o "kty" Parameter Value: "OKP" 230 o Key Type Description: Octet string key pairs 231 o JOSE Implementation Requirements: Optional 232 o Change Controller: IESG 233 o Specification Document(s): Section 2 of [RFC-THIS] 234 The following is added to JSON Web Key Parameters Registry: 236 o Parameter Name: "crv" 237 o Parameter Description: The algorithm group of keypair 238 o Parameter Information Class: Public 239 o Used with "kty" Value(s): "OKP" 240 o Change Controller: IESG 241 o Specification Document(s): Section 2 of [RFC-THIS] 243 o Parameter Name: "d" 244 o Parameter Description: The private key 245 o Parameter Information Class: Private 246 o Used with "kty" Value(s): "OKP" 247 o Change Controller: IESG 248 o Specification Document(s): Section 2 of [RFC-THIS] 250 o Parameter Name: "x" 251 o Parameter Description: The public key 252 o Parameter Information Class: Public 253 o Used with "kty" Value(s): "OKP" 254 o Change Controller: IESG 255 o Specification Document(s): Section 2 of [RFC-THIS] 257 The following is added to JSON Web Signature and Encryption 258 Algorithms Registry: 260 o Algorithm Name: "Ed25519" 261 o Algorithm Description: Ed25519 signature algorithm 262 o Algorithm Usage Location(s): "alg" 263 o JOSE Implementation Requirements: Optional 264 o Change Controller: IESG 265 o Specification Document(s): Section 3.1 of [RFC-THIS] 266 o Algorithm Analysis Documents(s): [I-D.irtf-cfrg-eddsa] 268 o Algorithm Name: "Ed25519ph" 269 o Algorithm Description: Ed25519 signature algorithm with prehash 270 o Algorithm Usage Location(s): "alg" 271 o JOSE Implementation Requirements: Optional 272 o Change Controller: IESG 273 o Specification Document(s): Section 3.1 of [RFC-THIS] 274 o Algorithm Analysis Documents(s): [I-D.irtf-cfrg-eddsa] 276 o Algorithm Name: "Ed448" 277 o Algorithm Description: Ed448 signature algorithm 278 o Algorithm Usage Location(s): "alg" 279 o JOSE Implementation Requirements: Optional 280 o Change Controller: IESG 281 o Specification Document(s): Section 3.1 of [RFC-THIS] 282 o Algorithm Analysis Documents(s): [I-D.irtf-cfrg-eddsa] 284 o Algorithm Name: "Ed448ph" 285 o Algorithm Description: Ed448 signature algorithm with prehash 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.1 of [RFC-THIS] 290 o Algorithm Analysis Documents(s): [I-D.irtf-cfrg-eddsa] 292 The following is added to 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.1 of [RFC-THIS] 300 o Curve Name: "Ed25519ph" 301 o Curve Description: Ed25519 signature algorithm with prehash 302 keypairs 303 o JOSE Implementation Requirements: Optional 304 o Change Controller: IESG 305 o Specification Document(s): Section 3.1 of [RFC-THIS] 307 o Curve Name: "Ed448" 308 o Curve Description: Ed448 signature algorithm keypairs 309 o JOSE Implementation Requirements: Optional 310 o Change Controller: IESG 311 o Specification Document(s): Section 3.1 of [RFC-THIS] 313 o Curve Name: "Ed448ph" 314 o Curve Description: Ed448 signature algorithm with prehash keypairs 315 o JOSE Implementation Requirements: Optional 316 o Change Controller: IESG 317 o Specification Document(s): Section 3.1 of [RFC-THIS] 319 o Curve name: "X25519" 320 o Curve Description: X25519 function keypairs 321 o JOSE Implementation Requirements: Optional 322 o Change Controller: IESG 323 o Specification Document(s): Section 3.2 of [RFC-THIS] 324 o Analysis Documents(s): [I-D.irtf-cfrg-curves] 326 o Curve Name: "X448" 327 o Curve Description: X448 function keypairs 328 o JOSE Implementation Requirements: Optional 329 o Change Controller: IESG 330 o Specification Document(s): Section 3.2 of [RFC-THIS] 331 o Analysis Documents(s): [I-D.irtf-cfrg-curves] 333 7. References 335 7.1. Normative References 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, 339 DOI 10.17487/RFC2119, March 1997, 340 . 342 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 343 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 344 . 346 [I-D.irtf-cfrg-curves] 347 Langley, A. and M. Hamburg, "Elliptic Curves for 348 Security", draft-irtf-cfrg-curves-11 (work in progress), 349 October 2015. 351 [I-D.irtf-cfrg-eddsa] 352 Josefsson, S. and I. Liusvaara, "Edwards-curve Digital 353 Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-01 354 (work in progress), December 2015. 356 7.2. Informative References 358 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 359 DOI 10.17487/RFC7517, May 2015, 360 . 362 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 363 DOI 10.17487/RFC7518, May 2015, 364 . 366 [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) 367 Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 368 2015, . 370 Appendix A. Examples 372 To the extent possible, the examples use material lifted from test 373 vectors of [I-D.irtf-cfrg-curves] and [I-D.irtf-cfrg-eddsa] 375 A.1. Ed25519 private key 377 {"kty":"OKP","crv":"Ed25519", 378 "d":"nWGxne_9WmC6hEr0kuwsxERJxWl7MmkZcDusAxyuf2A" 379 "x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"} 381 The hexadecimal dump of private key is: 383 9d 61 b1 9d ef fd 5a 60 ba 84 4a f4 92 ec 2c c4 384 44 49 c5 69 7b 32 69 19 70 3b ac 03 1c ae 7f 60 386 And of the public key: 388 d7 5a 98 01 82 b1 0a b7 d5 4b fe d3 c9 64 07 3a 389 0e e1 72 f3 da a6 23 25 af 02 1a 68 f7 07 51 1a 391 A.2. Ed25519 public key 393 This is the public parts of the previous private key (just omits 394 "d"): 396 {"kty":"OKP","crv":"Ed25519", 397 "x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"} 399 A.3. JWK thumbprint canonicalization 401 The JWK thumbprint canonicalization of the two above examples is 402 (linebreak inserted for formatting reasons) 404 {"crv":"Ed25519","kty":"OKP","x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwI 405 aaPcHURo"} 407 Which has the SHA-256 hash of: 408 90facafea9b1556698540f70c0117a22ea37bd5cf3ed3c47093c1707282b4b89 410 A.4. Ed25519 Signing 412 The JWS protected header is: 414 {"alg":"Ed25519"} 416 This has base64url encoding of: 418 eyJhbGciOiJFZDI1NTE5In0 420 The payload is (text): 422 Example of Ed25519 signing 423 This has base64url encoding of: 425 RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc 427 The JWS signing input is (concatenation of base64url encoding of the 428 (protected) header, a dot and base64url encoding of the payload) is: 430 eyJhbGciOiJFZDI1NTE5In0.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc 432 Applying Ed25519 signing algorithm to the private key, public key and 433 the JWS signing input yields signature (hex): 435 53 18 48 60 b1 c6 83 7f 4d 54 22 e9 40 05 43 fd 436 47 1f 3a 69 c6 48 2c cb 15 9a 17 62 42 e2 21 b1 437 5c 72 63 9b fe a3 9b b2 08 f3 2c ab 1f 27 0f b8 438 36 57 1c 52 0b d8 ac 41 eb 45 b3 55 d0 77 19 01 440 Converting this to base64url yields: 442 UxhIYLHGg39NVCLpQAVD_UcfOmnGSCzLFZoXYkLiIbFccmOb_qObsgjzLKsfJw-4NlccU 443 gvYrEHrRbNV0HcZAQ 445 So the compact serialization of JWS is (concatenation of signing 446 input, a dot and base64url encoding of the signature: 448 eyJhbGciOiJFZDI1NTE5In0.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc.UxhIYLHGg 449 39NVCLpQAVD_UcfOmnGSCzLFZoXYkLiIbFccmOb_qObsgjzLKsfJw-4NlccUgvYrEHrRb 450 NV0HcZAQ 452 A.5. Ed25519 Validation 454 The JWS from above example is: 456 eyJhbGciOiJFZDI1NTE5In0.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc.UxhIYLHGg 457 39NVCLpQAVD_UcfOmnGSCzLFZoXYkLiIbFccmOb_qObsgjzLKsfJw-4NlccUgvYrEHrRb 458 NV0HcZAQ 460 This has 2 dots in it, so it might be valid JWS. Base64url decoding 461 the protected header yields: 463 {"alg":"Ed25519"} 465 So this is Ed25519 signature. Now the key has: "kty":"OKP" and 466 "crv":"Ed25519", so the key is valid for the algorithm (if it had 467 other values, the validation would have failed). 469 The signing input is the part before second dot: 471 eyJhbGciOiJFZDI1NTE5In0.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc 473 Applying Ed25519 verification algorithm to the public key, JWS 474 signing input and the signature yields true. So the signature is 475 valid. The message is base64 decoding of the part between the dots: 477 Example of Ed25519 signing 479 A.6. ECDH-ES with X25519 481 The public key to encrypt to is: 483 {"kty":"OKP","crv":"X25519","kid":"Bob" 484 "x":"3p7bfXt9wbTTW2HC7OQ1Nz-DQ8hbeGdNrfx-FG-IK08"} 486 The public key from target key is (hex): 488 de 9e db 7d 7b 7d c1 b4 d3 5b 61 c2 ec e4 35 37 489 3f 83 43 c8 5b 78 67 4d ad fc 7e 14 6f 88 2b 4f 491 The ephemeral secret happens to be (hex): 493 77 07 6d 0a 73 18 a5 7d 3c 16 c1 72 51 b2 66 45 494 df 4c 2f 87 eb c0 99 2a b1 77 fb a5 1d b9 2c 2a 496 So the ephemeral public key is X25519(ephkey,G) (hex): 498 85 20 f0 09 89 30 a7 54 74 8b 7d dc b4 3e f7 5a 499 0d bf 3a 0d 26 38 1a f4 eb a4 a9 8e aa 9b 4e 6a 501 This is packed into ephemeral public key value: 503 {"kty":"OKP","crv":"X25519", 504 "x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"} 506 So the protected header could for example be: 508 {"alg":"ECDH-ES+A128KW","epk":{"kty":"OKP","crv":"X25519", 509 "x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"}, 510 "enc":"A128GCM","kid":"Bob"} 512 And sender computes as the DH Z value as X25519(ephkey,recv_pub) 513 (hex): 515 4a 5d 9d 5b a4 ce 2d e1 72 8e 3b f4 80 35 0f 25 516 e0 7e 21 c9 47 d1 9e 33 76 f0 9b 3c 1e 16 17 42 517 The receiver computes as the DH Z value as X25519(seckey,ephkey_pub) 518 (hex): 520 4a 5d 9d 5b a4 ce 2d e1 72 8e 3b f4 80 35 0f 25 521 e0 7e 21 c9 47 d1 9e 33 76 f0 9b 3c 1e 16 17 42 523 Which is the same as sender's value (the both sides run this through 524 KDF before using as AES128-KW key). 526 A.7. ECDH-ES with X448 528 The public key to encrypt to is (linebreak inserted for formatting 529 reasons): 531 {"kty":"OKP","crv":"X448","kid":"Dave" 532 "x":"PreoKbDNIPW8_AtZm2_sz22kYnEHvbDU80W0MCfYuXL8PjT7QjKhPKcG3LV67D2 533 uB73BxnvzNgk"} 535 The public key from target key is (hex): 537 3e b7 a8 29 b0 cd 20 f5 bc fc 0b 59 9b 6f ec cf 538 6d a4 62 71 07 bd b0 d4 f3 45 b4 30 27 d8 b9 72 539 fc 3e 34 fb 42 32 a1 3c a7 06 dc b5 7a ec 3d ae 540 07 bd c1 c6 7b f3 36 09 542 The ephemeral secret happens to be (hex): 544 9a 8f 49 25 d1 51 9f 57 75 cf 46 b0 4b 58 00 d4 545 ee 9e e8 ba e8 bc 55 65 d4 98 c2 8d d9 c9 ba f5 546 74 a9 41 97 44 89 73 91 00 63 82 a6 f1 27 ab 1d 547 9a c2 d8 c0 a5 98 72 6b 549 So the ephemeral public key is X448(ephkey,G) (hex): 551 9b 08 f7 cc 31 b7 e3 e6 7d 22 d5 ae a1 21 07 4a 552 27 3b d2 b8 3d e0 9c 63 fa a7 3d 2c 22 c5 d9 bb 553 c8 36 64 72 41 d9 53 d4 0c 5b 12 da 88 12 0d 53 554 17 7f 80 e5 32 c4 1f a0 556 This is packed into ephemeral public key value (linebreak inserted 557 for formatting purposes): 559 {"kty":"OKP","crv":"X448", 560 "x":"mwj3zDG34-Z9ItWuoSEHSic70rg94Jxj-qc9LCLF2bvINmRyQdlT1AxbEtqIEg1 561 TF3-A5TLEH6A"} 563 So the protected header could for example be (linebreak inserted for 564 formatting purposes): 566 {"alg":"ECDH-ES+A256KW","epk":{"kty":"OKP","crv":"X448", 567 "x":"mwj3zDG34-Z9ItWuoSEHSic70rg94Jxj-qc9LCLF2bvINmRyQdlT1AxbEtqIEg1 568 TF3-A5TLEH6A"},"enc":"A256GCM","kid":"Dave"} 570 And sender computes as the DH Z value as X448(ephkey,recv_pub) (hex): 572 07 ff f4 18 1a c6 cc 95 ec 1c 16 a9 4a 0f 74 d1 573 2d a2 32 ce 40 a7 75 52 28 1d 28 2b b6 0c 0b 56 574 fd 24 64 c3 35 54 39 36 52 1c 24 40 30 85 d5 9a 575 44 9a 50 37 51 4a 87 9d 577 The receiver computes as the DH Z value as X448(seckey,ephkey_pub) 578 (hex): 580 07 ff f4 18 1a c6 cc 95 ec 1c 16 a9 4a 0f 74 d1 581 2d a2 32 ce 40 a7 75 52 28 1d 28 2b b6 0c 0b 56 582 fd 24 64 c3 35 54 39 36 52 1c 24 40 30 85 d5 9a 583 44 9a 50 37 51 4a 87 9d 585 Which is the same as sender's value (the both sides run this through 586 KDF before using as AES256-KW key). 588 Author's Address 590 Ilari Liusvaara 591 Independent 593 Email: ilariliusvaara@welho.com