0
$\begingroup$

Using the crypto_aead_aes256gcm functions from Sodium produces a ciphertext of "at most mlen (plaintext length) + crypto_aead_aes256gcm_ABYTES bytes (16 bytes) are put into c (ciphertext), and the actual number of bytes is stored into clen if clen is not a NULL pointer. The phrase "at most" is deceiving because, in testing, ciphertext length is always plaintext length + 16 bytes. Why is this the case if in the specifications for GCM the output is a ciphertext, denoted C, whose bit length is the same as that of the plaintext (5.2.1.2).

I was going to attempt to read/write files using this, so would I just read 32 bytes at a time?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
2
$\begingroup$

The result you are getting is the cipher text (the encrypted data) plus 16 bytes of authentication data. The authentication data (mentioned directly below the ciphertext in the resource you cited) ensures that the ciphertext cannot be changed without the change being detected, and is the (most important) thing that distinguishes GCM from regular CTR-Mode.

The authentication data is the same length, no matter how much data you encrypt. So, if you encrypt 1024 bytes, you will still only get 16 bytes of authentication data. This means that you will only have to plan for those extra 16 bytes once and can read / write all remaining data as usual, although it would probably be a good idea to check some open source projects using the same library and cryptography and see how they are doing it, just to be sure you're not making any mistakes (at least that's what I usually do).

Edit: Also note that implementation questions are better suited for Stackoverflow, as the Crypto Stackexchange mostly deals with the concepts and not the implementations of cryptography.

Improve this answer
$\endgroup$
10
  • $\begingroup$ Even specifying Null auth data with 0 length gives me mlen + abytes. So the authenticated data is just somewhere in the library's implementation? $\endgroup$
    – user10984587
    Commented Mar 21, 2016 at 16:10
  • $\begingroup$ The auth data you are talking about is Additional Authenticated Data (AAD), which is optional. GCM will always give you an authentication tag, no matter if you specify AAD. AAD is used to authenticate data that is not contained in the plain text, for example a file name or similar things. $\endgroup$
    – malexmave
    Commented Mar 21, 2016 at 16:13
  • $\begingroup$ If you want plaintext_length == ciphertext_length, you cannot use GCM and have to use something like CTR mode. However, you should never use encryption without authentication. $\endgroup$
    – malexmave
    Commented Mar 21, 2016 at 16:15
  • $\begingroup$ Ahh I see. I was under the impression AAD was just regular AD. So for each round of encryption (say 16 bytes), I'll get 32 (16 plain + 16 AD) back each time? Doubling file size doesn't sound so appealing if it means verifying the data is correct. $\endgroup$
    – user10984587
    Commented Mar 21, 2016 at 16:17
  • $\begingroup$ No, you will only get the authentication data once per encryption. So, if you encrypt 512 KB of data, you will get 512 KB of ciphertext + 16 byte of authentication data. $\endgroup$
    – malexmave
    Commented Mar 21, 2016 at 16:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.