AES256 GCM IV guidelines

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












2












$begingroup$


If I use for example AES256 (GCM), and my message is bigger than 256bit (breaked into smaller 256bit blocks for encryption), should the IV change every 256bit of the message?










share|improve this question











$endgroup$











  • $begingroup$
    You can write comments under your question. A session, starting from setting the IV and the key until the max possible counter is reached. Did you looked at the links? IV repeat is insecure across sessions.
    $endgroup$
    – kelalaka
    Jan 28 at 8:19










  • $begingroup$
    To answer the other subquestion you have, "session" means plaintext that is encrypted and gets a ciphertext plus authentication tag, regardless of the length of the message, as long as it is within the limit defined by the mode
    $endgroup$
    – Richie Frame
    Jan 28 at 10:23











  • $begingroup$
    Besides that, GCM itself doesn't really know about sessions. The NIST version of the GCM spec does contain the word "session" but only in reference to a higher level protocol (w.r.t. key reuse). For this reason I don't think it is very useful to ask about sessions in a separate question, unless you can point out the protocol that you're targeting. GCM just deals with variable length messages. P.S. You deleted your question wrapped in an answer a second before I could post a comment with this content :| Thanks for deleting it regardless :)
    $endgroup$
    – Maarten Bodewes
    Jan 29 at 2:43
















2












$begingroup$


If I use for example AES256 (GCM), and my message is bigger than 256bit (breaked into smaller 256bit blocks for encryption), should the IV change every 256bit of the message?










share|improve this question











$endgroup$











  • $begingroup$
    You can write comments under your question. A session, starting from setting the IV and the key until the max possible counter is reached. Did you looked at the links? IV repeat is insecure across sessions.
    $endgroup$
    – kelalaka
    Jan 28 at 8:19










  • $begingroup$
    To answer the other subquestion you have, "session" means plaintext that is encrypted and gets a ciphertext plus authentication tag, regardless of the length of the message, as long as it is within the limit defined by the mode
    $endgroup$
    – Richie Frame
    Jan 28 at 10:23











  • $begingroup$
    Besides that, GCM itself doesn't really know about sessions. The NIST version of the GCM spec does contain the word "session" but only in reference to a higher level protocol (w.r.t. key reuse). For this reason I don't think it is very useful to ask about sessions in a separate question, unless you can point out the protocol that you're targeting. GCM just deals with variable length messages. P.S. You deleted your question wrapped in an answer a second before I could post a comment with this content :| Thanks for deleting it regardless :)
    $endgroup$
    – Maarten Bodewes
    Jan 29 at 2:43














2












2








2





$begingroup$


If I use for example AES256 (GCM), and my message is bigger than 256bit (breaked into smaller 256bit blocks for encryption), should the IV change every 256bit of the message?










share|improve this question











$endgroup$




If I use for example AES256 (GCM), and my message is bigger than 256bit (breaked into smaller 256bit blocks for encryption), should the IV change every 256bit of the message?







aes initialization-vector gcm






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 28 at 7:33









kelalaka

7,74522248




7,74522248










asked Jan 28 at 7:03









OffirOffir

211




211











  • $begingroup$
    You can write comments under your question. A session, starting from setting the IV and the key until the max possible counter is reached. Did you looked at the links? IV repeat is insecure across sessions.
    $endgroup$
    – kelalaka
    Jan 28 at 8:19










  • $begingroup$
    To answer the other subquestion you have, "session" means plaintext that is encrypted and gets a ciphertext plus authentication tag, regardless of the length of the message, as long as it is within the limit defined by the mode
    $endgroup$
    – Richie Frame
    Jan 28 at 10:23











  • $begingroup$
    Besides that, GCM itself doesn't really know about sessions. The NIST version of the GCM spec does contain the word "session" but only in reference to a higher level protocol (w.r.t. key reuse). For this reason I don't think it is very useful to ask about sessions in a separate question, unless you can point out the protocol that you're targeting. GCM just deals with variable length messages. P.S. You deleted your question wrapped in an answer a second before I could post a comment with this content :| Thanks for deleting it regardless :)
    $endgroup$
    – Maarten Bodewes
    Jan 29 at 2:43

















  • $begingroup$
    You can write comments under your question. A session, starting from setting the IV and the key until the max possible counter is reached. Did you looked at the links? IV repeat is insecure across sessions.
    $endgroup$
    – kelalaka
    Jan 28 at 8:19










  • $begingroup$
    To answer the other subquestion you have, "session" means plaintext that is encrypted and gets a ciphertext plus authentication tag, regardless of the length of the message, as long as it is within the limit defined by the mode
    $endgroup$
    – Richie Frame
    Jan 28 at 10:23











  • $begingroup$
    Besides that, GCM itself doesn't really know about sessions. The NIST version of the GCM spec does contain the word "session" but only in reference to a higher level protocol (w.r.t. key reuse). For this reason I don't think it is very useful to ask about sessions in a separate question, unless you can point out the protocol that you're targeting. GCM just deals with variable length messages. P.S. You deleted your question wrapped in an answer a second before I could post a comment with this content :| Thanks for deleting it regardless :)
    $endgroup$
    – Maarten Bodewes
    Jan 29 at 2:43
















