Re: Problems verifying sample packet protection in appendix A of Using TLS to Secure QUIC

[Nick Harper <[e-mail]>]

On Tue, Jul 14, 2020 at 9:06 AM <[e-mail]> wrote:

> Hi,
>
>
>
> I’m working through Appendix A of the QUIC TLS doc to check my
> understanding, but am having trouble decrypting the sample client initial
> packet.  I’m unsure if I’ve made a silly error or two, or if I’ve made one
> or more incorrect assumptions.  Or both.
>
>
>
> The functions I’m using are the OpenSSL EVP ones.  I’m attempting to
> follow the recipe here:
>
>
> https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption#Authenticated_Decryption_using_GCM_mode
> in conjunction with the draft RFC.
>
>
>
>
>
> EVP_CIPHER_CTX_new()
>
>
>
> EVP_DecryptInit_ex(ctx, EVP_aes_128_gcm(), NULL, NULL, NULL)
>
>
>
> EVP_DecryptInit_ex(ctx, NULL, NULL, client_key, iv)         where the
> client key is 0x175257a31eb09dea9366d8bb79ad80ba and the iv is
> 0x6b26114b9cba2b63a9e8dd4f
>

You need to compute the nonce from the IV and the packet number. I assume
what the openssl documentation refers to as an IV is actually the nonce as
described in RFC 5116.

>
>
> EVP_DecryptUpdate(ctx, NULL, &len, pUnprotectedHeader,
> headerLength)           where the unprotected header is
> 0xc3ff00001d088394c8f03e5157080000449e00000002 – this I believe is the
> Additional Data required
>
>
>
> EVP_DecryptUpdate(ctx, decryptedPayload, &len, pPayload,
> payloadLength-16))   here I’m passing in the encrypted payload beginning
> 0xfb66bc5f and ending 0xe82a4d919d48, length 1162.  I’m assuming that the
> final 16 bytes of the payload is the authentication tag so am not passing
> it in here.  Note that if this assumption about the authentication tag is
> correct, I think it could be more clearly stated in the draft RFC.
>

This is a quirk of the openssl API unfortunately. An AEAD decryption
operation should take 4 inputs: the key, the nonce, the associated data,
and the ciphertext. The ciphertext, as defined by RFC 5116, includes the
tag. There's no requirement on the structure of an AEAD's ciphertext,
including that some portion of the ciphertext be able to be identified as a
tag. AES-GCM does have this structure where the tag is at the end of the
ciphertext, and unfortunately openssl makes that part of the api for the
AEAD open operation, even though someone using it should never have to know
that detail of the AES-GCM algorithm.

>
>
> EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_TAG, 16, tag) where tag is the
> final 16 bytes of the encrypted payload, ie 0x43b1ca70 a2d8d3f7 25ead139
> 1377dcc0
>
>
>
> EVP_DecryptFinal_ex(ctx, decryptedPayload + len, &len)
>
>
>
> Everything seems OK until the EVP_DecryptFinal_ex() call which fails.
>
>
>
> Is there anything obviously wrong with the above?  I’ve not posted the
> full source code as I’m not asking people to check my working, I’m really
> asking if my assumptions are correct, am I using the correct functions,
> input data etc.
>
>
>
> Thanks in advance
>
>
>
> Tim
>