Re: aes/gcm maximum plaintext size; handling of large files

------=_Part_644974_1808595464.1755078258329
Content-Type: multipart/alternative; 
	boundary="----=_Part_644975_1607503638.1755078258329"

------=_Part_644975_1607503638.1755078258329
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi. I think it kind of depends on your use case. Personally I would look to=
=20
block the data up into manageable blocks of a certain size, fixed or=20
variable length. There are advantages to this: specifically that you can=20
random access data on a block basis, decrypt and verify as opposed to=20
having to decypt the whole lot in one go just to read a subsection of data.=
=20

Obviously you will need to either create some header on variable length=20
blocks or add padding to the last block if using fixed length blocks=20

Regarding the IV. You will need to differentiate for each block. You could=
=20
generate a =E2=80=98base iv=E2=80=99 for the file and add a block counter i=
n the low order=20
bits of the IV relating to the block number (0-n). This way you only need=
=20
to store one base IV for the file then calculate the counter for the block=
=20
being read. You also know that each IV for each block is unique (assuming=
=20
you have enough bits allocated to your counter field in the IV)



On Tuesday, 12 August 2025 at 22:07:13 UTC+1 Lana Deere wrote:

> On Tuesday, August 12, 2025 at 8:10:03=E2=80=AFAM UTC-4 Jeffrey Walton wr=
ote:
>
> GCM plaintext maximum length is specified in bits, not bytes. See=20
> SP800-39D, Section 5.2.1.1 Input Data, p. 8, <
> https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d=
.pdf>.=20
> That leads to:
>
>     2^39 - 256 =3D 549755813632
>     549755813632 / 8 =3D 68719476704
>
>
> Is there a standard practice for handling AES encryption of large files? =
=20
> E.g., create a new IV and resume encryption?  Use something other than GC=
M=20
> which has a higher limit?
>
> Thanks!
> =20
>

--=20
You received this message because you are subscribed to the Google Groups "=
Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/cryptopp-us=
ers/fddfc356-b2ba-4116-b696-b85edb819ee5n%40googlegroups.com.

------=_Part_644975_1607503638.1755078258329
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi.  I think it kind of depends on your use case.  Personally I would look =
to block the  data up into manageable blocks of a certain size, fixed or va=
riable length.  There are advantages to this: specifically that you can ran=
dom access data on a block basis, decrypt and verify as opposed to having t=
o decypt the whole lot in one go just to read a subsection of data.=C2=A0<d=
iv><br /></div><div>Obviously you will need to either create some header on=
 variable length blocks or add padding to the last block if using fixed len=
gth blocks=C2=A0</div><div><br /></div><div>Regarding the IV.  You will nee=
d to differentiate for each block.  You could generate a =E2=80=98base iv=
=E2=80=99 for the file and add a block counter in the low order bits of the=
 IV relating to the block number (0-n).  This way you only need to store on=
e base IV for the file then calculate the counter for the block being read.=
  You also know that each IV for each block is unique (assuming you have en=
ough bits allocated to your counter field in the IV)</div><div><br /></div>=
<div><br /><br /></div><div class=3D"gmail_quote"><div dir=3D"auto" class=
=3D"gmail_attr">On Tuesday, 12 August 2025 at 22:07:13 UTC+1 Lana Deere wro=
te:<br/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8e=
x; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div=
 dir=3D"auto">On Tuesday, August 12, 2025 at 8:10:03=E2=80=AFAM UTC-4 Jeffr=
ey Walton wrote:<br></div><blockquote style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div=
><div>GCM plaintext maximum length is specified in bits, not bytes. See SP8=
00-39D, Section 5.2.1.1 Input Data, p. 8, &lt;<a href=3D"https://nvlpubs.ni=
st.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf" rel=3D"nofollo=
w" target=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=
=3Den-GB&amp;q=3Dhttps://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpub=
lication800-38d.pdf&amp;source=3Dgmail&amp;ust=3D1755163783074000&amp;usg=
=3DAOvVaw1h2En7OdOWAjMLxSM3cNLz">https://nvlpubs.nist.gov/nistpubs/Legacy/S=
P/nistspecialpublication800-38d.pdf</a>&gt;. That leads to:</div><div><br><=
/div><div>=C2=A0 =C2=A0 2^39 - 256 =3D=C2=A0<span>549755813632</span></div>=
<div><span>=C2=A0 =C2=A0 549755813632 / 8 =3D=C2=A0</span><span>68719476704=
</span></div></div></div></blockquote><div><br></div></div><div><div>Is the=
re a standard practice for handling AES encryption of large files?=C2=A0 E.=
g., create a new IV and resume encryption?=C2=A0 Use something other than G=
CM which has a higher limit?</div><div><br></div><div>Thanks!</div><div>=C2=
=A0</div></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Crypto++ Users&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:[email protected]">cryp=
[email protected]</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
cryptopp-users/fddfc356-b2ba-4116-b696-b85edb819ee5n%40googlegroups.com?utm=
_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/cryp=
topp-users/fddfc356-b2ba-4116-b696-b85edb819ee5n%40googlegroups.com</a>.<br=
 />

------=_Part_644975_1607503638.1755078258329--

------=_Part_644974_1808595464.1755078258329--