$begingroup$
You can write comments under your question. A session, starting from setting the IV and the key until the max possible counter is reached. Did you looked at the links? IV repeat is insecure across sessions.
$endgroup$
– kelalaka
Jan 28 at 8:19




$begingroup$
You can write comments under your question. A session, starting from setting the IV and the key until the max possible counter is reached. Did you looked at the links? IV repeat is insecure across sessions.
$endgroup$
– kelalaka
Jan 28 at 8:19












$begingroup$
To answer the other subquestion you have, "session" means plaintext that is encrypted and gets a ciphertext plus authentication tag, regardless of the length of the message, as long as it is within the limit defined by the mode
$endgroup$
– Richie Frame
Jan 28 at 10:23





$begingroup$
To answer the other subquestion you have, "session" means plaintext that is encrypted and gets a ciphertext plus authentication tag, regardless of the length of the message, as long as it is within the limit defined by the mode
$endgroup$
– Richie Frame
Jan 28 at 10:23













$begingroup$
Besides that, GCM itself doesn't really know about sessions. The NIST version of the GCM spec does contain the word "session" but only in reference to a higher level protocol (w.r.t. key reuse). For this reason I don't think it is very useful to ask about sessions in a separate question, unless you can point out the protocol that you're targeting. GCM just deals with variable length messages. P.S. You deleted your question wrapped in an answer a second before I could post a comment with this content :| Thanks for deleting it regardless :)
$endgroup$
– Maarten Bodewes
Jan 29 at 2:43





$begingroup$
Besides that, GCM itself doesn't really know about sessions. The NIST version of the GCM spec does contain the word "session" but only in reference to a higher level protocol (w.r.t. key reuse). For this reason I don't think it is very useful to ask about sessions in a separate question, unless you can point out the protocol that you're targeting. GCM just deals with variable length messages. P.S. You deleted your question wrapped in an answer a second before I could post a comment with this content :| Thanks for deleting it regardless :)
$endgroup$
– Maarten Bodewes
Jan 29 at 2:43











2 Answers
2






active

oldest

votes


















2












$begingroup$

The IV for GCM mode, in this case the thing we call the Nonce, is different from the IV used for the CTR mode inside of GCM.



Additionally as per the wording of your question, AES256 has a 256-bit key and a 128-bit block, not a 256-bit block, and encrypts plaintext in 128-bit increments.



For GCM, you MUST use a unique Nonce for every message. Inside GCM, the Nonce is turned into the CTR IV. If you look at kelalaka's answer, if the Nonce is 96-bits, the CTR IV is the exact same thing. If it is some other size, it converts it to a 96-bit IV using the referenced algorithm. CTR mode uses the IV plus a counter starting at 1 to generate the stream. The 96-bit IV plus the 32-bit counter equal the 128-bit input block to the cipher.



([ IV ][ctr1]) -----> [AES] -----> ([ STREAM1 ])


The output 128-bit stream block is used to encrypt the plaintext blocks. If there are multiple blocks of plaintext, only one can be encrypted with a given counter, so it is incremented by 1, and the same operation is repeated to generate the next 128-bit stream block. If the final plaintext block is shorter than 128-bits, the unused stream bits are discarded.



MESSAGE = ([ PLAINTEXT1 ][ PLAINTEXT2 ][ PLAINTEXT3 ])
AUTHDAT = additional data to authenticate
LEN_T = desired length of authentication tag
L = length_64(AUTHDAT) || length_64(MESSAGE)
NONCE = 96-bits, therefore IV=NONCE
H = AES_K(0x00000000000000000000000000000000)
ctr0 = 0x00000001, ctr1 = 0x00000002, and so on

([ IV ][ctr0]) -----> [AES] -----> ([ STREAM0 ])

([ IV ][ctr1]) -----> [AES] -----> ([ STREAM1 ])
([ IV ][ctr2]) -----> [AES] -----> ([ STREAM2 ])
([ IV ][ctr3]) -----> [AES] -----> ([ STREAM3 ])

([ PLAINTEXT1 ]) XOR ([ STREAM1 ]) = ([ CIPHERTXT1 ])
([ PLAINTEXT2 ]) XOR ([ STREAM2 ]) = ([ CIPHERTXT2 ])
([ PLAINTEXT3 ]) XOR ([ STREAM3 ]) = ([ CIPHERTXT3 ])

