Are there any requirements for the additional data to be used in the GCM block cipher mode? And are there any "classic" used informations worthwile to be used? Can for example a username or the name and surname of a person be suitable to encrypt a message with AES GCM?
$\begingroup$
$\endgroup$
2
-
$\begingroup$ You really should stuff everything into the AAD that you can think of that is relevant to the connection / packet at hand. $\endgroup$– SEJPMDec 6, 2016 at 19:29
-
$\begingroup$ Aren't there any information which are suggested to include or, conversely, that shouldn't be used as additional data? $\endgroup$– M-elmanDec 6, 2016 at 20:17
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
13
There are few requirements for the additional data in the GCM document of NIST.
There are some limitations on the size of the AAD, the maximum is $len(A) ≤ 2^{64}-1$ in bits.
Furthermore the following recommendations about the size apply for 128 bit tags:
Therefore, the total number of blocks of plaintext and AAD that are protected by invocations of the authenticated encryption function during the lifetime of the key should be limited. A reasonable limit for most applications would be $2^{64}$, consistent with the requirement on the number of invocations in Sec. 8.3.
and for shorter authentication tags Appendix C applies further restrictions on the length of ciphertext (or equivalently plaintext) and AAD combined.
Those are all the restrictions that apply according to the NIST document.
I'll however add another restriction: AAD is defined in bytes. Whatever you do, for a successful authentication, the AAD must be encoded to the same bytes. That is: the encoding of the AAD must be a canonical encoding. Obviously if you encode a sequence number in little endian and later in big endian then you're in trouble. Same thing if it is unclear where one field ends and the other starts.
Is there any "classic" used information worthwhile to be used? Can for example a username or the name and surname of a person be suitable to encrypt a message with AES GCM?
NIST again offers a few options:
The controlling system or protocol may protect against such an event by monitoring for any duplication of the IVs that are presented for authenticated decryption. Alternatively, certain identifying information can be incorporated into the AAD. Examples of such information include a sequential message number or a timestamp.
I'd say it's a good idea to include as much identifying data in your AAD as possible. Note that you do not have to send the AAD data as long as you can produce it at the sender and the receiver. At least you should be able to prevent replay attacks and to distinguish between sender and receiver. If you cannot do this using the key/IV combination then you'd have to use the AAD (or plaintext) for that.
So yes, name and surname are a good idea as they identify the sender. Beware that names are however often not unique (hence UUID's etc.), something you'd sorely want in an identification scheme.
One thing you do not have to include is the IV, the IV is authenticated by default. And in case you're a greenhorn in cryptography, including the key is a bad idea as well.
answered Dec 6, 2016 at 20:25
-
$\begingroup$ "Including the key is a bad idea as well." - is there any treatment on this? Ie should there be any founded fear to include the key (beside it being pointless)? $\endgroup$– SEJPMDec 6, 2016 at 20:30
-
$\begingroup$ @SEJPM That's enough reason not to do it. But in general you should just use a key for one singular purpose. And mind that if you'd ever want to use hardware encryption (or something similar) that the key value may not even be available. $\endgroup$– Maarten Bodewes ♦Dec 6, 2016 at 20:37
-
-
1$\begingroup$ That's simple: 128 bits, the maximum size in other words. $\endgroup$– Maarten Bodewes ♦Dec 6, 2016 at 21:07
-
1$\begingroup$ Base64 encodes binary as text. You need to encode to binary; if you already have a byte array then you don't have to encode. As for the ID: long as it uniquely identifies the sender to the receiver (for the specific key). It depends on your protocol if you want to include name / surname & whatever more (you're good at final questions, I presume this was the last one?) $\endgroup$– Maarten Bodewes ♦Dec 6, 2016 at 21:28