forked from agl/gcmsiv
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathgcmsiv.xml
1972 lines (1751 loc) · 96.5 KB
/
gcmsiv.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" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC3610 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3610.xml">
<!ENTITY RFC5116 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5116.xml">
<!ENTITY RFC5297 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5297.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" ipr="trust200902" number="8452" submissionType="IRTF"
consensus="yes">
<front>
<title abbrev="AES-GCM-SIV">AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption</title>
<author fullname="Shay Gueron" initials="S." surname="Gueron">
<organization abbrev="University of Haifa & AWS">University of Haifa and Amazon</organization>
<address>
<postal>
<street>Abba Khoushy Ave 199</street>
<city>Haifa</city>
<code>3498838</code>
<country>Israel</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Adam Langley" initials="A." surname="Langley">
<organization>Google LLC</organization>
<address>
<postal>
<street>345 Spear St</street>
<city>San Francisco</city>
<region>CA</region>
<code>94105</code>
<country>United States of America</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Yehuda Lindell" initials="Y." surname="Lindell">
<organization>Bar-Ilan University and Unbound Tech</organization>
<address>
<postal>
<street>Ramat Gan</street>
<code>5290002</code>
<country>Israel</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date month="April" year="2019" />
<workgroup>Crypto Forum</workgroup>
<keyword>authenticated encryption</keyword>
<keyword>aead</keyword>
<keyword>aes</keyword>
<keyword>gcm</keyword>
<keyword>siv</keyword>
<abstract>
<t>This memo specifies two authenticated encryption algorithms that are
nonce misuse resistant -- that is, they do not fail catastrophically
if a nonce is repeated.</t>
<t>This document is the product of the Crypto Forum Research Group.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The concept of Authenticated Encryption with Additional Data (AEAD)
<xref target="RFC5116"/> couples confidentiality and integrity in a
single operation, avoiding the risks of the previously common practice
of using ad hoc constructions of block-cipher and hash primitives. The
most popular AEAD, AES-GCM <xref target="GCM"/>, is seeing widespread
use due to its attractive performance.</t>
<t>However, some AEADs (including AES-GCM) suffer catastrophic failures
of confidentiality and/or integrity when two distinct messages are
encrypted with the same key and nonce. While the requirements for AEADs
specify that the pair of (key, nonce) shall only ever be used once, and
thus prohibit this, this is a worry in practice.</t>
<t>Nonce misuse-resistant AEADs do not suffer from this problem. For this class of AEADs, encrypting two messages with the same nonce only discloses whether the messages were equal or not. This is the minimum amount of information that a deterministic algorithm can leak in this situation.</t>
<t>This memo specifies two nonce misuse-resistant AEADs:
AEAD_AES_128_GCM_SIV and AEAD_AES_256_GCM_SIV. These AEADs are designed
to be able to take advantage of existing hardware support for AES-GCM
and can decrypt within 5% of the speed of AES-GCM (for multikilobyte
messages). Encryption is, perforce, slower than AES‑GCM, because two
passes are required in order to achieve that nonce misuse-resistance
property. However, measurements suggest that it can still run at
two-thirds of the speed of AES-GCM.</t>
<t>We suggest that these AEADs be considered in any situation where
nonce uniqueness cannot be guaranteed. This includes situations where
there is no stateful counter or where such state cannot be guaranteed,
as when multiple encryptors use the same key. As discussed in <xref
target="seccon"></xref>, it is RECOMMENDED to use this scheme with
randomly chosen nonces.</t>
<t>This document represents the consensus of the Crypto Forum Research Group (CFRG).</t>
</section>
<section title="Requirements Language">
<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="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section title="POLYVAL">
<t>The GCM-SIV construction is similar to GCM: the block cipher is used
in counter mode to encrypt the plaintext, and a polynomial authenticator
is used to provide integrity. The authenticator in GCM-SIV is called
POLYVAL.</t>
<t>POLYVAL, like GHASH (the authenticator in AES-GCM; see <xref
target="GCM"/>, Section 6.4), operates in a binary field of size
2^128. The field is defined by the irreducible polynomial x^128 + x^127
+ x^126 + x^121 + 1. The sum of any two elements in the field is the
result of XORing them. The product of any two elements is calculated
using standard (binary) polynomial multiplication followed by reduction
modulo the irreducible polynomial.</t>
<t>We define another binary operation on elements of the field:
<vspace />
dot(a, b), where dot(a, b) = a * b * x^-128. The value of the field element
x^-128 is equal to x^127 + x^124 + x^121 + x^114 + 1. The result of this
multiplication, dot(a, b), is another field element.</t>
<t>Polynomials in this field are converted to and from 128-bit strings
by taking the least significant bit of the first byte to be the
coefficient of x^0, the most significant bit of the first byte to be the
coefficient of x^7, and so on, until the most significant bit of the
last byte is the coefficient of x^127.</t>
<t>POLYVAL takes a field element, H, and a series of field elements
<vspace />
X_1, ..., X_s. Its result is S_s, where S is defined by the iteration S_0 =
0; S_j = dot(S_{j-1} + X_j, H), for j = 1..s.</t>
<t>We note that POLYVAL(H, X_1, X_2, ...) is equal to
ByteReverse(GHASH(ByteReverse(H) * x, ByteReverse(X_1),
ByteReverse(X_2), ...)), where ByteReverse is a function that reverses
the order of 16 bytes. See <xref target="ghash"></xref> for a more
detailed explanation.</t>
</section>
<section title="Encryption">
<t>AES-GCM-SIV encryption takes a 16- or 32-byte key-generating key, a
96-bit nonce, and plaintext and additional data
byte strings of variable length. It outputs an authenticated ciphertext that will be 16
bytes longer than the plaintext. Both encryption and decryption are only
defined on inputs that are a whole number of bytes.</t>
<t>If the key-generating key is 16 bytes long, then AES-128 is used
throughout. Otherwise, AES-256 is used throughout.</t>
<t>The first step of encryption is to generate per-nonce,
message-authentication and message-encryption keys. The
message-authentication key is 128 bit, and the message-encryption key is
either 128 (for AES-128) or 256 bit (for AES-256).</t>
<t>These keys are generated by encrypting a series of plaintext blocks
that contain a 32-bit, little-endian counter followed by the nonce, and
then discarding the second half of the resulting ciphertext. In the
AES-128 case, 128 + 128 = 256 bits of key material need to be generated,
and, since encrypting each block yields 64 bits after discarding half,
four blocks need to be encrypted. The counter values for these blocks
are 0, 1, 2, and 3. For AES-256, six blocks are needed in total, with
counter values 0 through 5 (inclusive).</t>
<t>In pseudocode form, where "++" indicates concatenation and "x[:8]" indicates taking only the first eight bytes from x:</t>
<figure align="center">
<artwork align="left"><![CDATA[
func derive_keys(key_generating_key, nonce) {
message_authentication_key =
AES(key = key_generating_key,
block = little_endian_uint32(0) ++ nonce)[:8] ++
AES(key = key_generating_key,
block = little_endian_uint32(1) ++ nonce)[:8]
message_encryption_key =
AES(key = key_generating_key,
block = little_endian_uint32(2) ++ nonce)[:8] ++
AES(key = key_generating_key,
block = little_endian_uint32(3) ++ nonce)[:8]
if bytelen(key_generating_key) == 32 {
message_encryption_key ++=
AES(key = key_generating_key,
block = little_endian_uint32(4) ++ nonce)[:8] ++
AES(key = key_generating_key,
block = little_endian_uint32(5) ++ nonce)[:8]
}
return message_authentication_key, message_encryption_key
}
]]></artwork>
</figure>
<t>Define the "length block" as a 16-byte value that is the concatenation of the 64-bit, little-endian encodings of bytelen(additional_data) * 8 and bytelen(plaintext) * 8. Pad the plaintext and additional data with zeros until they are each a multiple of 16 bytes, the AES block size. Then X_1, X_2, ... (the series of field elements that are inputs to POLYVAL) are the concatenation of the padded additional data, the padded plaintext, and the length block.</t>
<t>Calculate S_s = POLYVAL(message-authentication-key, X_1, X_2,
...). XOR the first twelve bytes of S_s with the nonce and clear the
most significant bit of the last byte. Encrypt the result with AES using the message-encryption key to produce the tag.</t>
<!--[rfced] Are the underscores around the word "plaintext"
being used for emphasis or another purpose, or may we remove them?
Original:
(It's worth highlighting a contrast with AES-GCM here: AES-GCM
authenticates the encoded additional data and ciphertext, while AES-
GCM-SIV authenticates the encoded additional data and _plaintext_.)
-->
<t>(It's worth highlighting a contrast with AES-GCM here: AES-GCM
authenticates the encoded additional data and ciphertext, while
AES‑GCM-SIV authenticates the encoded additional data and <spanx
style="emph">plaintext</spanx>.)</t>
<t>The encrypted plaintext is produced by using AES, with the
message-encryption key, in counter mode (see <xref target="SP800-38A"/>,
Section 6.5) on the unpadded plaintext. The initial counter block is the
tag with the most significant bit of the last byte set to one. The
counter advances by incrementing the first 32 bits interpreted as an
unsigned, little-endian integer, wrapping at 2^32. The result of the
encryption is the encrypted plaintext (truncated to the length of the
plaintext), followed by the tag.</t>
<t>In pseudocode form, the encryption process can be expressed as:</t>
<figure align="center">
<artwork align="left"><![CDATA[
func right_pad_to_multiple_of_16_bytes(input) {
while (bytelen(input) % 16 != 0) {
input = input ++ "\x00"
}
return input
}
func AES_CTR(key, initial_counter_block, in) {
block = initial_counter_block
output = ""
while bytelen(in) > 0 {
keystream_block = AES(key = key, block = block)
block[0:4] = little_endian_uint32(
read_little_endian_uint32(block[0:4]) + 1)
todo = min(bytelen(in), bytelen(keystream_block)
for j = 0; j < todo; j++ {
output = output ++ (keystream_block[j] ^ in[j])
}
in = in[todo:]
}
return output
}
func encrypt(key_generating_key,
nonce,
plaintext,
additional_data) {
if bytelen(plaintext) > 2^36 {
fail()
}
if bytelen(additional_data) > 2^36 {
fail()
}
message_encryption_key, message_authentication_key =
derive_keys(key_generating_key, nonce)
length_block =
little_endian_uint64(bytelen(additional_data) * 8) ++
little_endian_uint64(bytelen(plaintext) * 8)
padded_plaintext = right_pad_to_multiple_of_16_bytes(plaintext)
padded_ad = right_pad_to_multiple_of_16_bytes(additional_data)
S_s = POLYVAL(key = message_authentication_key,
input = padded_ad ++ padded_plaintext ++
length_block)
for i = 0; i < 12; i++ {
S_s[i] ^= nonce[i]
}
S_s[15] &= 0x7f
tag = AES(key = message_encryption_key, block = S_s)
counter_block = tag
counter_block[15] |= 0x80
return AES_CTR(key = message_encryption_key,
initial_counter_block = counter_block,
in = plaintext) ++
tag
}
]]></artwork>
</figure>
</section>
<section title="Decryption">
<t>Decryption takes a 16- or 32-byte key-generating key, a 96-bit nonce,
and ciphertext and additional data byte strings of variable length. It
either fails or outputs a plaintext that is 16 bytes shorter than the
ciphertext.</t>
<t>To decrypt an AES-GCM-SIV ciphertext, first derive the message-encryption and message-authentication keys in the same manner as when encrypting.</t>
<t>If the ciphertext is less than 16 bytes or more than 2^36 + 16 bytes,
then fail. Otherwise, split the input into the encrypted plaintext and a
16-byte tag. Decrypt the encrypted plaintext with the message-encryption
key in counter mode, where the initial counter block is the tag with the
most significant bit of the last byte set to one. Advance the counter
for each block in the same way as when encrypting. At this point, the
plaintext is unauthenticated and MUST NOT be output until the following
tag confirmation is complete:</t>
<t>Pad the additional data and plaintext with zeros until they are each
a multiple of 16 bytes, the AES block size. Calculate the length block
and X_1, X_2, ... as above and compute
<vspace />
S_s = POLYVAL(message-authentication-key, X_1, X_2, ...)
</t>
<t>
Compute the expected
tag by XORing S_s and the nonce, clearing the most significant bit of
the last byte and encrypting with the message-encryption key. Compare
the provided and expected tag values in constant time. Fail the
decryption if they do not match (and do not release the plaintext);
otherwise, return the plaintext.</t>
<t>In pseudocode form, the decryption process can be expressed as:</t>
<figure align="center">
<artwork align="left"><![CDATA[
func decrypt(key_generating_key,
nonce,
ciphertext,
additional_data) {
if bytelen(ciphertext) < 16 || bytelen(ciphertext) > 2^36 + 16 {
fail()
}
if bytelen(additional_data) > 2^36 {
fail()
}
message_encryption_key, message_authentication_key =
derive_keys(key_generating_key, nonce)
tag = ciphertext[bytelen(ciphertext)-16:]
counter_block = tag
counter_block[15] |= 0x80
plaintext = AES_CTR(key = message_encryption_key,
initial_counter_block = counter_block,
in = ciphertext[:bytelen(ciphertext)-16])
length_block =
little_endian_uint64(bytelen(additional_data) * 8) ++
little_endian_uint64(bytelen(plaintext) * 8)
padded_plaintext = right_pad_to_multiple_of_16_bytes(plaintext)
padded_ad = right_pad_to_multiple_of_16_bytes(additional_data)
S_s = POLYVAL(key = message_authentication_key,
input = padded_ad ++ padded_plaintext ++
length_block)
for i = 0; i < 12; i++ {
S_s[i] ^= nonce[i]
}
S_s[15] &= 0x7f
expected_tag = AES(key = message_encryption_key, block = S_s)
xor_sum = 0
for i := 0; i < bytelen(expected_tag); i++ {
xor_sum |= expected_tag[i] ^ tag[i]
}
if xor_sum != 0 {
fail()
}
return plaintext
}
]]></artwork>
</figure>
</section>
<section title="AEADs">
<t>We define two AEADs, in the format of RFC 5116, that use AES-GCM-SIV:
AEAD_AES_128_GCM_SIV and AEAD_AES_256_GCM_SIV. They differ only in the
size of the AES key used.</t>
<t>The key input to these AEADs becomes the key-generating key. Thus,
AEAD_AES_128_GCM_SIV takes a 16-byte key and AEAD_AES_256_GCM_SIV takes
a 32-byte key.</t>
<t>The parameters for AEAD_AES_128_GCM_SIV are then as follows:
<vspace />
K_LEN is
16, P_MAX is 2^36, A_MAX is 2^36, N_MIN and N_MAX are 12, and C_MAX is
2^36 + 16.</t>
<t>The parameters for AEAD_AES_256_GCM_SIV differ only in the key size:
<vspace />
K_LEN is 32, P_MAX is 2^36, A_MAX is 2^36, N_MIN and N_MAX are 12, and C_MAX is 2^36 + 16.</t>
</section>
<section title="Field Operation Examples">
<t>Polynomials in this document will be written as 16-byte values. For example, the sixteen bytes 01000000000000000000000000000492 would represent the polynomial x^127 + x^124 + x^121 + x^114 + 1, which is also the value of x^-128 in this field.</t>
<!--[rfced] FYI, some line breaks and blank lines have been added to
make equations easier to read in Sections 5 and 7 and Appendixes
A and B. Please let us know if prefer other formatting. For example:
Original:
If a = 66e94bd4ef8a2c3b884cfa59ca342b2e and b =
ff000000000000000000000000000000 then a + b =
99e94bd4ef8a2c3b884cfa59ca342b2e, a * b =
37856175e9dc9df26ebc6d6171aa0ae9 and dot(a, b) =
ebe563401e7e91ea3ad6426b8140c394.
Current:
If a = 66e94bd4ef8a2c3b884cfa59ca342b2e and
b = ff000000000000000000000000000000,
then a + b = 99e94bd4ef8a2c3b884cfa59ca342b2e,
a * b = 37856175e9dc9df26ebc6d6171aa0ae9, and
dot(a, b) = ebe563401e7e91ea3ad6426b8140c394.
-->
<figure><artwork>
If a = 66e94bd4ef8a2c3b884cfa59ca342b2e and
b = ff000000000000000000000000000000,
then a + b = 99e94bd4ef8a2c3b884cfa59ca342b2e,
a * b = 37856175e9dc9df26ebc6d6171aa0ae9, and
dot(a, b) = ebe563401e7e91ea3ad6426b8140c394.
</artwork></figure>
</section>
<section title="Worked Example">
<t>Consider the encryption of the plaintext "Hello world" with the additional data "example" under key ee8e1ed9ff2540ae8f2ba9f50bc2f27c using AEAD_AES_128_GCM_SIV. The random nonce that we'll use for this example is 752abad3e0afb5f434dc4310.</t>
<t>In order to generate the message-authentication and
message-encryption keys, a counter is combined with the nonce to form
four blocks. These blocks are encrypted with the key given above:</t>
<figure align="center">
<artwork align="left"><![CDATA[
Counter | Nonce Ciphertext
00000000752abad3e0afb5f434dc4310 -> 310728d9911f1f38c40e952ca83d093e
01000000752abad3e0afb5f434dc4310 -> 37b24316c3fab9a046ae90952daa0450
02000000752abad3e0afb5f434dc4310 -> a4c5ae624996327947920b2d2412474b
03000000752abad3e0afb5f434dc4310 -> c100be4d7e2c6edd1efef004305ab1e7
]]></artwork>
</figure>
<t>The latter halves of the ciphertext blocks are discarded and the
remaining bytes are concatenated to form the per-message keys. Thus, the
message-authentication key is 310728d9911f1f3837b24316c3fab9a0, and the
message-encryption key is a4c5ae6249963279c100be4d7e2c6edd.</t>
<t>The length block contains the encoding of the bit lengths of the additional data and plaintext, respectively. The string "example" is seven characters, thus 56 bits (or 0x38 in hex). The string "Hello world" is 11 characters, or 88 = 0x58 bits. Thus, the length block is 38000000000000005800000000000000.</t>
<t>The input to POLYVAL is the padded additional data, padded plaintext,
and then the length block. This is
6578616d706c6500000000000000000048656c6c6f20776f726c64000000000038000000000000005800000000000000,
based on the ASCII encoding of "example" (6578616d706c65) and "Hello
world" (48656c6c6f20776f726c64).</t>
<t>Calling POLYVAL with the message-authentication key and the input above results in S_s = ad7fcf0b5169851662672f3c5f95138f.</t>
<t>Before encrypting, the nonce is XORed in and the most significant bit of the last byte is cleared. This gives d85575d8b1c630e256bb6c2c5f95130f, because that bit happened to be one previously. Encrypting with the message-encryption key (using AES‑128) gives the tag, which is 4fbcdeb7e4793f4a1d7e4faa70100af1.</t>
<t>In order to form the initial counter block, the most significant bit of the last byte of the tag is set to one. That doesn't result in a change in this example. Encrypting this with the message key (using AES-128) gives the first block of the keystream: 1551f2c1787e81deac9a99f139540ab5.</t>
<t>The final ciphertext is the result of XORing the plaintext with the keystream and appending the tag. That gives 5d349ead175ef6b1def6fd4fbcdeb7e4793f4a1d7e4faa70100af1.</t>
</section>
<section title="Security Considerations" anchor="seccon">
<t>AES-GCM-SIV decryption involves first producing an unauthenticated
plaintext. This plaintext is vulnerable to manipulation by an attacker;
thus, if an implementation released some or all of the plaintext before
authenticating it, other parts of a system may process malicious data as
if it were authentic. AES-GCM might be less likely to lead
implementations to do this because there the ciphertext is generally
authenticated before, or concurrently with, the plaintext
calculation. Therefore, this text requires that implementations MUST NOT
release unauthenticated plaintext. Thus, system designers should consider
memory limitations when picking the size of AES-GCM-SIV plaintexts:
large plaintexts may not fit in the available memory of some machines,
tempting implementations to release unverified plaintext.</t>
<t>A detailed cryptographic analysis of AES-GCM-SIV appears in <xref
target="AES-GCM-SIV"/>, and the remainder of this section is a summary of
that paper.</t>
<t>The AEADs defined in this document calculate fresh AES keys for each
nonce. This allows a larger number of plaintexts to be encrypted under a
given key. Without this step, AES-GCM-SIV encryption would be limited by
the birthday bound like other standard modes (e.g., AES-GCM, AES-CCM
<xref target="RFC3610"/>, and AES-SIV <xref target="RFC5297"/>). This
means that when 2^64 blocks have been encrypted overall, a
distinguishing adversary who is trying to break the confidentiality of
the scheme has an advantage of 1/2. Thus, in order to limit the
adversary's advantage to 2^-32, at most 2^48 blocks can be encrypted
overall. In contrast, by deriving fresh keys from each nonce, it is
possible to encrypt a far larger number of messages and blocks with
AES-GCM-SIV.</t>
<t>We stress that nonce misuse-resistant schemes guarantee that if a
nonce repeats, then the only security loss is that identical plaintexts
will produce identical ciphertexts. Since this can also be a concern (as
the fact that the same plaintext has been encrypted twice is revealed),
we do not recommend using a fixed nonce as a policy. In addition, as we
show below, better-than-birthday bounds are achieved by AES-GCM-SIV when
the nonce repetition rate is low. Finally, as shown in <xref
target="BHT18"/>, there is a great security benefit in the
multiuser/multikey setting when each particular nonce is reused by a
small number of users only. We stress that the nonce misuse-resistance
property is not intended to be coupled with intentional nonce reuse;
rather, such schemes provide the best possible security in the event of
nonce reuse. Due to all of the above, it is RECOMMENDED that AES-GCM-SIV
nonces be randomly generated.</t>
<t>Some example usage bounds for AES-GCM-SIV are given below. The
adversary's advantage is the "AdvEnc" from <xref target="key-derive"/>
and is colloquially the ability of an attacker to distinguish
ciphertexts from random bit strings. The bounds below limit this
advantage to 2^-32. For up to 256 uses of the same nonce and key (i.e.,
where one can assume that nonce misuse is no more than this bound), the
<!--[rfced] Is the correct expansion for AAD "additional authenticated data"?
Please advise how best to expand in this sentence.
Original:
For up to 256 uses of the same nonce and key (i.e., where one
can assume that nonce misuse is no more than this bound), the
following message limits should be respected (this assumes a short
AAD, i.e. less than 64 bytes):
-->
following message limits should be respected (this assumes a short AAD,
i.e. less than 64 bytes):</t>
<t><list>
<t>2^29 messages, where each plaintext is at most 1 GiB</t>
<t>2^35 messages, where each plaintext is at most 128 MiB</t>
<t>2^49 messages, where each plaintext is at most 1 MiB</t>
<t>2^61 messages, where each plaintext is at most 16 KiB</t>
</list></t>
<t>Suzuki et al. <xref target="multi-birthday"/> show that even if
nonces are selected uniformly at random, the probability that one or
more values would be repeated 256 or more times is negligible until the
number of nonces reaches 2^102. (Specifically, the probability is
1/((2^96)^(255)) * Binomial(q, 256), where q is the number of nonces.)
Since 2^102 is vastly greater than the limit on the number of plaintexts
per key given above, we don't feel that this limit on the number of
repeated nonces will be a problem. This also means that selecting nonces
at random is a safe practice with AES-GCM-SIV. The bounds obtained for
random nonces are as follows (as above, for these bounds, the
adversary's advantage is at most 2^-32):</t>
<t><list>
<t>2^32 messages, where each plaintext is at most 8 GiB</t>
<t>2^48 messages, where each plaintext is at most 32 MiB</t>
<t>2^64 messages, where each plaintext is at most 128 KiB</t>
</list></t>
<t>For situations where, for some reason, an even higher number of nonce
repeats is possible (e.g., in devices with very poor randomness), the
message limits need to be reconsidered. Theorem 7 in <xref
target="AES-GCM-SIV"/> contains more details, but for up to 1,024
repeats of each nonce, the limits would be (again assuming a short AAD,
i.e. less than 64 bytes):</t>
<t><list>
<t>2^25 messages, where each plaintext is at most 1 GiB</t>
<t>2^31 messages, where each plaintext is at most 128 MiB</t>
<t>2^45 messages, where each plaintext is at most 1 MiB</t>
<t>2^57 messages, where each plaintext is at most 16 KiB</t>
</list></t>
<t>In addition to calculating fresh AES keys for each nonce, these AEADs
also calculate fresh POLYVAL keys. Previous versions of GCM-SIV did not
do this and instead used part of the AEAD's key as the POLYVAL
key. Bleichenbacher pointed out <xref target="Bleichenbacher16"/> that this allowed an attacker who
controlled the AEAD key to force the POLYVAL key to be zero. If a user
of this AEAD authenticated messages with a secret additional-data value,
then this would be insecure as the attacker could calculate a valid
authenticator without knowing the input. This does not violate the
standard properties of an AEAD as the additional data is not assumed to
be confidential. However, we want these AEADs to be robust against plausible
misuse and also to be drop-in replacements for AES-GCM and so derive
nonce-specific POLYVAL keys to avoid this issue.</t>
<t>We also wish to note that the probability of successful forgery
increases with the number of attempts that an attacker is permitted. The
advantage defined in <xref target="key-derive"/> and used above is
specified in terms of the ability of an attacker to distinguish
ciphertexts from random bit strings. It thus covers both confidentiality
and integrity, and Theorem 6.2 in <xref target="key-derive"/> shows that
the advantage increases with the number of decryption
attempts, although much more slowly than with
the number of encryptions; the dependence on the number of decryption
queries for forgery is actually only linear, not quadratic. The latter is an
artifact of the bound in the paper not being tight. If an attacker is
permitted extremely large numbers of attempts, then the tiny probability
that any given attempt succeeds may sum to a non-trivial chance.</t>
<t>A security analysis of a similar scheme without nonce-based key
derivation appears in <xref target="GCM-SIV"/>, and a full analysis of
the bounds when applying nonce-based key derivation appears in <xref
target="key-derive"/>. A larger table of bounds and other information
appears at <xref target="aes-gcm-siv-homepage"/>.</t>
<t>The multiuser/multikey security of AES-GCM-SIV was studied by <xref
target="BHT18"/>, which showed that security is almost the same as in
the single-user setting, as long as nonces do not repeat many times
across many
users. This is the case when nonces are chosen randomly.</t>
</section>
<section title="IANA Considerations">
<t>IANA has added two entries to the "AEAD Algorithms" registry:
AEAD_AES_128_GCM_SIV (Numeric ID 30) and AEAD_AES_256_GCM_SIV (Numeric
ID 31), both referencing this document as their specification.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC8174;
<reference anchor="SP800-38A"
target="https://csrc.nist.gov/publications/detail/sp/800-38a/final">
<front>
<title>
Recommendation for Block Cipher Modes of Operation: Methods and Techniques
</title>
<author initials="M." surname="Dworkin" fullname="M. Dworkin">
<organization/>
</author>
<date year="2001" month="December"/>
</front>
<seriesInfo name="NIST SP" value="800-38A"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-38A"/>
</reference>
</references>
<references title="Informative References">
&RFC3610;
&RFC5116;
&RFC5297;
<reference anchor="GCM" target="https://csrc.nist.gov/publications/detail/sp/800-38d/final">
<front>
<title>
Recommendation for Block Cipher Modes of Operation: Galois/Counter
Mode (GCM) and GMAC
</title>
<author initials="M." surname="Dworkin" fullname="M. Dworkin">
<organization/>
</author>
<date year="2007" month="November"/>
</front>
<seriesInfo name="NIST SP" value="800-38D"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-38D"/>
</reference>
<reference anchor="AES-GCM-SIV" target="https://eprint.iacr.org/2017/168">
<front>
<title>
AES-GCM-SIV: Specification and Analysis
</title>
<author initials="S." surname="Gueron" fullname="Shay Gueron">
<organization/>
</author>
<author initials="A." surname="Langley" fullname="Adam Langley">
<organization/>
</author>
<author initials="Y." surname="Lindell" fullname="Yehuda Lindell">
<organization/>
</author>
<date year="2017" month="July"/>
</front>
</reference>
<reference anchor="BHT18" target="https://eprint.iacr.org/2018/136.pdf">
<front>
<title>
Revisiting AES-GCM-SIV: Multi-user Security, Faster Key Derivation, and Better Bounds
</title>
<author initials="P." surname="Bose" fullname="Priyanka Bose">
<organization/>
</author>
<author initials="V.T." surname="Hoang" fullname="Viet Tung Hoang">
<organization/>
</author>
<author initials="S." surname="Tessaro" fullname="Stefano Tessaro">
<organization/>
</author>
<date year="2018" month="May"/>
</front>
<seriesInfo name="Advances in Cryptology - EUROCRYPT" value="2018"/>
<seriesInfo name="DOI" value="10.1007/978-3-319-78381-9_18"/>
</reference>
<reference anchor="GCM-SIV" target="http://doi.acm.org/10.1145/2810103.2813613">
<front>
<title>
GCM-SIV: Full Nonce Misuse-Resistant Authenticated Encryption at Under One Cycle Per Byte
</title>
<author initials="S." surname="Gueron" fullname="Shay Gueron">
<organization/>
</author>
<author initials="Y." surname="Lindell" fullname="Yehuda Lindell">
<organization/>
</author>
<date month="October" year="2015"/>
</front>
<seriesInfo name="Proceedings of the 22nd ACM SIGSAC Conference on
Computer and Communications" value="Security"/>
<seriesInfo name="DOI" value="10.1145/2810103.2813613"/>
</reference>
<reference anchor="key-derive" target="https://doi.org/10.1145/3133956.3133992">
<front>
<title>
Better Bounds for Block Cipher Modes of Operation via Nonce-Based Key Derivation
</title>
<author initials="S." surname="Gueron" fullname="Shay Gueron">
<organization/>
</author>
<author initials="Y." surname="Lindell" fullname="Yehuda Lindell">
<organization/>
</author>
<date year="2017"/>
</front>
<seriesInfo name="Proceedings of the 2017 ACM SIGSAC Conference on
Computer and Communications" value="Security"/>
<seriesInfo name="DOI" value="10.1145/3133956.3133992"/>
</reference>
<reference anchor="aes-gcm-siv-homepage" target="https://cyber.biu.ac.il/aes-gcm-siv/">
<front>
<title>
Webpage for the AES-GCM-SIV Mode of Operation
</title>
<author initials="S." surname="Gueron" fullname="Shay Gueron">
<organization/>
</author>
<author initials="A." surname="Langley" fullname="Adam Langley">
<organization/>
</author>
<author initials="Y." surname="Lindell" fullname="Yehuda Lindell">
<organization/>
</author>
<date/>
</front>
</reference>
<reference anchor="multi-birthday" target="http://dx.doi.org/10.1007/11927587_5">
<front>
<title>
Birthday Paradox for Multi-collisions
</title>
<author initials="K." surname="Suzuki" fullname="Suzuki Kazuhiro">
<organization/>
</author>
<author initials="D." surname="Tonien" fullname="Tonien Dongvu">
<organization/>
</author>
<author initials="K." surname="Kurosawa" fullname="Kurosawa Kaoru">
<organization/>
</author>
<author initials="K." surname="Toyota" fullname="Toyota Koji">
<organization/>
</author>
<date year="2006"/>
</front>
<seriesInfo name="Information Security and Cryptology - ICISC 2006, Lecture Notes in Computer Science,"
value="Volume 4296"/>
<seriesInfo name="DOI" value="10.1007/11927587_5"/>
</reference>
<reference anchor="Bleichenbacher16" target="https://mailarchive.ietf.org/arch/msg/cfrg/qgh-Yxmj7CC7cq2YZLpmfGA3x-o">
<front>
<title>Subject: AES-GCM-SIV security of the additional data</title>
<author initials="D" surname="Bleichenbacher" />
<date month="24 June" year="2016" />
</front>
<seriesInfo name="message to the" value="cfrg mailing list"/>
</reference>
</references>
<section anchor="ghash" title="The Relationship between POLYVAL and GHASH">
<t>GHASH and POLYVAL both operate in GF(2^128), although with different irreducible polynomials: POLYVAL works modulo x^128 + x^127 + x^126 + x^121 + 1 and GHASH works modulo x^128 + x^7 + x^2 + x + 1. Note that these irreducible polynomials are the "reverse" of each other.</t>
<t>GHASH also has a different mapping between 128-bit strings and field
elements. Whereas POLYVAL takes the least significant to
most significant bits of the first byte to be the coefficients of x^0 to
x^7, GHASH takes them to be the coefficients of x^7 to x^0. This
continues until, for the last byte, POLYVAL takes the least significant
to most significant bits to be the coefficients of x^120 to x^127, while
GHASH takes them to be the coefficients of x^127 to x^120.</t>
<t>The combination of these facts means that it's possible to "convert" values between the two by reversing the order of the bytes in a 16-byte string. The differing interpretations of bit order takes care of reversing the bits within each byte, and then reversing the bytes does the rest. This may have a practical benefit for implementations that wish to implement both GHASH and POLYVAL.</t>
<t>In order to be clear which field a given operation is performed in,
let mulX_GHASH be a function that takes a 16-byte string, converts it to
an element of GHASH's field using GHASH's convention, multiplies it by x,
and converts it back to a string. Likewise, let mulX_POLYVAL be a function
that converts a 16-byte string to an element of POLYVAL's field using
POLYVAL's convention, multiplies it by x, and converts it back.</t>
<t>Given the 16-byte string 01000000000000000000000000000000, mulX_GHASH of that string is 00800000000000000000000000000000 and mulX_POLYVAL of that string is 02000000000000000000000000000000. As a more general example, given 9c98c04df9387ded828175a92ba652d8, mulX_GHASH of that string is 4e4c6026fc9c3ef6c140bad495d3296c and mulX_POLYVAL of it is 3931819bf271fada0503eb52574ca5f2.</t>
<t>Lastly, let ByteReverse be the function that takes a 16-byte string and returns a copy where the order of the bytes has been reversed.</t>
<t>Now GHASH and POLYVAL can be defined in terms of one another:</t>
<t>POLYVAL(H, X_1, ..., X_n) = ByteReverse(GHASH(mulX_GHASH(ByteReverse(H)), ByteReverse(X_1), ..., ByteReverse(X_n)))</t>
<t>GHASH(H, X_1, ..., X_n) = ByteReverse(POLYVAL(mulX_POLYVAL(ByteReverse(H)), ByteReverse(X_1), ..., ByteReverse(X_n)))</t>
<figure><artwork>
As a worked example:
let H = 25629347589242761d31f826ba4b757b,
X_1 = 4f4f95668c83dfb6401762bb2d01a262, and
X_2 = d1a24ddd2721d006bbe45f20d3c9f362.
POLYVAL(H, X_1, X_2) = f7a3b47b846119fae5b7866cf5e5b77e.
</artwork></figure>
<t>
If we wished to calculate this given only an implementation of GHASH, then the
key for GHASH would be
</t>
<figure><artwork>
mulX_GHASH(ByteReverse(H)) = dcbaa5dd137c188ebb21492c23c9b112.
Then ByteReverse(GHASH(dcba..., ByteReverse(X_1), ByteReverse(X_2)))
= f7a3b47b846119fae5b7866cf5e5b77e, as required.
</artwork></figure>
<t>In the other direction, GHASH(H, X_1, X_2) =
bd9b3997046731fb96251b91f9c99d7a. If we wished to calculate this given
only an implementation of POLYVAL, then we would first calculate the key
for POLYVAL: </t>
<figure><artwork>
mulX_POLYVAL(ByteReverse(H)) = f6ea96744df0633aec8424b18e26c54a.
Then ByteReverse(POLYVAL(f6ea..., ByteReverse(X_1), ByteReverse(X_2)))
= bd9b3997046731fb96251b91f9c99d7a.
</artwork></figure>
</section>
<section anchor="aesgcm" title="Additional Comparisons with AES-GCM">
<t>Some functional properties that differ between AES-GCM and
AES-GCM-SIV that are also worth noting:</t>
<t>AES-GCM allows plaintexts to be encrypted in a streaming fashion -- i.e., the beginning of the plaintext can be encrypted and transmitted before the entire message has been processed. AES-GCM-SIV requires two passes for encryption and so cannot do this.</t>
<t>AES-GCM allows a constant additional-data input to be precomputed in order to save per-message computation. AES-GCM-SIV varies the authenticator key based on the nonce and so does not permit this.</t>
<t>The performance for AES-GCM vs. AES-GCM-SIV on small machines can be
roughly characterized by the number of AES operations and the number of
GF(2^128) multiplications needed to process a message.</t>
<figure><artwork>
Let a = (bytelen(additional-data) + 15) / 16 and
p = (bytelen(plaintext) + 15) / 16.
</artwork></figure>
<t>
Then AES-GCM requires p + 1 AES operations and p + a + 1 field
multiplications.
</t>
<t>Defined similarly, AES-GCM-SIV with AES-128 requires p + 5 AES operations and p + a + 1 field multiplications. With AES-256, that becomes p + 7 AES operations.</t>
<t>With large machines, the available parallelism becomes far more important, and such simple performance analysis is no longer representative. For such machines, we find that decryption of AES-GCM-SIV is only about 5% slower than AES-GCM, as long as the message is at least a couple of kilobytes. Encryption tends to run about two-thirds the speed because of the additional pass required.</t>
</section>
<section title="Test Vectors">
<section title="AEAD_AES_128_GCM_SIV">
<figure align="center">
<artwork align="left"><![CDATA[
Plaintext (0 bytes) =
AAD (0 bytes) =
Key = 01000000000000000000000000000000
Nonce = 030000000000000000000000
Record authentication key = d9b360279694941ac5dbc6987ada7377
Record encryption key = 4004a0dcd862f2a57360219d2d44ef6c
POLYVAL input = 00000000000000000000000000000000
POLYVAL result = 00000000000000000000000000000000
POLYVAL result XOR nonce = 03000000000000000000000000000000
... and masked = 03000000000000000000000000000000
Tag = dc20e2d83f25705bb49e439eca56de25
Initial counter = dc20e2d83f25705bb49e439eca56dea5
Result (16 bytes) = dc20e2d83f25705bb49e439eca56de25
Plaintext (8 bytes) = 0100000000000000
AAD (0 bytes) =
Key = 01000000000000000000000000000000
Nonce = 030000000000000000000000
Record authentication key = d9b360279694941ac5dbc6987ada7377
Record encryption key = 4004a0dcd862f2a57360219d2d44ef6c
POLYVAL input = 01000000000000000000000000000000
00000000000000004000000000000000
POLYVAL result = eb93b7740962c5e49d2a90a7dc5cec74
POLYVAL result XOR nonce = e893b7740962c5e49d2a90a7dc5cec74
... and masked = e893b7740962c5e49d2a90a7dc5cec74
Tag = 578782fff6013b815b287c22493a364c
Initial counter = 578782fff6013b815b287c22493a36cc
Result (24 bytes) = b5d839330ac7b786578782fff6013b81
5b287c22493a364c
Plaintext (12 bytes) = 010000000000000000000000
AAD (0 bytes) =
Key = 01000000000000000000000000000000
Nonce = 030000000000000000000000
Record authentication key = d9b360279694941ac5dbc6987ada7377
Record encryption key = 4004a0dcd862f2a57360219d2d44ef6c
POLYVAL input = 01000000000000000000000000000000
00000000000000006000000000000000
POLYVAL result = 48eb6c6c5a2dbe4a1dde508fee06361b
POLYVAL result XOR nonce = 4beb6c6c5a2dbe4a1dde508fee06361b
... and masked = 4beb6c6c5a2dbe4a1dde508fee06361b
Tag = a4978db357391a0bc4fdec8b0d106639
Initial counter = a4978db357391a0bc4fdec8b0d1066b9
Result (28 bytes) = 7323ea61d05932260047d942a4978db3
57391a0bc4fdec8b0d106639
Plaintext (16 bytes) = 01000000000000000000000000000000
AAD (0 bytes) =
Key = 01000000000000000000000000000000
Nonce = 030000000000000000000000
Record authentication key = d9b360279694941ac5dbc6987ada7377
Record encryption key = 4004a0dcd862f2a57360219d2d44ef6c
POLYVAL input = 01000000000000000000000000000000
00000000000000008000000000000000
POLYVAL result = 20806c26e3c1de019e111255708031d6
POLYVAL result XOR nonce = 23806c26e3c1de019e111255708031d6
... and masked = 23806c26e3c1de019e11125570803156
Tag = 303aaf90f6fe21199c6068577437a0c4
Initial counter = 303aaf90f6fe21199c6068577437a0c4
Result (32 bytes) = 743f7c8077ab25f8624e2e948579cf77
303aaf90f6fe21199c6068577437a0c4
Plaintext (32 bytes) = 01000000000000000000000000000000
02000000000000000000000000000000
AAD (0 bytes) =
Key = 01000000000000000000000000000000
Nonce = 030000000000000000000000
Record authentication key = d9b360279694941ac5dbc6987ada7377
Record encryption key = 4004a0dcd862f2a57360219d2d44ef6c
POLYVAL input = 01000000000000000000000000000000
02000000000000000000000000000000
00000000000000000001000000000000
POLYVAL result = ce6edc9a50b36d9a98986bbf6a261c3b
POLYVAL result XOR nonce = cd6edc9a50b36d9a98986bbf6a261c3b
... and masked = cd6edc9a50b36d9a98986bbf6a261c3b
Tag = 1a8e45dcd4578c667cd86847bf6155ff
Initial counter = 1a8e45dcd4578c667cd86847bf6155ff
Result (48 bytes) = 84e07e62ba83a6585417245d7ec413a9
fe427d6315c09b57ce45f2e3936a9445
1a8e45dcd4578c667cd86847bf6155ff
Plaintext (48 bytes) = 01000000000000000000000000000000
02000000000000000000000000000000
03000000000000000000000000000000
AAD (0 bytes) =
Key = 01000000000000000000000000000000
Nonce = 030000000000000000000000
Record authentication key = d9b360279694941ac5dbc6987ada7377
Record encryption key = 4004a0dcd862f2a57360219d2d44ef6c
POLYVAL input = 01000000000000000000000000000000
02000000000000000000000000000000
03000000000000000000000000000000
00000000000000008001000000000000
POLYVAL result = 81388746bc22d26b2abc3dcb15754222
POLYVAL result XOR nonce = 82388746bc22d26b2abc3dcb15754222