CIPHERTEXT= ([ CIPHERTXT1 ][ CIPHERTXT2 ][ CIPHERTXT3 ])

H = GHASH(H,AUTHDAT,CIPHERTEXT,L)
TAG = truncate_LEN_T( H XOR STREAM0 )


As many blocks are generated as required to encrypt all the plaintext, as long as the limit of GCM is not reached, which is 549,755,813,632 bits, or 256 bits less than 64GiB, as explained here.






share|improve this answer











$endgroup$








  • 1




    $begingroup$
    The counter starts at 2 for confidentiality. See the comments of Richie below as for the why.
    $endgroup$
    – Maarten Bodewes
    Jan 28 at 12:04







  • 1




    $begingroup$
    @MaartenBodewes I am pretty sure a 128-bit 0 block is used to generate H, but you are right, the counter for encryption of the plaintext starts at 2, the first counter value is used to encrypt the authentication tag after the final multiplication
    $endgroup$
    – Richie Frame
    Jan 29 at 0:18






  • 1




    $begingroup$
    I should mention the reason they do not use 0 at all in the counter, is because if your nonce is all 0, the first counter would be identical to H
    $endgroup$
    – Richie Frame
    Jan 29 at 3:30


















1












$begingroup$

AES-GCM uses the Counter (CTR) mode for AES. If you use an SP 800-38D compatible library, actually, it handles the incrementing the IV for you.



For an encryption session, once the IV is initialized the counter part (32-bit part) of the IV is incremented for the encryption of every block. The IV fot CTR mode start from 2 as mentioned Maarten's comment. Thus, encryption can be continued until the counter is reached to the maximum, that is $2^32-2$ AES blocks if 32-bit counter is used. Then, you have to use a new IV to continue.



The real problem is generating the IV's uniquely per session. If IV ever repeats then it is insecure so you need to make sure that the IV never repeats.



For the generation of the IV, you can use a good random source, or you can use the IV incrementally. In this case, the IV size must be 96-bit, see page 15 of SP 800-38D.




If $len(IV)=96$, then let $J_0 = IV | 0^31 |1$.




Storing the last used IV and incrementing it then providing to GCM is the general practice to mitigate from a birthday attack.



If the supplied IV is not 96-bits it is processed by $operatornameGHASH$. You can see how it is processed in this answer Generate J0 for GCM cipher when $len(IV)neq96$ bits in details.






share|improve this answer











$endgroup$












  • $begingroup$
    i understand. but what does it mean unique per session? what is the definition of session?
    $endgroup$
    – Offir
    Jan 28 at 8:09






  • 1




    $begingroup$
    Note that the counter value 1 is used for GMAC, also see my comment below Richie Frame's answer. That's why you can encrypt 256 bits less than for just CTR mode ($2^32 - 2$ blocks of 128 bits, in other words).
    $endgroup$
    – Maarten Bodewes
    Jan 28 at 12:07











  • $begingroup$
    @MaartenBodewes Yes, it starts from 1. Thanks for the reminder.
    $endgroup$
    – kelalaka
    Jan 28 at 12:08











  • $begingroup$
    For the confidentiality part it starts at two.
    $endgroup$
    – Maarten Bodewes
    Jan 29 at 1:04











Your Answer





StackExchange.ifUsing("editor", function ()
return StackExchange.using("mathjaxEditing", function ()
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
);
);
, "mathjax-editing");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "281"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f66837%2faes256-gcm-iv-guidelines%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









2












$begingroup$

The IV for GCM mode, in this case the thing we call the Nonce, is different from the IV used for the CTR mode inside of GCM.



Additionally as per the wording of your question, AES256 has a 256-bit key and a 128-bit block, not a 256-bit block, and encrypts plaintext in 128-bit increments.



For GCM, you MUST use a unique Nonce for every message. Inside GCM, the Nonce is turned into the CTR IV. If you look at kelalaka's answer, if the Nonce is 96-bits, the CTR IV is the exact same thing. If it is some other size, it converts it to a 96-bit IV using the referenced algorithm. CTR mode uses the IV plus a counter starting at 1 to generate the stream. The 96-bit IV plus the 32-bit counter equal the 128-bit input block to the cipher.



([ IV ][ctr1]) -----> [AES] -----> ([ STREAM1 ])


The output 128-bit stream block is used to encrypt the plaintext blocks. If there are multiple blocks of plaintext, only one can be encrypted with a given counter, so it is incremented by 1, and the same operation is repeated to generate the next 128-bit stream block. If the final plaintext block is shorter than 128-bits, the unused stream bits are discarded.



MESSAGE = ([ PLAINTEXT1 ][ PLAINTEXT2 ][ PLAINTEXT3 ])
AUTHDAT = additional data to authenticate
LEN_T = desired length of authentication tag
L = length_64(AUTHDAT) || length_64(MESSAGE)
NONCE = 96-bits, therefore IV=NONCE
H = AES_K(0x00000000000000000000000000000000)
ctr0 = 0x00000001, ctr1 = 0x00000002, and so on

