-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-madden-jose-ecdh-1pu-01.xml
1201 lines (1155 loc) · 58.6 KB
/
draft-madden-jose-ecdh-1pu-01.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0"?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
"http://xml2rfc.tools.ietf.org/authoring/rfc2629.dtd" [
<!ENTITY RFC7515 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml'>
<!ENTITY RFC7516 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7516.xml'>
<!ENTITY RFC7518 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7518.xml'>
<!ENTITY RFC7519 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml'>
<!ENTITY RFC7748 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7748.xml'>
<!ENTITY RFC8037 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8037.xml'>
<!ENTITY RFC8174 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml'>
]>
<rfc category="std" docName="draft-madden-jose-ecdh-1pu-01" ipr="trust200902">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc private=""?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<front>
<title abbrev="JOSE ECDH-1PU">Public Key Authenticated Encryption for JOSE: ECDH-1PU</title>
<author initials="N.E." surname="Madden" fullname="Neil Madden">
<organization>ForgeRock</organization>
<address>
<postal>
<street>Broad Quay House</street>
<street>Prince Street</street>
<city>Bristol</city>
<code>BS1 4DJ</code>
<country>United Kingdom</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date day="10" month="May" year="2019"/>
<area>Security</area>
<!-- <workgroup>OAuth</workgroup> -->
<keyword>Internet-Draft</keyword>
<keyword>JSON Object Signing and Encryption</keyword>
<keyword>JOSE</keyword>
<keyword>JSON Web Encryption</keyword>
<keyword>JWE</keyword>
<keyword>JSON Web Algorithms</keyword>
<keyword>JWA</keyword>
<keyword>Elliptic Curve Diffie-Hellman Key Agreement</keyword>
<keyword>ECDH</keyword>
<keyword>ECDH-1PU</keyword>
<abstract>
<t>
This document describes the ECDH-1PU public key authenticated encryption algorithm
for JWE. The algorithm is similar to the existing ECDH-ES encryption algorithm, but
adds an additional ECDH key agreement between static keys of the sender and recipient.
This additional step allows the recipient to be assured of sender authenticity without
requiring a nested signed-then-encrypted message structure. The mode is also a useful
building block for constructing interactive handshake protocols on top of JOSE.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
JSON Object Signing and Encryption (JOSE) defines a number of encryption (JWE)
<xref target="RFC7516"/> and digital signature (JWS) <xref target="RFC7515"/>
algorithms. When symmetric cryptography is used, JWE provides authenticated
encryption that ensures both confidentiality and sender authentication. However,
for public key cryptography the existing JWE encryption algorithms provide only
confidentiality and some level of ciphertext integrity. When sender authentication
is required, users must resort to nested signed-then-encrypted structures, which
increases the overhead and size of resulting messages. This document describes an
alternative encryption algorithm called ECDH-1PU that provides public key
authenticated encryption, allowing the benefits of authenticated encryption to be
enjoyed for public key JWE as it currently is for symmetric cryptography.
</t>
<t>
ECDH-1PU is based on the One-Pass Unified Model for Elliptic Curve Diffie-Hellman
key agreement described in <xref target="NIST.800-56A"/>.
</t>
<t>
The advantages of public key authenticated encryption with ECDH-1PU compared to
using nested signed-then-encrypted documents include the following:
<list style="symbols">
<t>
The resulting message size is more compact as an additional layer of headers
and base64url-encoding is avoided. A 500-byte payload when encrypted and
authenticated with ECDH-1PU (with P-256 keys and "A256GCM" Content Encryption
Method) results in a 1087-byte JWE in Compact Encoding. An equivalent nested
signed-then-encrypted JOSE message using the same keys and encryption method
is 1489 bytes (37% larger).
</t>
<t>
The same primitives are used for both confidentiality and authenticity,
providing savings in code size for constrained environments.
</t>
<t>
The generic composition of signatures and public key encryption involves
a number of subtle details that are essential to security <xref target="PKAE"/>.
Providing a dedicated algorithm for public key authenticated encryption
reduces complexity for users of JOSE libraries.
</t>
<t>
ECDH-1PU provides only authenticity and not the stronger security properties of
non-repudiation or third-party verifiability. This can be an advantage in
applications where privacy, anonymity, or plausible deniability are goals.
</t>
</list>
</t>
<section title="Requirements Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described
in BCP 14 <xref target="RFC8174"/> when, and only when, they appear
in all capitals, as shown here.</t>
</section>
</section>
<section anchor="ecdh-1pu"
title="Key Agreement with Elliptic Curve Diffie-Hellman One-Pass Unified Model (ECDH-1PU)">
<t>
This section defines the specifics of key agreement with Elliptic Curve Diffie-Hellman
One-Pass Unified Model, in combination with the one-step KDF, as defined in
Section 5.8.2.1 of <xref target="NIST.800-56A"/> using the Concatenation Format of
Section 5.8.2.1.1. This is identical to the ConcatKDF function used by the existing
JWE ECDH-ES algorithm defined in Section 4.6 of <xref target="RFC7518"/>. As for ECDH-ES,
the key agreement result can be used in one of two ways:
<list style="numbers">
<t>directly as the Content Encryption Key (CEK) for the "enc" algorithm, in the
Direct Key Agreement mode, or</t>
<t>as a symmetric key used to wrap the CEK with the "A128KW", "A192KW", or "A256KW"
algorithms, in the Key Agreement with Key Wrapping mode.</t>
</list>
</t>
<t>
A new ephemeral public key value MUST be generated for each key agreement operation.
</t>
<t>
In Direct Key Agreement mode, the output of the KDF MUST be a key of the same length
as that used by the "enc" algorithm. In this case, the empty octet sequence is used
as the JWE Encrypted Key value. The "alg" (algorithm) Header Parameter value "ECDH-1PU"
is used in Direct Key Agreement mode.
</t>
<t>
In Key Agreement with Key Wrapping mode, the output of the KDF MUST be a key of the length
needed for the specified key wrapping algorithm. In this case, the JWE Encrypted Key is
the CEK wrapped with the agreed-upon key.
</t>
<t>
The following "alg" (algorithm) Header Parameter values are used to indicate the JWE
Encrypted Key is the result of encrypting the CEK using the result of the key agreement
algorithm as the key encryption key for the corresponding key wrapping algorithm:
</t>
<texttable>
<ttcol align="left" width="13%">"alg" Param Value</ttcol>
<ttcol align="left">Key Management Algorithm</ttcol>
<c>ECDH-1PU+A128KW</c>
<c>ECDH-1PU using one-pass KDF and CEK wrapped with "A128KW"</c>
<c>ECDH-1PU+A192KW</c>
<c>ECDH-1PU using one-pass KDF and CEK wrapped with "A192KW"</c>
<c>ECDH-1PU+A256KW</c>
<c>ECDH-1PU using one-pass KDF and CEK wrapped with "A256KW"</c>
</texttable>
<section title="Header Parameters used for ECDH Key Agreement">
<t>
The "epk" (ephemeral public key), "apu" (Agreement PartyUInfo), and "apv" (Agreement PartyVInfo)
header parameters are used in ECDH-1PU exactly as defined in Section 4.6.1 of
<xref target="RFC7518"/>.
</t>
<t>
When no other values are supplied, it is RECOMMENDED that the producer software
initializes the "apu" header to the base64url-encoding of the SHA-256 hash of the
concatenation of the sender's static public key and the ephemeral public key, and
the "apv" header to the base64url-encoding of the SHA-256 hash of the recipient's
static public key. This ensures that all keys involved in the key agreement are
cryptographically bound to the derived keys.
</t>
<section anchor="skid" title=""skid" Header Parameter">
<t>
A new Header Parameter "skid" (Sender Key ID) is registered as a hint as to which
of the sender's keys was used to authenticate the JWE. The structure of the "skid"
value is unspecified. Its value MUST be a case-sensitive string. Use of this Header
Parameter is OPTIONAL. When used with a JWK, the "skid" value is used to match a JWK
"kid" parameter value.
</t>
</section>
</section>
<section title="Key Derivation for ECDH-1PU Key Agreement">
<t>
The key derivation process derives the agreed-upon key from the shared secret Z
established through the ECDH algorithm, per Section 6.2.1.2 of <xref target="NIST.800-56A"/>.
For the NIST prime order curves "P-256", "P-384", and "P-521", the ECC CDH primitive
for cofactor Diffie-Hellman defined in Section 5.7.1.2 of <xref target="NIST.800-56A"/> is
used (taking note that the cofactor for all these curves is 1). For curves "X25519" and
"X448" the appropriate ECDH primitive from Section 5 of <xref target="RFC7748"/> is used.
</t>
<t>
Key derivation is performed using the one-step KDF, as defined in Section 5.8.1 and
Section 5.8.2.1 of <xref target="NIST.800-56A"/> using the Concatenation Format of
Section 5.8.2.1.1, where the Auxilary Function H is SHA-256. The KDF parameters
are set as follows:
<list style="hanging">
<t hangText="Z">
This is set to the representation of the shared secret Z as an octet sequence.
As per Section 6.2.1.2 of <xref target="NIST.800-56A"/> Z is the concatenation
of Ze and Zs, where Ze is the shared secret derived from applying the ECDH
primitive to the sender's ephemeral private key and the recipient's static
public key. Zs is the shared secret derived from applying the ECDH primitive
to the sender's static private key and the recipient's static public key.
</t>
<t hangText="keydatalen">
This is set to the number of bits in the desired output key. For "ECDH-1PU",
this is the length of the key used by the "enc" algorithm. For "ECDH-1PU+A128KW",
"ECDH-1PU+A192KW", and "ECDH-1PU+A256KW", this is 128, 192, and 256, respectively.
</t>
<t hangText="AlgorithmID">
The AlgorithmID values is of the form Datalen || Data, where Data is a variable-length
string of zero or more octets, and Datalen is a fixed-length, big-endian 32-bit counter
that indicates the length (in octets) of Data. In the Direct Key Agreement case,
Data is set to the octets of the ASCII representation of the "enc" Header Parameter value.
In the Key Agreement with Key Wrapping case, Data is set to the octets of the ASCII
representation of the "alg" (algorithm) Header Parameter value.
</t>
<t hangText="PartyUInfo">
The PartyUInfo value is of the form Datalen || Data, where Data is
a variable-length string of zero or more octets, and Datalen is a
fixed-length, big-endian 32-bit counter that indicates the length
(in octets) of Data. If an "apu" (agreement PartyUInfo) Header
Parameter is present, Data is set to the result of base64url
decoding the "apu" value and Datalen is set to the number of
octets in Data. Otherwise, Datalen is set to 0 and Data is set to
the empty octet sequence.
</t>
<t hangText="PartyVInfo">
The PartyVInfo value is of the form Datalen || Data, where Data is
a variable-length string of zero or more octets, and Datalen is a
fixed-length, big-endian 32-bit counter that indicates the length
(in octets) of Data. If an "apv" (agreement PartyVInfo) Header
Parameter is present, Data is set to the result of base64url
decoding the "apv" value and Datalen is set to the number of
octets in Data. Otherwise, Datalen is set to 0 and Data is set to
the empty octet sequence.
</t>
<t hangText="SuppPubInfo">
This is set to the keydatalen represented as a 32-bit big-endian integer.
</t>
<t hangText="SuppPrivInfo">
This is set to the empty octet sequence.
</t>
</list>
Applications need to specifiy how the "apu" and "apv" Header Parameters are used for that
application. The "apu" and "apv" values MUST be distinct, when used. Applications wishing
to conform to <xref target="NIST.800-56A"/> need to provide values that meet the requirements
of that doucument, e.g., by using values that identify the producer and consumer.
</t>
<t>
See <xref target="example"/> for an example key agreement computation using this method.
</t>
</section>
</section>
<section anchor="interactive" title="Two-way interactive handshake">
<t>
A party that has received a JWE encrypted with ECDH-1PU MAY reply to that message by
creating a new JWE using ECDH-1PU, but using the ephemeral public key ("epk") from the
first message as if it was the originating party's static public key. In this case,
key agreement proceeds exactly as for <xref target="ecdh-1pu"/>, but with the originator's
ephemeral public key used as the recipient (Party V) static public key. The "alg" (algorithm)
Header Parameter in the response MUST be identical to the "alg" Header Parameter of the
original message. The "enc" (encryption method) Header Parameter in the response MUST also
be identical to the "enc" Header Parameter of the original message.
</t>
<t>
The value of the "apu" (Agreement PartyUInfo) Header Parameter value from the original
message SHOULD be reflected as the "apv" (Agreement PartyVInfo) Header Parameter value in
the new message. Applications need to specify how the new "apu" Header Parameter should be
constructed.
</t>
<t>
If a "kid" claim was included in the ephemeral public key of the original message, then
a "kid" Header Parameter with the same value MUST be included in the reply JWE.
</t>
<t>
See <xref target="handshake"/> for an example handshake using this method.
</t>
<t>
After the initial message and a reply have been exchanged, the two parties may communicate
using the derived key from the second message as the encryption key for any number of
additional messages. Applications MUST specify the algorithm to be used. The JWE algorithm
and encryption method used MUST use the same size key as the derived key. For example, if
the derived key is 256-bits, then appropriate algorithms include alg=dir and enc=A256GCM,
or alg=A256KW with any JWE content encryption method.
</t>
<t>
If Direct encryption is used, the "enc" (encryption method) of all subsequent messages MUST
be identical to the "enc" Header Parameter of the handshake messages. If the same derived key
is to be used for messages in both directions between the two parties, the application MUST
specify how unique nonces/IVs are to be generated by each party to avoid collisions. It is
RECOMMENDED that either a Key Wrap algorithm is used, or else the derived key is used as input to
a key derivation function to derive separate keys for each direction.
</t>
</section>
<section anchor="IANA" title="IANA considerations">
<?rfc subcompact="yes" ?>
<t>
This section registers identifiers under the IANA JSON Web Signature and Encryption Algorithms
Registry established by <xref target="RFC7518"/> and the IANA JSON Web Signature and Encryption
Header Parameters registry established by <xref target="RFC7515"/>.
</t>
<section title="JSON Web Signature and Encryption Algorithms Registration">
<t>
This section registers JWE algorithms as per the registry established in
<xref target="RFC7518"/>.
</t>
<section title="ECDH-1PU">
<t>
<list style="bullets">
<t>Algorithm Name: "ECDH-1PU"</t>
<t>Algorithm Description: ECDH One-Pass Unified Model using one-pass KDF</t>
<t>Algorithm Usage Location(s): "alg"</t>
<t>JOSE Implementation Requirements: Optional</t>
<t>Change Controller: IESG</t>
<t>Specification Document(s): <xref target="ecdh-1pu"/></t>
<t>Algorithm Analysis Document(s): <xref target="NIST.800-56A"/> (Section 7.3),
<xref target="PKAE"/></t>
</list>
</t>
</section>
</section>
<section title="JSON Web Signature and Encryption Header Parameters Registration">
<t>
This section registers new Header Parameters as per the registry established in
<xref target="RFC7515"/>.
</t>
<section title="skid">
<t>
<list style="bullets">
<t>Header Parameter Name: "skid"</t>
<t>Header Parameter Description: Sender Key ID</t>
<t>Header Parameter Usage Location(s): JWE</t>
<t>Change Controller: IESG</t>
<t>Specification Document(s): <xref target="skid"/></t>
</list>
</t>
</section>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>
The security considerations of <xref target="RFC7516"/> and <xref target="RFC7518"/>
relevant to ECDH-ES also apply to this specification.
</t>
<t>The security considerations of <xref target="NIST.800-56A"/> apply here.</t>
<t>
When performing an ECDH key agreement between a static private key and any untrusted
public key, care should be taken to ensure that the public key is a valid point on
the same curve as the private key. Failure to do so may result in compromise of the
static private key. For the NIST curves P-256, P-384, and P-521, appropriate validation
routines are given in Section 5.6.2.3.3 of <xref target="NIST.800-56A"/>. For the curves
used by X25519 and X448, consult the security considerations of <xref target="RFC7748"/>.
</t>
<t>
The ECDH-1PU algorithm is vulnerable to Key Compromise Impersonation (KCI) attacks. If
the long-term static private key of a party is compromised, then the attacker can not
only impersonate that party to other parties, but also impersonate any other party when
communicating with the compromised party. The second and any subsequent messages in
the two-way interactive handshake described in <xref target="interactive"/> are not
vulnerable to KCI. If resistance to KCI is desired in a single message, then it is
RECOMMENDED to use a nested JWS signature over the content.
</t>
<t>
When Key Agreement with Key Wrapping is used, with the same Content Encryption Key (CEK)
reused for multiple recipients, any of those recipients can produce a new message that
appears to come from the original sender. The new message will be indistinguishable from
a genuine message from the original sender to any of the other participants. The sender
SHOULD use a unique CEK for each recipient of a message.
</t>
<t>
The security properties of the one-pass unified model are given in Section 7.3 of
<xref target="NIST.800-56A"/>. The ECDH-1PU scheme is also related (but not identical) to
the "K" one-way handshake pattern of the Noise Protocol Framework. The two-way interactive
handshake described in <xref target="interactive"/> is also related to the "KK" two-way
interactive handshake pattern. The security properties of these handshake patterns are
given in Section 7.7 of <xref target="Noise"/>, although it should be stressed that many
details differ between Noise and the current specification.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC7515;
&RFC7516;
&RFC7518;
&RFC7748;
&RFC8174;
<reference anchor="NIST.800-56A">
<front>
<title>Recommendation for Pair-Wise Key Establishment Using Discrete Logarithm Cryptography Revision 3.</title>
<author surname="Barker" initials="E.">
<organization>Computer Security Division, Information Technology Laboratory</organization>
</author>
<author surname="Chen" initials="L.">
<organization>Computer Security Division, Information Technology Laboratory</organization>
</author>
<author surname="Roginsky" initials="A.">
<organization>Computer Security Division, Information Technology Laboratory</organization>
</author>
<author surname="Vassilev" initials="A.">
<organization>Computer Security Division, Information Technology Laboratory</organization>
</author>
<author surname="Davis" initials="R.">
<organization>National Security Agency</organization>
</author>
<date month="April" year="2018"/>
</front>
<seriesInfo name="NIST Special Publication" value="800-56A"/>
<format target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf" type="PDF"/>
</reference>
</references>
<references title="Informative References">
&RFC7519;
&RFC8037;
<reference anchor="PKAE">
<front>
<title>Authenticated Encryption in the Public-Key Setting: Security Notions and Analyses</title>
<author surname="An" initials="J.">
<organization>University of California at Davis</organization>
</author>
<date year="2001"/>
</front>
<seriesInfo name="IACR" value="ePrint 2001/079"/>
<format target="https://eprint.iacr.org/2001/079.ps" type="PS"/>
</reference>
<reference anchor="Noise">
<front>
<title>The Noise Protocol Framework, Revision 34</title>
<author surname="Perrin" initials="T."/>
<date year="2018" month="July" day="11"/>
</front>
<format target="https://noiseprotocol.org/noise.pdf" type="PDF"/>
</reference>
</references>
<section anchor="example" title="Example ECDH-1PU Key Agreement Computation with A256GCM">
<t>
This example uses ECDH-1PU in Direct Key Agreement mode ("alg" value "ECDH-1PU")
to produce an agreed-upon key for AES GCM with a 256-bit key ("enc" value "A256GCM").
The example re-uses the keys and parameters of the example computation in Appendix C
of <xref target="RFC7518"/>, with the addition of an extra static key-pair for Alice.
</t>
<t>
When used in this way, ECDH-1PU has similar security properties to the "K" one-way
handshake pattern of <xref target="Noise"/>, although it is quite different in details.
</t>
<t>
In this example, a producer Alice is encrypting content to a consumer Bob. Alice's
static key-pair (in JWK format) used for the key agreement in this example (including
the private part) is:
</t>
<figure>
<artwork><![CDATA[
{"kty":"EC",
"crv":"P-256",
"x":"WKn-ZIGevcwGIyyrzFoZNBdaq9_TsqzGl96oc0CWuis",
"y":"y77t-RvAHRKTsSGdIYUfweuOvwrvDD-Q3Hv5J0fSKbE",
"d":"Hndv7ZZjs_ke8o9zXYo3iq-Yr8SewI5vrqd0pAvEPqg"}
]]></artwork>
</figure>
<t>
Bob's static key-pair (in JWK format) is:
</t>
<figure><artwork><![CDATA[
{"kty":"EC",
"crv":"P-256",
"x":"weNJy2HscCSM6AEDTDg04biOvhFhyyWvOHQfeF_PxMQ",
"y":"e8lnCO-AlStT-NJVX-crhB7QRYhiix03illJOVAOyck",
"d":"VEmDZpDXXK8p8N0Cndsxs924q6nS1RXFASRl6BfUqdw"}
]]></artwork></figure>
<t>
The producer (Alice) generates an ephemeral key for the key agreement computation.
Alice's ephemeral key (in JWK format) is:
</t>
<figure><artwork><![CDATA[
{"kty":"EC",
"crv":"P-256",
"x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
"y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps",
"d":"0_NxaRPUMQoAJt50Gz8YiTr8gRTwyEaCumd-MToTmIo"}
]]></artwork></figure>
<t>
Header Parameter values used in this example are as follows. The
"apu" (agreement PartyUInfo) Header Parameter value is the base64url
encoding of the UTF-8 string "Alice" and the "apv" (agreement
PartyVInfo) Header Parameter value is the base64url encoding of the
UTF-8 string "Bob". The "epk" (ephemeral public key) Header
Parameter is used to communicate the producer's (Alice's) ephemeral
public key value to the consumer (Bob).
</t>
<figure><artwork><![CDATA[
{"alg":"ECDH-1PU",
"enc":"A256GCM",
"apu":"QWxpY2U",
"apv":"Qm9i",
"epk":
{"kty":"EC",
"crv":"P-256",
"x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
"y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps"
}
}
]]></artwork></figure>
<t>
The resulting one-pass KDF <xref target="NIST.800-56A"/> parameter values are:
<list style="hanging">
<t hangText="Ze">
This is set to the output of the ECDH key agreement between Alice's
ephemeral private key and Bob's static public key. In this example,
Ze is the following octet sequence (in hexadecimal notation):
</t>
</list>
</t>
<t>
<figure><artwork>
9e 56 d9 1d 81 71 35 d3 72 83 42 83 bf 84 26 9c
fb 31 6e a3 da 80 6a 48 f6 da a7 79 8c fe 90 c4</artwork></figure>
</t>
<t>
<list style="hanging">
<t hangText="Zs">
This is set to the output of the ECDH key agreement between Alice's
static private key and Bob's static public key. In this example,
Zs is the following octet sequence (in hexadecimal notation):
</t>
</list>
</t>
<t>
<figure><artwork><![CDATA[
e3 ca 34 74 38 4c 9f 62 b3 0b fd 4c 68 8b 3e 7d
41 10 a1 b4 ba dc 3c c5 4e f7 b8 12 41 ef d5 0d]]></artwork></figure>
</t>
<t>
<list style="hanging">
<t hangText="Z">
This is set to the concatenation of Ze followed by Zs. In this example,
Z is the following octet sequence (in hexadecimal notation):
</t>
</list>
</t>
<t>
<figure><artwork><![CDATA[
9e 56 d9 1d 81 71 35 d3 72 83 42 83 bf 84 26 9c
fb 31 6e a3 da 80 6a 48 f6 da a7 79 8c fe 90 c4
e3 ca 34 74 38 4c 9f 62 b3 0b fd 4c 68 8b 3e 7d
41 10 a1 b4 ba dc 3c c5 4e f7 b8 12 41 ef d5 0d]]></artwork></figure>
</t>
<t>
<list style="hanging">
<t hangText="keydatalen">
This value is 256 - the number of bits in the desired output key
(because "A256GCM" uses a 256-bit key).
</t>
<t hangText="AlgorithmID">
This is set to the octets representing the 32-bit big-endian value
7 - 00 00 00 07 in hexadecimal notation - the number of octets in
the AlgorithmID content "A256GCM", followed by the octets representing
the ASCII string "A256GCM" - 41 32 35 36 47 43 4d (in hex). The
complete value is therefore: 00 00 00 07 41 32 35 36 47 43 4d
</t>
<t hangText="PartyUInfo">
This is set to the octets representing the 32-bit big-endian value
5, followed by the octets representing the UTF-8 string "Alice". In
hexadecimal notation: 00 00 00 05 41 6c 69 63 65
</t>
<t hangText="PartyVInfo">
This is set to the octets representing the 32-bit big-endian value
3, followed by the octets representing the UTF-8 string "Bob". In
hexadecimal notation: 00 00 00 03 42 6f 62
</t>
<t hangText="SuppPubInfo">
This is set to the octets representing the 32-bit big-endian value
256 - the keydatalen value. In hexadecimal notation: 00 00 01 00
</t>
<t hangText="SuppPrivInfo">
This is set to the empty octet sequence.
</t>
</list>
</t>
<t>
Concatenating the parameters AlgorithmID through SuppPrivInfo results in a FixedInfo
value in Concatenation Format (as per Section 5.8.2.1.1 of <xref target="NIST.800-56A"/>)
of (in hexidecimal notation):
</t>
<t>
<figure><artwork><![CDATA[
00 00 00 07 41 32 35 36 47 43 4d 00 00 00 05 41
6c 69 63 65 00 00 00 03 42 6f 62 00 00 01 00
]]></artwork></figure>
</t>
<t>
Concatenating the round number 1 (00 00 00 01), Z, and the FixedInfo value results in
a one-pass KDF round 1 hash input of (hexadecimal):
</t>
<t>
<figure><artwork><![CDATA[
00 00 00 01 9e 56 d9 1d 81 71 35 d3 72 83 42 83
bf 84 26 9c fb 31 6e a3 da 80 6a 48 f6 da a7 79
8c fe 90 c4 e3 ca 34 74 38 4c 9f 62 b3 0b fd 4c
68 8b 3e 7d 41 10 a1 b4 ba dc 3c c5 4e f7 b8 12
41 ef d5 0d 00 00 00 07 41 32 35 36 47 43 4d 00
00 00 05 41 6c 69 63 65 00 00 00 03 42 6f 62 00
00 01 00 ]]></artwork></figure>
</t>
<t>
The resulting derived key, which is the full 256 bits of the round 1 hash output is:
</t>
<t>
<figure><artwork><![CDATA[
6c af 13 72 3d 14 85 0a d4 b4 2c d6 dd e9 35 bf
fd 2f ff 00 a9 ba 70 de 05 c2 03 a5 e1 72 2c a7
]]></artwork></figure>
</t>
<t>
The base64url-encoded representation of this derived key is:
</t>
<t>
<figure><artwork><![CDATA[
bK8Tcj0UhQrUtCzW3ek1v_0v_wCpunDeBcIDpeFyLKc
]]></artwork></figure>
</t>
</section>
<section anchor="handshake" title="Example Interactive Handshake">
<t>
This example use ECDH-1PU in Direct Key Agreement mode using the X448 curve
from <xref target="RFC8037"/> to perform a two-way interactive handshake.
When used in this way, ECDH-1PU has similar security properties to the
"KK" interactive handshake pattern of <xref target="Noise"/>. Messages are
encrypted using the "A256GCM" encryption method ("enc" Header Parameter value).
</t>
<t>
In this example, a producer Alice is encrypting content to a consumer Bob.
Alice's static key-pair (in JWK format) including the private key part is
(with linebreaks added for display purposes only):
</t>
<t>
<figure><artwork><![CDATA[
{"kty":"OKP",
"kid":"alice-static",
"crv": "X448",
"x":"qaggoGo7qFwBrBtxv4hwI09UaiQmCrF1KdHvaXrzjzzInqDD0Cfx9GlGFi2367
RATs-hBoB2IHw",
"d":"hJW9knOYfyCIkZnW922U81uDNNfAwcVeNcpbaQIKyh0iW5LSpDLSmBdPSyvOh7
J4u9hArU2uoX0"}
]]></artwork></figure>
</t>
<t>
Bob's static key-pair (in JWK format) including the private key part is (with
linebreaks added for display purposes only):
</t>
<t>
<figure><artwork><![CDATA[
{"kty":"OKP",
"kid":"bob-static",
"crv":"X448",
"x":"4jvO2Ef15DErhV5_5OzoaZDQ2tVb_jHB09eNruOkCTETatzOZ2EGgJCkXNElWR
sLnbns3TtYYSY",
"d":"HGKc9R7_Zso3BCnrhzA9GzOzHKHOkMYvb_n54aJ1qkO1qYYTEUS0OQmBZTq1NK
R5_kmiX5e5r-I"}
]]></artwork></figure>
</t>
<section title="Initial message from Alice to Bob">
<t>
Alice generates an ephemeral key-pair for her handshake with Bob.
Alice's ephemeral key-pair in JWK format is (with linebreaks added
for display purposes only):
</t>
<t>
<figure><artwork><![CDATA[
{"kty":"OKP",
"kid":"alice-ephemeral",
"crv":"X448",
"x":"6DRxSemaGVx1iVEPRyOAcTKS2zJsi0oZ9bR-IhZUJtezxjSXroVoDTf-RVYBjS
XdwkLOIGKSI74",
"d":"8epzr7H0N7ZIIOZeNckLL3iAHfSmIDeb-cMSgI8PJzyQfjZB0tHoGFtkQG7cAK
xP0Fi6Bbfbe7I"}
]]></artwork></figure>
</t>
<t>
The following JWE Protected Header is used for the message (with
line breaks and whitespace added for display purposes):
</t>
<t>
<figure><artwork><![CDATA[
{"typ":"JWT",
"epk":{
"kty":"OKP",
"crv":"X448",
"x":"6DRxSemaGVx1iVEPRyOAcTKS2zJsi0oZ9bR-IhZUJtezxjSXroVoDTf-RVYB
jSXdwkLOIGKSI74"},
"apv":"Qm9i",
"apu":"QWxpY2U",
"kid":"bob-static",
"enc":"A256GCM",
"alg":"ECDH-1PU"} ]]></artwork></figure>
</t>
<t>
After removing all whitespace, the octets of ASCII(BASE64URL(UTF8(JWE Protected Header)))
are as follows (in hexadecimal notation):
</t>
<t>
<figure><artwork><![CDATA[
65 79 4a 30 65 58 41 69 4f 69 4a 4b 56 31 51 69
4c 43 4a 6c 63 47 73 69 4f 6e 73 69 61 33 52 35
49 6a 6f 69 54 30 74 51 49 69 77 69 59 33 4a 32
49 6a 6f 69 57 44 51 30 4f 43 49 73 49 6e 67 69
4f 69 49 32 52 46 4a 34 55 32 56 74 59 55 64 57
65 44 46 70 56 6b 56 51 55 6e 6c 50 51 57 4e 55
53 31 4d 79 65 6b 70 7a 61 54 42 76 57 6a 6c 69
55 69 31 4a 61 46 70 56 53 6e 52 6c 65 6e 68 71
55 31 68 79 62 31 5a 76 52 46 52 6d 4c 56 4a 57
57 55 4a 71 55 31 68 6b 64 32 74 4d 54 30 6c 48
53 31 4e 4a 4e 7a 51 69 66 53 77 69 59 58 42 32
49 6a 6f 69 55 57 30 35 61 53 49 73 49 6d 46 77
64 53 49 36 49 6c 46 58 65 48 42 5a 4d 6c 55 69
4c 43 4a 72 61 57 51 69 4f 69 4a 69 62 32 49 74
63 33 52 68 64 47 6c 6a 49 69 77 69 5a 57 35 6a
49 6a 6f 69 51 54 49 31 4e 6b 64 44 54 53 49 73
49 6d 46 73 5a 79 49 36 49 6b 56 44 52 45 67 74
4d 56 42 56 49 6e 30 ]]></artwork></figure>
</t>
<t>
The resulting one-pass KDF <xref target="NIST.800-56A"/> parameter values are:
<list style="hanging">
<t hangText="Ze">
This is set to the output of the X448 key agreement between Alice's
ephemeral private key and Bob's static public key. In this example,
Ze is the following octet sequence (in hexadecimal notation):
</t>
</list>
</t>
<t>
<figure><artwork><![CDATA[
4c b2 b9 11 cd 1c 0a 69 d2 89 4f 39 3b 94 34 29
61 02 40 f4 19 fc 09 2e bc 06 eb a2 c8 27 17 33
d2 7d ea 64 c8 b6 4d 66 de c1 db ce 6d de a1 b3
a5 d3 12 c7 9a 0c e1 47 ]]></artwork></figure>
</t>
<t>
<list style="hanging">
<t hangText="Zs">
This is set to the output of the X448 key agreement between Alice's
static private key and Bob's static public key. In this example,
Zs is the following octet sequence (in hexadecimal notation):
</t>
</list>
</t>
<t>
<figure><artwork><![CDATA[
d8 8e aa 18 61 a4 8e a4 69 7b e0 99 c6 bc 3b 73
4f 0e 13 6d ed e7 75 d3 f3 a2 f4 86 b7 47 ba f0
e0 39 b1 b6 c1 62 84 07 86 52 0c ff 0c 69 58 db
ff a5 06 0c 08 5e 77 38 ]]></artwork></figure>
</t>
<t>
<list style="hanging">
<t hangText="Z">
This is set to the concatenation of Ze followed by Zs. In this example,
Z is the following octet sequence (in hexadecimal notation):
</t>
</list>
</t>
<t>
<figure><artwork><![CDATA[
4c b2 b9 11 cd 1c 0a 69 d2 89 4f 39 3b 94 34 29
61 02 40 f4 19 fc 09 2e bc 06 eb a2 c8 27 17 33
d2 7d ea 64 c8 b6 4d 66 de c1 db ce 6d de a1 b3
a5 d3 12 c7 9a 0c e1 47 d8 8e aa 18 61 a4 8e a4
69 7b e0 99 c6 bc 3b 73 4f 0e 13 6d ed e7 75 d3
f3 a2 f4 86 b7 47 ba f0 e0 39 b1 b6 c1 62 84 07
86 52 0c ff 0c 69 58 db ff a5 06 0c 08 5e 77 38 ]]></artwork></figure>
</t>
<t>
<list style="hanging">
<t hangText="keydatalen">
This value is 256, because "A256GCM" uses a 256-bit key.
</t>
<t hangText="AlgorithmID">
This is set to the octets representing the 32-bit big-endian
value 7 followed by the octets representing the ASCII string
"A256GCM". In hexadecimal notation: 00 00 00 07 41 32 35 36 47 43 4d
</t>
<t hangText="PartyUInfo">
This is set to the octets representing the 32-bit big-endian
value 5 followed by the octets representing the UTF-8 string
"Alice". In hexadecimal notation: 00 00 00 05 41 6c 69 63 65
</t>
<t hangText="PartyVInfo">
This is set to the octets representing the 32-bit big-endian
value 3 followed by the octets representing the UTF-8 string
"Bob". In hexadecimal notation: 00 00 00 03 42 6f 62
</t>
<t hangText="SuppPubInfo">
This is set to the octets representing the 32-bit big endian
value 256 - the keydatalen value. In hexadecimal: 00 00 01 00
</t>
<t hangText="SuppPrivInfo">
This is set to the empty octet sequence.
</t>
</list>
</t>
<t>
Concatenating the parameters AlgorithmID through SuppPubInfo results in
a FixedInfo value of (in hex):
</t>
<t>
<figure><artwork><![CDATA[
00 00 00 07 41 32 35 36 47 43 4d 00 00 00 05 41
6c 69 63 65 00 00 00 03 42 6f 62 00 00 01 00 ]]></artwork></figure>
</t>
<t>
Concatenating the round number 1 (00 00 00 01), Z, and the FixedInfo value
results in the KDF round 1 hash input of:
</t>
<t>
<figure><artwork><![CDATA[
00 00 00 01 4c b2 b9 11 cd 1c 0a 69 d2 89 4f 39
3b 94 34 29 61 02 40 f4 19 fc 09 2e bc 06 eb a2
c8 27 17 33 d2 7d ea 64 c8 b6 4d 66 de c1 db ce
6d de a1 b3 a5 d3 12 c7 9a 0c e1 47 d8 8e aa 18
61 a4 8e a4 69 7b e0 99 c6 bc 3b 73 4f 0e 13 6d
ed e7 75 d3 f3 a2 f4 86 b7 47 ba f0 e0 39 b1 b6
c1 62 84 07 86 52 0c ff 0c 69 58 db ff a5 06 0c
08 5e 77 38 00 00 00 07 41 32 35 36 47 43 4d 00
00 00 05 41 6c 69 63 65 00 00 00 03 42 6f 62 00
00 01 00 ]]></artwork></figure>
</t>
<t>
The resulting derived key, which is the full 256-bits of the round 1
hash output is:
</t>
<t>
<figure><artwork><![CDATA[
3e 22 44 01 ab cf 8b 1a 93 63 bd 2b 6c 8e 85 c4
e0 c7 b9 8c ad 3b 51 aa 3f 04 a4 9d 0c 29 da 0c ]]></artwork></figure>
</t>
<t>
Alice then generates a random 96-bit Initialization Vector (IV) for A256GCM.
In hexadecimal format:
</t>
<t>
<figure><artwork><![CDATA[
3b c5 10 62 97 3c 45 8d 5a 6f 2d 8d ]]></artwork></figure>
</t>
<t>
Alice uses the derived key and the IV to encrypt and authenticate the following
plaintext JWT Claims Set <xref target="RFC7519"/>, with the octets of the encoded
JWE Protected Header as the Additional Authenticated Data.
</t>
<t>
<figure><artwork><![CDATA[
{"msg":"Hello Mike","aud":"Bob","iss":"Alice"} ]]></artwork></figure>
</t>
<t>
In hexadecimal notation, the UTF-8 bytes of this plaintext are:
</t>
<t>
<figure><artwork><![CDATA[
7b 22 6d 73 67 22 3a 22 48 65 6c 6c 6f 20 4d 69
6b 65 22 2c 22 61 75 64 22 3a 22 42 6f 62 22 2c
22 69 73 73 22 3a 22 41 6c 69 63 65 22 7d ]]></artwork></figure>
</t>
<t>
The resulting Authentication Tag value is:
</t>
<t>
<figure><artwork><![CDATA[
4b 39 e8 a7 70 ec eb e3 46 f4 af 77 af 22 4f 42 ]]></artwork></figure>
</t>
<t>
The JWE Ciphertext is:
</t>
<t>
<figure><artwork><![CDATA[
b5 bd c4 83 44 54 be 02 04 f6 b5 d5 cd 9c 0d f6
95 57 ab d9 4b ba d4 4f f4 70 0e 57 55 a2 c0 fc
21 ca 63 56 38 93 7b fb 06 3e 60 f4 a4 cb ]]></artwork></figure>
</t>
<t>
Alice assembles the complete message in JWE Compact Serialization format
and sends it to Bob (with line breaks added for display purposes only):
</t>
<t>
<figure><artwork><![CDATA[
eyJ0eXAiOiJKV1QiLCJlcGsiOnsia3R5IjoiT0tQIiwiY3J
2IjoiWDQ0OCIsIngiOiI2RFJ4U2VtYUdWeDFpVkVQUnlPQW
NUS1MyekpzaTBvWjliUi1JaFpVSnRlenhqU1hyb1ZvRFRmL
VJWWUJqU1hkd2tMT0lHS1NJNzQifSwiYXB2IjoiUW05aSIs
ImFwdSI6IlFXeHBZMlUiLCJraWQiOiJib2Itc3RhdGljIiw
iZW5jIjoiQTI1NkdDTSIsImFsZyI6IkVDREgtMVBVIn0..O
8UQYpc8RY1aby2N.tb3Eg0RUvgIE9rXVzZwN9pVXq9lLutR
P9HAOV1WiwPwhymNWOJN7-wY-YPSkyw.Sznop3Ds6-NG9K9
3ryJPQg ]]></artwork></figure>
</t>
<t>
The message is 383 octets in size.
</t>
</section>
<section title="Response message from Bob to Alice">
<t>
Bob receives the message from Alice and decrypts it, using Alice's
(known) static public key to authenticate that the message did
indeed come from Alice. Bob wishes to establish an interactive secure
channel with Alice, so replies to her message using the ephemeral
key from her initial message as Alice's public key.
</t>
<t>
Bob generates a fresh ephemeral key-pair of his own. In this example,
Bob's ephemeral key-pair (in JWK format) is as follows, including the
private key parts (with linebreaks added for display purposes only):
</t>
<t>
<figure><artwork><![CDATA[
{"kty":"OKP",
"kid":"bob-ephemeral",
"crv":"X448",
"x":"_a4lG0EVO62pyVyuGjCIzHYII7vjEBqf02CcNMCHUjWvRMKbkZB-XQ0uzhByXl
jx0bNgpAvmf84",
"d":"bNy3py2jvaYOnnzkxV3nOYazDEWTeEOEtTGK7eH-Cjp_m4uCOS-AYqmcUDJCyG
uFj340p3ld0NA"} ]]></artwork></figure>
</t>
<t>
Bob generates the following JWE Protected Header for his reply to
Alice (with line breaks and whitespace added for display only):
</t>
<t>
<figure><artwork><![CDATA[
{"typ":"JWT",
"epk":{
"kty":"OKP",
"crv":"X448",
"x":"_a4lG0EVO62pyVyuGjCIzHYII7vjEBqf02CcNMCHUjWvRMKbkZB-XQ0uzhBy
Xljx0bNgpAvmf84"},
"apv":"QWxpY2U",
"apu":"Qm9i",
"kid":"alice-ephemeral",
"enc":"A256GCM",
"alg":"ECDH-1PU"} ]]></artwork></figure>
</t>
<t>
After removing all whitespace, the octets of
ASCII(BASE64URL(UTF8(JWE Protected Header))) are as follows (in
hexadecimal notation):
</t>
<t>
<figure><artwork><![CDATA[
65 79 4a 30 65 58 41 69 4f 69 4a 4b 56 31 51 69
4c 43 4a 6c 63 47 73 69 4f 6e 73 69 61 33 52 35
49 6a 6f 69 54 30 74 51 49 69 77 69 59 33 4a 32
49 6a 6f 69 57 44 51 30 4f 43 49 73 49 6e 67 69
4f 69 4a 66 59 54 52 73 52 7a 42 46 56 6b 38 32
4d 6e 42 35 56 6e 6c 31 52 32 70 44 53 58 70 49
57 55 6c 4a 4e 33 5a 71 52 55 4a 78 5a 6a 41 79
51 32 4e 4f 54 55 4e 49 56 57 70 58 64 6c 4a 4e
53 32 4a 72 57 6b 49 74 57 46 45 77 64 58 70 6f