AES-GCM cipher in TLS

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

AES-GCM cipher in TLS

PS-9
I am trying to decrypt TLS 1.2 records that is using the TLS_AES_128_GCM_SHA256 cipher-suite using openssl's EVP API.

Per RFC 5246, decryption needs 4 inputs.
"
   In order to decrypt and verify, the cipher takes as input the key,
   nonce, the "additional_data", and the AEADEncrypted value.  The
   output is either the plaintext or an error indicating that the
   decryption failed.  There is no separate integrity check.  That is:

      TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce,
                                            AEADEncrypted,
                                            additional_data)
"

But, in the AES-GCM decryption example on openssl wiki at https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption shows the decryption also takes as input the tag to be verified.

I know that the Authentication tag is the last 16 bytes of the TLS 1.2 record payload. But, my confusion is why the RFC has no mention of the Authentication tag.

And so, to decrypt the TLS record, should I follow the example on openssl wiki?





--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: AES-GCM cipher in TLS

Matt Caswell-2
On 05/04/18 05:12, PS wrote:

> I am trying to decrypt TLS 1.2 records that is using the
> TLS_AES_128_GCM_SHA256 cipher-suite using openssl's EVP API.
>
> Per RFC 5246, decryption needs 4 inputs.
> "
>
>    In order to decrypt and verify, the cipher takes as input the key,
>    nonce, the "additional_data", and the AEADEncrypted value.  The
>    output is either the plaintext or an error indicating that the
>    decryption failed.  There is no separate integrity check.  That is:
>
>       TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce,
>                                             AEADEncrypted,
>                                             additional_data)
>
> "
>
> But, in the AES-GCM decryption example on openssl wiki at
>
https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption
> shows the decryption also takes as input the*tag *to be verified.
>
> I know that the Authentication tag is the last 16 bytes of the TLS 1.2
> record payload. But, my confusion is why the RFC has no mention of the
> Authentication tag.

Well you have to look in the right RFC :-). TLSv1.2 is specified in
RFC5246. This contains some high level information about how to use AEAD
ciphersuites in TLSv1.2 (in particular see section 6.2.3.3).

Then there is RFC5288. This should be read in conjunction with RFC5246
and provides information on a set of specific AEAD ciphersuites -
including all of the GCM ones. This provides information on how to
construct the nonce from the explicit and implicit parts. The
ciphersuites make use of the AEAD_AES_128_GCM algorithm as specified in
RFC5116.

RFC5116 has this to say on the authentication tag:

   The AEAD_AES_128_GCM authenticated encryption algorithm works as
   specified in [GCM], using AES-128 as the block cipher, by providing
   the key, nonce, and plaintext, and associated data to that mode of
   operation.  An authentication tag with a length of 16 octets (128
   bits) is used.  The AEAD_AES_128_GCM ciphertext is formed by
   appending the authentication tag provided as an output to the GCM
   encryption operation to the ciphertext that is output by that
   operation.

Matt
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: AES-GCM cipher in TLS

PS-9
Thanks Matt.

I did read those RFC as well. And here is the confusion. The RFC5116 says this section 2.1

  There is a single output:

      A ciphertext C, which is at least as long as the plaintext, or

      an indication that the requested encryption operation could not be
      performed.
Note the emphasis on "single output". So, encryption output is just a single output ciphertext C. This C is the ciphertext + tag from what I understand in a single output. Similarly, section 2.2, does not mention anything about separating the tag from the Ciphertext and just takes C as input.

Now assuming that openssl follows this, shouldn't the example at https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption just give a single output per the RFC. Instead the example requires Cipher text and tag to be extracted separately. Conversely, decryption should just take the ciphertext C (which includes the tag) and output the plaintext. But again the example requires separating the tag for verification.

In summary, per my understanding of the RFC, the auth tag is seamless and the application should not have to deal with it separately. Yet, the openssl example using EVP deals with tag separately.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: AES-GCM cipher in TLS

Matt Caswell-2


On 05/04/18 18:35, PS wrote:

> Thanks Matt.
>
> I did read those RFC as well. And here is the confusion. The RFC5116
> says this section 2.1
>
>   There is a *single output:*
>
>       A ciphertext C, which is at least as long as the plaintext, or
>
>       an indication that the requested encryption operation could not be
>       performed.
>
> Note the emphasis on "single output". So, encryption output is just a
> single output ciphertext C. This C is the ciphertext + tag from what I
> understand in a single output. Similarly, section 2.2, does not mention
> anything about separating the tag from the Ciphertext and just takes C
> as input.
>
> Now assuming that openssl follows this, shouldn't the example at
> https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption
> just give a single output per the RFC. Instead the example requires
> Cipher text and tag to be extracted separately. Conversely, decryption
> should just take the ciphertext C (which includes the tag) and output
> the plaintext. But again the example requires separating the tag for
> verification.
>
> In summary, per my understanding of the RFC, the auth tag is seamless
> and the application should not have to deal with it separately. Yet, the
> openssl example using EVP deals with tag separately.

Right - I understand where your confusion is. The EVP interface is *not*
an RFC5116 API. RFC5116 is itself built on top of another standard -
SP800-38D. The EVP API gives you an interface to GCM as defined in that
standard. RFC5116 wraps that standard with some additional requirements
such as the fact that tag is 16 octets in length and appended to the end
of the ciphertext. OpenSSL implements RFC5116 only in as much as it is
required to implement the TLS ciphersuites in libssl. The EVP interface
is just a building block provided by libcrypto to create those ciphersuites.

Matt
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users