([ IV ][ctr0]) -----> [AES] -----> ([ STREAM0 ])

([ IV ][ctr1]) -----> [AES] -----> ([ STREAM1 ])
([ IV ][ctr2]) -----> [AES] -----> ([ STREAM2 ])
([ IV ][ctr3]) -----> [AES] -----> ([ STREAM3 ])

([ PLAINTEXT1 ]) XOR ([ STREAM1 ]) = ([ CIPHERTXT1 ])
([ PLAINTEXT2 ]) XOR ([ STREAM2 ]) = ([ CIPHERTXT2 ])
([ PLAINTEXT3 ]) XOR ([ STREAM3 ]) = ([ CIPHERTXT3 ])

CIPHERTEXT= ([ CIPHERTXT1 ][ CIPHERTXT2 ][ CIPHERTXT3 ])

H = GHASH(H,AUTHDAT,CIPHERTEXT,L)
TAG = truncate_LEN_T( H XOR STREAM0 )


As many blocks are generated as required to encrypt all the plaintext, as long as the limit of GCM is not reached, which is 549,755,813,632 bits, or 256 bits less than 64GiB, as explained here.






share|improve this answer











$endgroup$








  • 1




    $begingroup$
    The counter starts at 2 for confidentiality. See the comments of Richie below as for the why.
    $endgroup$
    – Maarten Bodewes
    Jan 28 at 12:04







  • 1




    $begingroup$
    @MaartenBodewes I am pretty sure a 128-bit 0 block is used to generate H, but you are right, the counter for encryption of the plaintext starts at 2, the first counter value is used to encrypt the authentication tag after the final multiplication
    $endgroup$
    – Richie Frame
    Jan 29 at 0:18






  • 1




    $begingroup$
    I should mention the reason they do not use 0 at all in the counter, is because if your nonce is all 0, the first counter would be identical to H
    $endgroup$
    – Richie Frame
    Jan 29 at 3:30















2












$begingroup$

The IV for GCM mode, in this case the thing we call the Nonce, is different from the IV used for the CTR mode inside of GCM.



Additionally as per the wording of your question, AES256 has a 256-bit key and a 128-bit block, not a 256-bit block, and encrypts plaintext in 128-bit increments.



For GCM, you MUST use a unique Nonce for every message. Inside GCM, the Nonce is turned into the CTR IV. If you look at kelalaka's answer, if the Nonce is 96-bits, the CTR IV is the exact same thing. If it is some other size, it converts it to a 96-bit IV using the referenced algorithm. CTR mode uses the IV plus a counter starting at 1 to generate the stream. The 96-bit IV plus the 32-bit counter equal the 128-bit input block to the cipher.



([ IV ][ctr1]) -----> [AES] -----> ([ STREAM1 ])


The output 128-bit stream block is used to encrypt the plaintext blocks. If there are multiple blocks of plaintext, only one can be encrypted with a given counter, so it is incremented by 1, and the same operation is repeated to generate the next 128-bit stream block. If the final plaintext block is shorter than 128-bits, the unused stream bits are discarded.



MESSAGE = ([ PLAINTEXT1 ][ PLAINTEXT2 ][ PLAINTEXT3 ])
AUTHDAT = additional data to authenticate
LEN_T = desired length of authentication tag
L = length_64(AUTHDAT) || length_64(MESSAGE)
NONCE = 96-bits, therefore IV=NONCE
H = AES_K(0x00000000000000000000000000000000)
ctr0 = 0x00000001, ctr1 = 0x00000002, and so on

([ IV ][ctr0]) -----> [AES] -----> ([ STREAM0 ])

([ IV ][ctr1]) -----> [AES] -----> ([ STREAM1 ])
([ IV ][ctr2]) -----> [AES] -----> ([ STREAM2 ])
([ IV ][ctr3]) -----> [AES] -----> ([ STREAM3 ])

([ PLAINTEXT1 ]) XOR ([ STREAM1 ]) = ([ CIPHERTXT1 ])
([ PLAINTEXT2 ]) XOR ([ STREAM2 ]) = ([ CIPHERTXT2 ])
([ PLAINTEXT3 ]) XOR ([ STREAM3 ]) = ([ CIPHERTXT3 ])

CIPHERTEXT= ([ CIPHERTXT1 ][ CIPHERTXT2 ][ CIPHERTXT3 ])

H = GHASH(H,AUTHDAT,CIPHERTEXT,L)
TAG = truncate_LEN_T( H XOR STREAM0 )


As many blocks are generated as required to encrypt all the plaintext, as long as the limit of GCM is not reached, which is 549,755,813,632 bits, or 256 bits less than 64GiB, as explained here.






