idnits 2.17.1 draft-ietf-jose-cfrg-curves-02.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 (May 24, 2016) is 2891 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 302, 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 May 24, 2016 5 Expires: November 25, 2016 7 CFRG ECDH and signatures in JOSE 8 draft-ietf-jose-cfrg-curves-02 10 Abstract 12 This document defines how to use Diffie-Hellman algorithms "X25519" 13 and "X448" as well as signature algorithms "Ed25519" and "Ed448" from 14 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 November 25, 2016. 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. Requirements Terminology . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 6 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 7.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 8 67 A.1. Ed25519 private key . . . . . . . . . . . . . . . . . . . 8 68 A.2. Ed25519 public key . . . . . . . . . . . . . . . . . . . 8 69 A.3. JWK thumbprint canonicalization . . . . . . . . . . . . . 8 70 A.4. Ed25519 Signing . . . . . . . . . . . . . . . . . . . . . 9 71 A.5. Ed25519 Validation . . . . . . . . . . . . . . . . . . . 10 72 A.6. ECDH-ES with X25519 . . . . . . . . . . . . . . . . . . . 10 73 A.7. ECDH-ES with X448 . . . . . . . . . . . . . . . . . . . . 11 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 Internet Research Task Force (IRTF) Crypto Forum Research Group 79 (CFRG) selected new Diffie-Hellman algorithms ("X25519" and "X448"; 80 [RFC7748]) and signature algorithms ("Ed25519" and "Ed448"); 81 [I-D.irtf-cfrg-eddsa]) for asymmetric key cryptography. This 82 document defines how those algorithms are to be used in JOSE in 83 interoperable manner. 85 This document defines the conventions to be used in context of 86 [RFC7517] and [RFC7518] 88 While the CFRG also defined two pairs of isogenous elliptic curves 89 that underlie these algorithms, these curves are not directly 90 exposed, as the algorithms laid on top are sufficient for the 91 purposes of JOSE and are much easier to use (e.g. trying to apply 92 ECDSA to those curves leads to nasty corner-cases and produces odd 93 results). 95 All inputs to and outputs from the the ECDH and signature functions 96 are defined to be octet strings, with the exception of output of 97 verification function, which is a boolean. 99 1.1. Requirements Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 2. Key type 'OKP' 107 A new key type (kty) value "OKP" (Octet Key Pair) is defined for 108 public key algorithms that use octet strings as private and public 109 keys. It has the following parameters: 111 o The parameter "kty" MUST be "OKP". 113 o The parameter "crv" MUST be present, and contain the subtype of 114 the key (from "JSON Web Elliptic curve" registry). 116 o The parameter "x" MUST be present, and contain the public key 117 encoded using base64url [RFC4648] encoding. 119 o The parameter "d" MUST be present for private keys, and contain 120 the private key encoded using base64url encoding. This parameter 121 MUST NOT be present for public keys. 123 Note: Do not assume that there is an underlying elliptic curve, 124 despite the existence of the "crv" and "x" parameters (for instance, 125 this key type could be extended to represent DH algorithms based on 126 hyperelliptic surfaces). 128 When calculating thumbprints [RFC7638], the three public key fields 129 are included in the hash. That is, in lexicographic order: "crv", 130 "kty" and "x". 132 3. Algorithms 134 3.1. Signatures 136 3.1.1. Algorithms 138 For EdDSA signatures, algorithm "EdDSA" is defined here, to be 139 applied as value of "alg" parameter. 141 The key type for these keys is "OKP" and key subtype for these keys 142 MUST be "Ed25519" for Ed25519 and "Ed448" for Ed448. The keys of 143 these subtypes MUST NOT be used for ECDH-ES. 145 "crv" EdDSA variant 146 Ed25519 Ed25519 147 Ed448 Ed448 149 3.1.2. Signing 151 Signing for these is preformed by applying the signing algorithm 152 defined in [I-D.irtf-cfrg-eddsa] to the private key (as private key), 153 public key (as public key) and the JWS Signing Input (as message). 154 The resulting signature is the JWS Signature value. All inputs and 155 outputs are octet strings. 157 3.1.3. Verification 159 Verification is performed by applying the verification algorithm 160 defined in [I-D.irtf-cfrg-eddsa] to the public key (as public key), 161 the JWS Signing Input (as message) and the JWS Signature value (as 162 signature). All inputs are octet strings. If the algorithm accepts, 163 the signature is valid, otherwise signature is invalid. 165 3.2. ECDH-ES 167 The following key subtypes defined here for purpose of "Key Agreement 168 with Elliptic Curve Diffie-Hellman Ephemeral Static" (ECDH-ES). 170 "crv" ECDH Function applied 171 X25519 X25519 172 X448 X448 174 The key type used with these keys is "OKP". These subtypes MUST NOT 175 be used for signing. 177 [RFC7518] section 4.6 defines the ECDH-ES algorithms "ECDH- 178 ES+A128KW", "ECDH-ES+A192KW", "ECDH-ES+A256KW" and "ECDH-ES". 180 3.2.1. Performing the ECDH operation 182 The "x" parameter of "epk" field is set as follows: 184 Apply the appropriate ECDH function to the ephemeral private key (as 185 scalar input) and the standard basepoint (as u-coordinate input). 186 The output is the value for "x" parameter of "epk" field. All inputs 187 and outputs are octet strings. 189 The Z value (raw key agreement output) for key agreement (to be used 190 in subsequent KDF as per [RFC7518] section 4.6.2) is determined as 191 follows: 193 Apply the appropriate ECDH function to the ephemeral private key (as 194 scalar input) and receiver public key (as u-coordinate input). The 195 output is the Z value. All inputs and outputs are octet strings. 197 4. Security considerations 199 Security considerations from [RFC7748] and [I-D.irtf-cfrg-eddsa] 200 apply here. 202 Do not separate key material from information about what key subtype 203 it is for. When using keys, check that the algorithm is compatible 204 with the key subtype for the key. To do otherwise opens system up to 205 attacks via mixing up algorithms. It is particularly dangerous to 206 mix up signature and MAC algorithms. 208 Although for Ed25519 and Ed448 the signature binds the key used for 209 signing, do not assume this, as there are many signature algorithms 210 that fail to make such binding. If key-binding is desired, include 211 the key used for signing either inside the JWS protected header or 212 the data to sign. 214 If key generation or batch signature verification is performed, a 215 well-seed cryptographic random number generator is REQUIRED. Signing 216 and non-batch signature verification are deterministic operations and 217 do not need random numbers of any kind. 219 The JWA ECDH-ES KDF construction does not mix keys into the final 220 shared secret. While in key exchange such could be a bad mistake, 221 here either receiver public key has to be chosen maliciously or the 222 sender has to be malicious in order to cause problems. And in either 223 case, all security evaporates anyway. 225 The nominal security strengths of X25519 and X448 are ~126 and ~223 226 bits. Therefore, using 256-bit symmetric encryption (especially key 227 wrapping and encryption) with X448 is RECOMMENDED. 229 5. Acknowledgements 231 Mike Jones for comments on initial pre-draft. 233 6. IANA considerations 235 The following is added to JSON Web Key Types Registry: 237 o "kty" Parameter Value: "OKP" 238 o Key Type Description: Octet string key pairs 239 o JOSE Implementation Requirements: Optional 240 o Change Controller: IESG 241 o Specification Document(s): Section 2 of [RFC-THIS] 243 The following is added to JSON Web Key Parameters Registry: 245 o Parameter Name: "crv" 246 o Parameter Description: The subtype of keypair 247 o Parameter Information Class: Public 248 o Used with "kty" Value(s): "OKP" 249 o Change Controller: IESG 250 o Specification Document(s): Section 2 of [RFC-THIS] 252 o Parameter Name: "d" 253 o Parameter Description: The private key 254 o Parameter Information Class: Private 255 o Used with "kty" Value(s): "OKP" 256 o Change Controller: IESG 257 o Specification Document(s): Section 2 of [RFC-THIS] 259 o Parameter Name: "x" 260 o Parameter Description: The public key 261 o Parameter Information Class: Public 262 o Used with "kty" Value(s): "OKP" 263 o Change Controller: IESG 264 o Specification Document(s): Section 2 of [RFC-THIS] 266 The following is added to JSON Web Signature and Encryption 267 Algorithms Registry: 269 o Algorithm Name: "EdDSA" 270 o Algorithm Description: EdDSA signature algorithms 271 o Algorithm Usage Location(s): "alg" 272 o JOSE Implementation Requirements: Optional 273 o Change Controller: IESG 274 o Specification Document(s): Section 3.1 of [RFC-THIS] 275 o Algorithm Analysis Documents(s): [I-D.irtf-cfrg-eddsa] 277 The following is added to JSON Web Key Elliptic Curve Registry: 279 o Curve Name: "Ed25519" 280 o Curve Description: Ed25519 signature algorithm keypairs 281 o JOSE Implementation Requirements: Optional 282 o Change Controller: IESG 283 o Specification Document(s): Section 3.1 of [RFC-THIS] 285 o Curve Name: "Ed448" 286 o Curve Description: Ed448 signature algorithm keypairs 287 o JOSE Implementation Requirements: Optional 288 o Change Controller: IESG 289 o Specification Document(s): Section 3.1 of [RFC-THIS] 291 o Curve name: "X25519" 292 o Curve Description: X25519 function keypairs 293 o JOSE Implementation Requirements: Optional 294 o Change Controller: IESG 295 o Specification Document(s): Section 3.2 of [RFC-THIS] 296 o Analysis Documents(s): [RFC7748] 298 o Curve Name: "X448" 299 o Curve Description: X448 function keypairs 300 o JOSE Implementation Requirements: Optional 301 o Change Controller: IESG 302 o Specification Document(s): Section 3.2 of [RFC-THIS] 303 o Analysis Documents(s): [RFC7748] 305 7. References 307 7.1. Normative References 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, 311 DOI 10.17487/RFC2119, March 1997, 312 . 314 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 315 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 316 . 318 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 319 for Security", RFC 7748, DOI 10.17487/RFC7748, January 320 2016, . 322 [I-D.irtf-cfrg-eddsa] 323 Josefsson, S. and I. Liusvaara, "Edwards-curve Digital 324 Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-05 325 (work in progress), March 2016. 327 7.2. Informative References 329 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 330 DOI 10.17487/RFC7517, May 2015, 331 . 333 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 334 DOI 10.17487/RFC7518, May 2015, 335 . 337 [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) 338 Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 339 2015, . 341 Appendix A. Examples 343 To the extent possible, the examples use material lifted from test 344 vectors of [RFC7748] and [I-D.irtf-cfrg-eddsa] 346 A.1. Ed25519 private key 348 {"kty":"OKP","crv":"Ed25519", 349 "d":"nWGxne_9WmC6hEr0kuwsxERJxWl7MmkZcDusAxyuf2A" 350 "x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"} 352 The hexadecimal dump of private key is: 354 9d 61 b1 9d ef fd 5a 60 ba 84 4a f4 92 ec 2c c4 355 44 49 c5 69 7b 32 69 19 70 3b ac 03 1c ae 7f 60 357 And of the public key: 359 d7 5a 98 01 82 b1 0a b7 d5 4b fe d3 c9 64 07 3a 360 0e e1 72 f3 da a6 23 25 af 02 1a 68 f7 07 51 1a 362 A.2. Ed25519 public key 364 This is the public parts of the previous private key (just omits 365 "d"): 367 {"kty":"OKP","crv":"Ed25519", 368 "x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"} 370 A.3. JWK thumbprint canonicalization 372 The JWK thumbprint canonicalization of the two above examples is 373 (linebreak inserted for formatting reasons) 374 {"crv":"Ed25519","kty":"OKP","x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwI 375 aaPcHURo"} 377 Which has the SHA-256 hash of: 378 90facafea9b1556698540f70c0117a22ea37bd5cf3ed3c47093c1707282b4b89 380 A.4. Ed25519 Signing 382 The JWS protected header is: 384 {"alg":"EdDSA"} 386 This has base64url encoding of: 388 eyJhbGciOiJFZERTQSJ9 390 The payload is (text): 392 Example of Ed25519 signing 394 This has base64url encoding of: 396 RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc 398 The JWS signing input is (concatenation of base64url encoding of the 399 (protected) header, a dot and base64url encoding of the payload) is: 401 eyJhbGciOiJFZERTQSJ9.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc 403 Applying Ed25519 signing algorithm to the private key, public key and 404 the JWS signing input yields signature (hex): 406 86 0c 98 d2 29 7f 30 60 a3 3f 42 73 96 72 d6 1b 407 53 cf 3a de fe d3 d3 c6 72 f3 20 dc 02 1b 41 1e 408 9d 59 b8 62 8d c3 51 e2 48 b8 8b 29 46 8e 0e 41 409 85 5b 0f b7 d8 3b b1 5b e9 02 bf cc b8 cd 0a 02 411 Converting this to base64url yields: 413 hgyY0il_MGCjP0JzlnLWG1PPOt7-09PGcvMg3AIbQR6dWbhijcNR4ki4iylGjg5BhVsPt 414 9g7sVvpAr_MuM0KAg 416 So the compact serialization of JWS is (concatenation of signing 417 input, a dot and base64url encoding of the signature: 419 eyJhbGciOiJFZERTQSJ9.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc.hgyY0il_MGCj 420 P0JzlnLWG1PPOt7-09PGcvMg3AIbQR6dWbhijcNR4ki4iylGjg5BhVsPt9g7sVvpAr_Mu 421 M0KAg 423 A.5. Ed25519 Validation 425 The JWS from above example is: 427 eyJhbGciOiJFZERTQSJ9.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc.hgyY0il_MGCj 428 P0JzlnLWG1PPOt7-09PGcvMg3AIbQR6dWbhijcNR4ki4iylGjg5BhVsPt9g7sVvpAr_Mu 429 M0KAg 431 This has 2 dots in it, so it might be valid JWS. Base64url decoding 432 the protected header yields: 434 {"alg":"EdDSA"} 436 So this is EdDSA signature. Now the key has: "kty":"OKP" and 437 "crv":"Ed25519", so the signature is Ed25519 signature. 439 The signing input is the part before second dot: 441 eyJhbGciOiJFZERTQSJ9.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc 443 Applying Ed25519 verification algorithm to the public key, JWS 444 signing input and the signature yields true. So the signature is 445 valid. The message is base64 decoding of the part between the dots: 447 Example of Ed25519 signing 449 A.6. ECDH-ES with X25519 451 The public key to encrypt to is: 453 {"kty":"OKP","crv":"X25519","kid":"Bob" 454 "x":"3p7bfXt9wbTTW2HC7OQ1Nz-DQ8hbeGdNrfx-FG-IK08"} 456 The public key from target key is (hex): 458 de 9e db 7d 7b 7d c1 b4 d3 5b 61 c2 ec e4 35 37 459 3f 83 43 c8 5b 78 67 4d ad fc 7e 14 6f 88 2b 4f 461 The ephemeral secret happens to be (hex): 463 77 07 6d 0a 73 18 a5 7d 3c 16 c1 72 51 b2 66 45 464 df 4c 2f 87 eb c0 99 2a b1 77 fb a5 1d b9 2c 2a 466 So the ephemeral public key is X25519(ephkey,G) (hex): 468 85 20 f0 09 89 30 a7 54 74 8b 7d dc b4 3e f7 5a 469 0d bf 3a 0d 26 38 1a f4 eb a4 a9 8e aa 9b 4e 6a 470 This is packed into ephemeral public key value: 472 {"kty":"OKP","crv":"X25519", 473 "x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"} 475 So the protected header could for example be: 477 {"alg":"ECDH-ES+A128KW","epk":{"kty":"OKP","crv":"X25519", 478 "x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"}, 479 "enc":"A128GCM","kid":"Bob"} 481 And sender computes as the DH Z value as X25519(ephkey,recv_pub) 482 (hex): 484 4a 5d 9d 5b a4 ce 2d e1 72 8e 3b f4 80 35 0f 25 485 e0 7e 21 c9 47 d1 9e 33 76 f0 9b 3c 1e 16 17 42 487 The receiver computes as the DH Z value as X25519(seckey,ephkey_pub) 488 (hex): 490 4a 5d 9d 5b a4 ce 2d e1 72 8e 3b f4 80 35 0f 25 491 e0 7e 21 c9 47 d1 9e 33 76 f0 9b 3c 1e 16 17 42 493 Which is the same as sender's value (the both sides run this through 494 KDF before using as direct encryption key or AES128-KW key). 496 A.7. ECDH-ES with X448 498 The public key to encrypt to is (linebreak inserted for formatting 499 reasons): 501 {"kty":"OKP","crv":"X448","kid":"Dave" 502 "x":"PreoKbDNIPW8_AtZm2_sz22kYnEHvbDU80W0MCfYuXL8PjT7QjKhPKcG3LV67D2 503 uB73BxnvzNgk"} 505 The public key from target key is (hex): 507 3e b7 a8 29 b0 cd 20 f5 bc fc 0b 59 9b 6f ec cf 508 6d a4 62 71 07 bd b0 d4 f3 45 b4 30 27 d8 b9 72 509 fc 3e 34 fb 42 32 a1 3c a7 06 dc b5 7a ec 3d ae 510 07 bd c1 c6 7b f3 36 09 512 The ephemeral secret happens to be (hex): 514 9a 8f 49 25 d1 51 9f 57 75 cf 46 b0 4b 58 00 d4 515 ee 9e e8 ba e8 bc 55 65 d4 98 c2 8d d9 c9 ba f5 516 74 a9 41 97 44 89 73 91 00 63 82 a6 f1 27 ab 1d 517 9a c2 d8 c0 a5 98 72 6b 518 So the ephemeral public key is X448(ephkey,G) (hex): 520 9b 08 f7 cc 31 b7 e3 e6 7d 22 d5 ae a1 21 07 4a 521 27 3b d2 b8 3d e0 9c 63 fa a7 3d 2c 22 c5 d9 bb 522 c8 36 64 72 41 d9 53 d4 0c 5b 12 da 88 12 0d 53 523 17 7f 80 e5 32 c4 1f a0 525 This is packed into ephemeral public key value (linebreak inserted 526 for formatting purposes): 528 {"kty":"OKP","crv":"X448", 529 "x":"mwj3zDG34-Z9ItWuoSEHSic70rg94Jxj-qc9LCLF2bvINmRyQdlT1AxbEtqIEg1 530 TF3-A5TLEH6A"} 532 So the protected header could for example be (linebreak inserted for 533 formatting purposes): 535 {"alg":"ECDH-ES+A256KW","epk":{"kty":"OKP","crv":"X448", 536 "x":"mwj3zDG34-Z9ItWuoSEHSic70rg94Jxj-qc9LCLF2bvINmRyQdlT1AxbEtqIEg1 537 TF3-A5TLEH6A"},"enc":"A256GCM","kid":"Dave"} 539 And sender computes as the DH Z value as X448(ephkey,recv_pub) (hex): 541 07 ff f4 18 1a c6 cc 95 ec 1c 16 a9 4a 0f 74 d1 542 2d a2 32 ce 40 a7 75 52 28 1d 28 2b b6 0c 0b 56 543 fd 24 64 c3 35 54 39 36 52 1c 24 40 30 85 d5 9a 544 44 9a 50 37 51 4a 87 9d 546 The receiver computes as the DH Z value as X448(seckey,ephkey_pub) 547 (hex): 549 07 ff f4 18 1a c6 cc 95 ec 1c 16 a9 4a 0f 74 d1 550 2d a2 32 ce 40 a7 75 52 28 1d 28 2b b6 0c 0b 56 551 fd 24 64 c3 35 54 39 36 52 1c 24 40 30 85 d5 9a 552 44 9a 50 37 51 4a 87 9d 554 Which is the same as sender's value (the both sides run this through 555 KDF before using as direct encryption key or AES256-KW key). 557 Author's Address 559 Ilari Liusvaara 560 Independent 562 Email: ilariliusvaara@welho.com