share|improve this answer











$endgroup$








  • 1




    $begingroup$
    The counter starts at 2 for confidentiality. See the comments of Richie below as for the why.
    $endgroup$
    – Maarten Bodewes
    Jan 28 at 12:04







  • 1




    $begingroup$
    @MaartenBodewes I am pretty sure a 128-bit 0 block is used to generate H, but you are right, the counter for encryption of the plaintext starts at 2, the first counter value is used to encrypt the authentication tag after the final multiplication
    $endgroup$
    – Richie Frame
    Jan 29 at 0:18






  • 1




    $begingroup$
    I should mention the reason they do not use 0 at all in the counter, is because if your nonce is all 0, the first counter would be identical to H
    $endgroup$
    – Richie Frame
    Jan 29 at 3:30













2












2








2





$begingroup$

The IV for GCM mode, in this case the thing we call the Nonce, is different from the IV used for the CTR mode inside of GCM.



Additionally as per the wording of your question, AES256 has a 256-bit key and a 128-bit block, not a 256-bit block, and encrypts plaintext in 128-bit increments.



For GCM, you MUST use a unique Nonce for every message. Inside GCM, the Nonce is turned into the CTR IV. If you look at kelalaka's answer, if the Nonce is 96-bits, the CTR IV is the exact same thing. If it is some other size, it converts it to a 96-bit IV using the referenced algorithm. CTR mode uses the IV plus a counter starting at 1 to generate the stream. The 96-bit IV plus the 32-bit counter equal the 128-bit input block to the cipher.



([ IV ][ctr1]) -----> [AES] -----> ([ STREAM1 ])


The output 128-bit stream block is used to encrypt the plaintext blocks. If there are multiple blocks of plaintext, only one can be encrypted with a given counter, so it is incremented by 1, and the same operation is repeated to generate the next 128-bit stream block. If the final plaintext block is shorter than 128-bits, the unused stream bits are discarded.



MESSAGE = ([ PLAINTEXT1 ][ PLAINTEXT2 ][ PLAINTEXT3 ])
AUTHDAT = additional data to authenticate
LEN_T = desired length of authentication tag
L = length_64(AUTHDAT) || length_64(MESSAGE)
NONCE = 96-bits, therefore IV=NONCE
H = AES_K(0x00000000000000000000000000000000)
ctr0 = 0x00000001, ctr1 = 0x00000002, and so on

([ IV ][ctr0]) -----> [AES] -----> ([ STREAM0 ])

([ IV ][ctr1]) -----> [AES] -----> ([ STREAM1 ])
([ IV ][ctr2]) -----> [AES] -----> ([ STREAM2 ])
([ IV ][ctr3]) -----> [AES] -----> ([ STREAM3 ])

([ PLAINTEXT1 ]) XOR ([ STREAM1 ]) = ([ CIPHERTXT1 ])
([ PLAINTEXT2 ]) XOR ([ STREAM2 ]) = ([ CIPHERTXT2 ])
([ PLAINTEXT3 ]) XOR ([ STREAM3 ]) = ([ CIPHERTXT3 ])

CIPHERTEXT= ([ CIPHERTXT1 ][ CIPHERTXT2 ][ CIPHERTXT3 ])

H = GHASH(H,AUTHDAT,CIPHERTEXT,L)
TAG = truncate_LEN_T( H XOR STREAM0 )


As many blocks are generated as required to encrypt all the plaintext, as long as the limit of GCM is not reached, which is 549,755,813,632 bits, or 256 bits less than 64GiB, as explained here.






share|improve this answer











$endgroup$



The IV for GCM mode, in this case the thing we call the Nonce, is different from the IV used for the CTR mode inside of GCM.



Additionally as per the wording of your question, AES256 has a 256-bit key and a 128-bit block, not a 256-bit block, and encrypts plaintext in 128-bit increments.



For GCM, you MUST use a unique Nonce for every message. Inside GCM, the Nonce is turned into the CTR IV. If you look at kelalaka's answer, if the Nonce is 96-bits, the CTR IV is the exact same thing. If it is some other size, it converts it to a 96-bit IV using the referenced algorithm. CTR mode uses the IV plus a counter starting at 1 to generate the stream. The 96-bit IV plus the 32-bit counter equal the 128-bit input block to the cipher.



([ IV ][ctr1]) -----> [AES] -----> ([ STREAM1 ])


The output 128-bit stream block is used to encrypt the plaintext blocks. If there are multiple blocks of plaintext, only one can be encrypted with a given counter, so it is incremented by 1, and the same operation is repeated to generate the next 128-bit stream block. If the final plaintext block is shorter than 128-bits, the unused stream bits are discarded.



MESSAGE = ([ PLAINTEXT1 ][ PLAINTEXT2 ][ PLAINTEXT3 ])
AUTHDAT = additional data to authenticate
LEN_T = desired length of authentication tag
L = length_64(AUTHDAT) || length_64(MESSAGE)
NONCE = 96-bits, therefore IV=NONCE
H = AES_K(0x00000000000000000000000000000000)
ctr0 = 0x00000001, ctr1 = 0x00000002, and so on

([ IV ][ctr0]) -----> [AES] -----> ([ STREAM0 ])

([ IV ][ctr1]) -----> [AES] -----> ([ STREAM1 ])
([ IV ][ctr2]) -----> [AES] -----> ([ STREAM2 ])
([ IV ][ctr3]) -----> [AES] -----> ([ STREAM3 ])

([ PLAINTEXT1 ]) XOR ([ STREAM1 ]) = ([ CIPHERTXT1 ])
([ PLAINTEXT2 ]) XOR ([ STREAM2 ]) = ([ CIPHERTXT2 ])
([ PLAINTEXT3 ]) XOR ([ STREAM3 ]) = ([ CIPHERTXT3 ])

CIPHERTEXT= ([ CIPHERTXT1 ][ CIPHERTXT2 ][ CIPHERTXT3 ])

H = GHASH(H,AUTHDAT,CIPHERTEXT,L)
TAG = truncate_LEN_T( H XOR STREAM0 )


As many blocks are generated as required to encrypt all the plaintext, as long as the limit of GCM is not reached, which is 549,755,813,632 bits, or 256 bits less than 64GiB, as explained here.







share|improve this answer














share|improve this answer



share|improve this answer








edited Jan 29 at 0:41

























answered Jan 28 at 11:00









Richie FrameRichie Frame

9,99711530




9,99711530







  • 1




    $begingroup$
    The counter starts at 2 for confidentiality. See the comments of Richie below as for the why.
    $endgroup$
    – Maarten Bodewes
    Jan 28 at 12:04







  • 1




    $begingroup$
    @MaartenBodewes I am pretty sure a 128-bit 0 block is used to generate H, but you are right, the counter for encryption of the plaintext starts at 2, the first counter value is used to encrypt the authentication tag after the final multiplication
    $endgroup$
    – Richie Frame
    Jan 29 at 0:18






  • 1




    $begingroup$
    I should mention the reason they do not use 0 at all in the counter, is because if your nonce is all 0, the first counter would be identical to H
    $endgroup$
    – Richie Frame
    Jan 29 at 3:30












  • 1




    $begingroup$
    The counter starts at 2 for confidentiality. See the comments of Richie below as for the why.
    $endgroup$
    – Maarten Bodewes
    Jan 28 at 12:04







  • 1




    $begingroup$
    @MaartenBodewes I am pretty sure a 128-bit 0 block is used to generate H, but you are right, the counter for encryption of the plaintext starts at 2, the first counter value is used to encrypt the authentication tag after the final multiplication
    $endgroup$
    – Richie Frame
    Jan 29 at 0:18






  • 1




    $begingroup$
    I should mention the reason they do not use 0 at all in the counter, is because if your nonce is all 0, the first counter would be identical to H
    $endgroup$
    – Richie Frame
    Jan 29 at 3:30







1




1




$begingroup$
The counter starts at 2 for confidentiality. See the comments of Richie below as for the why.
$endgroup$
– Maarten Bodewes
Jan 28 at 12:04





$begingroup$
The counter starts at 2 for confidentiality. See the comments of Richie below as for the why.
$endgroup$
– Maarten Bodewes
Jan 28 at 12:04





1




1




$begingroup$
@MaartenBodewes I am pretty sure a 128-bit 0 block is used to generate H, but you are right, the counter for encryption of the plaintext starts at 2, the first counter value is used to encrypt the authentication tag after the final multiplication
$endgroup$
– Richie Frame
Jan 29 at 0:18




$begingroup$
@MaartenBodewes I am pretty sure a 128-bit 0 block is used to generate H, but you are right, the counter for encryption of the plaintext starts at 2, the first counter value is used to encrypt the authentication tag after the final multiplication
$endgroup$
– Richie Frame
Jan 29 at 0:18




1




1




$begingroup$
I should mention the reason they do not use 0 at all in the counter, is because if your nonce is all 0, the first counter would be identical to H
$endgroup$
– Richie Frame
Jan 29 at 3:30




$begingroup$
I should mention the reason they do not use 0 at all in the counter, is because if your nonce is all 0, the first counter would be identical to H
$endgroup$
– Richie Frame
Jan 29 at 3:30











1












$begingroup$

AES-GCM uses the Counter (CTR) mode for AES. If you use an SP 800-38D compatible library, actually, it handles the incrementing the IV for you.



For an encryption session, once the IV is initialized the counter part (32-bit part) of the IV is incremented for the encryption of every block. The IV fot CTR mode start from 2 as mentioned Maarten's comment. Thus, encryption can be continued until the counter is reached to the maximum, that is $2^32-2$ AES blocks if 32-bit counter is used. Then, you have to use a new IV to continue.



The real problem is generating the IV's uniquely per session. If IV ever repeats then it is insecure so you need to make sure that the IV never repeats.



For the generation of the IV, you can use a good random source, or you can use the IV incrementally. In this case, the IV size must be 96-bit, see page 15 of SP 800-38D.




If $len(IV)=96$, then let $J_0 = IV | 0^31 |1$.




Storing the last used IV and incrementing it then providing to GCM is the general practice to mitigate from a birthday attack.



If the supplied IV is not 96-bits it is processed by $operatornameGHASH$. You can see how it is processed in this answer Generate J0 for GCM cipher when $len(IV)neq96$ bits in details.






share|improve this answer











$endgroup$












  • $begingroup$
    i understand. but what does it mean unique per session? what is the definition of session?
    $endgroup$
    – Offir
    Jan 28 at 8:09






  • 1




    $begingroup$
    Note that the counter value 1 is used for GMAC, also see my comment below Richie Frame's answer. That's why you can encrypt 256 bits less than for just CTR mode ($2^32 - 2$ blocks of 128 bits, in other words).
    $endgroup$
    – Maarten Bodewes
    Jan 28 at 12:07











  • $begingroup$
    @MaartenBodewes Yes, it starts from 1. Thanks for the reminder.
    $endgroup$
    – kelalaka
    Jan 28 at 12:08











  • $begingroup$
    For the confidentiality part it starts at two.
    $endgroup$
    – Maarten Bodewes
    Jan 29 at 1:04
















1












$begingroup$

AES-GCM uses the Counter (CTR) mode for AES. If you use an SP 800-38D compatible library, actually, it handles the incrementing the IV for you.



For an encryption session, once the IV is initialized the counter part (32-bit part) of the IV is incremented for the encryption of every block. The IV fot CTR mode start from 2 as mentioned Maarten's comment. Thus, encryption can be continued until the counter is reached to the maximum, that is $2^32-2$ AES blocks if 32-bit counter is used. Then, you have to use a new IV to continue.



The real problem is generating the IV's uniquely per session. If IV ever repeats then it is insecure so you need to make sure that the IV never repeats.



For the generation of the IV, you can use a good random source, or you can use the IV incrementally. In this case, the IV size must be 96-bit, see page 15 of SP 800-38D.




If $len(IV)=96$, then let $J_0 = IV | 0^31 |1$.




Storing the last used IV and incrementing it then providing to GCM is the general practice to mitigate from a birthday attack.



If the supplied IV is not 96-bits it is processed by $operatornameGHASH$. You can see how it is processed in this answer Generate J0 for GCM cipher when $len(IV)neq96$ bits in details.






share|improve this answer











$endgroup$












  • $begingroup$
    i understand. but what does it mean unique per session? what is the definition of session?
    $endgroup$
    – Offir
    Jan 28 at 8:09






  • 1




    $begingroup$
    Note that the counter value 1 is used for GMAC, also see my comment below Richie Frame's answer. That's why you can encrypt 256 bits less than for just CTR mode ($2^32 - 2$ blocks of 128 bits, in other words).
    $endgroup$
    – Maarten Bodewes
    Jan 28 at 12:07











  • $begingroup$
    @MaartenBodewes Yes, it starts from 1. Thanks for the reminder.
    $endgroup$
    – kelalaka
    Jan 28 at 12:08











  • $begingroup$
    For the confidentiality part it starts at two.
    $endgroup$
    – Maarten Bodewes
    Jan 29 at 1:04














1












1








1





$begingroup$

AES-GCM uses the Counter (CTR) mode for AES. If you use an SP 800-38D compatible library, actually, it handles the incrementing the IV for you.



For an encryption session, once the IV is initialized the counter part (32-bit part) of the IV is incremented for the encryption of every block. The IV fot CTR mode start from 2 as mentioned Maarten's comment. Thus, encryption can be continued until the counter is reached to the maximum, that is $2^32-2$ AES blocks if 32-bit counter is used. Then, you have to use a new IV to continue.



The real problem is generating the IV's uniquely per session. If IV ever repeats then it is insecure so you need to make sure that the IV never repeats.



For the generation of the IV, you can use a good random source, or you can use the IV incrementally. In this case, the IV size must be 96-bit, see page 15 of SP 800-38D.




If $len(IV)=96$, then let $J_0 = IV | 0^31 |1$.




Storing the last used IV and incrementing it then providing to GCM is the general practice to mitigate from a birthday attack.



If the supplied IV is not 96-bits it is processed by $operatornameGHASH$. You can see how it is processed in this answer Generate J0 for GCM cipher when $len(IV)neq96$ bits in details.






share|improve this answer











$endgroup$



AES-GCM uses the Counter (CTR) mode for AES. If you use an SP 800-38D compatible library, actually, it handles the incrementing the IV for you.



For an encryption session, once the IV is initialized the counter part (32-bit part) of the IV is incremented for the encryption of every block. The IV fot CTR mode start from 2 as mentioned Maarten's comment. Thus, encryption can be continued until the counter is reached to the maximum, that is $2^32-2$ AES blocks if 32-bit counter is used. Then, you have to use a new IV to continue.



The real problem is generating the IV's uniquely per session. If IV ever repeats then it is insecure so you need to make sure that the IV never repeats.



For the generation of the IV, you can use a good random source, or you can use the IV incrementally. In this case, the IV size must be 96-bit, see page 15 of SP 800-38D.




If $len(IV)=96$, then let $J_0 = IV | 0^31 |1$.




Storing the last used IV and incrementing it then providing to GCM is the general practice to mitigate from a birthday attack.



If the supplied IV is not 96-bits it is processed by $operatornameGHASH$. You can see how it is processed in this answer Generate J0 for GCM cipher when $len(IV)neq96$ bits in details.







share|improve this answer














share|improve this answer



share|improve this answer








edited Jan 28 at 12:14

























answered Jan 28 at 7:45









kelalakakelalaka

7,74522248




7,74522248











  • $begingroup$
    i understand. but what does it mean unique per session? what is the definition of session?
    $endgroup$
    – Offir
    Jan 28 at 8:09






  • 1




    $begingroup$
    Note that the counter value 1 is used for GMAC, also see my comment below Richie Frame's answer. That's why you can encrypt 256 bits less than for just CTR mode ($2^32 - 2$ blocks of 128 bits, in other words).
    $endgroup$
    – Maarten Bodewes
    Jan 28 at 12:07











  • $begingroup$
    @MaartenBodewes Yes, it starts from 1. Thanks for the reminder.
    $endgroup$
    – kelalaka
    Jan 28 at 12:08











  • $begingroup$
    For the confidentiality part it starts at two.
    $endgroup$
    – Maarten Bodewes
    Jan 29 at 1:04

















  • $begingroup$
    i understand. but what does it mean unique per session? what is the definition of session?
    $endgroup$
    – Offir
    Jan 28 at 8:09






  • 1




    $begingroup$
    Note that the counter value 1 is used for GMAC, also see my comment below Richie Frame's answer. That's why you can encrypt 256 bits less than for just CTR mode ($2^32 - 2$ blocks of 128 bits, in other words).
    $endgroup$
    – Maarten Bodewes
    Jan 28 at 12:07











  • $begingroup$
    @MaartenBodewes Yes, it starts from 1. Thanks for the reminder.
    $endgroup$
    – kelalaka
    Jan 28 at 12:08











  • $begingroup$
    For the confidentiality part it starts at two.
    $endgroup$
    – Maarten Bodewes
    Jan 29 at 1:04
















$begingroup$
i understand. but what does it mean unique per session? what is the definition of session?
$endgroup$
– Offir
Jan 28 at 8:09




$begingroup$
i understand. but what does it mean unique per session? what is the definition of session?
$endgroup$
– Offir
Jan 28 at 8:09




1




1




$begingroup$
Note that the counter value 1 is used for GMAC, also see my comment below Richie Frame's answer. That's why you can encrypt 256 bits less than for just CTR mode ($2^32 - 2$ blocks of 128 bits, in other words).
$endgroup$
– Maarten Bodewes
Jan 28 at 12:07





$begingroup$
Note that the counter value 1 is used for GMAC, also see my comment below Richie Frame's answer. That's why you can encrypt 256 bits less than for just CTR mode ($2^32 - 2$ blocks of 128 bits, in other words).
$endgroup$
– Maarten Bodewes
Jan 28 at 12:07













$begingroup$
@MaartenBodewes Yes, it starts from 1. Thanks for the reminder.
$endgroup$
– kelalaka
Jan 28 at 12:08





$begingroup$
@MaartenBodewes Yes, it starts from 1. Thanks for the reminder.
$endgroup$
– kelalaka
Jan 28 at 12:08













$begingroup$
For the confidentiality part it starts at two.
$endgroup$
– Maarten Bodewes
Jan 29 at 1:04





$begingroup$
For the confidentiality part it starts at two.
$endgroup$
– Maarten Bodewes
Jan 29 at 1:04


















draft saved

draft discarded
















































Thanks for contributing an answer to Cryptography Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

Use MathJax to format equations. MathJax reference.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f66837%2faes256-gcm-iv-guidelines%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown






Popular posts from this blog

How to check contact read email or not when send email to Individual?

Displaying single band from multi-band raster using QGIS

How many registers does an x86_64 CPU actually have?