Decryption succeed in GCM mode when tag is truncated

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Decryption succeed in GCM mode when tag is truncated

michel-60
Hi all,

I was surprised that decryption succeeded in GCM mode althought the tag
was shorter than the one produced when encrypting,
as it is not the case in CCM. Is it the intended behaviour ?

In order to rule out a possible bug in my program, I finally used the
example code at :
https://github.com/openssl/openssl/blob/master/demos/evp/aesccm.c
https://github.com/openssl/openssl/blob/master/demos/evp/aesgcm.c
using OpenSSL 1.0.1h.

When altering line 91 of of aesccm.c with 'sizeof(ccm_tag)-1',
decryption failed.
But doing the same with aesgcm.c, line 100 : sizeof(gcm_tag)-10,
decryption succeeded.

Thanks in advance for any assistance with this.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Decryption succeed in GCM mode when tag is truncated

Thulasi Goriparthi
EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_TAG, sizeof(gcm_tag), gcm_tag);

When you change tag length with the above statement, you are telling
the decrypt context to consider only those many number of bytes
for tag comparision.



On Wed, Jun 18, 2014 at 4:52 PM, Michel <[hidden email]> wrote:
Hi all,

I was surprised that decryption succeeded in GCM mode althought the tag was shorter than the one produced when encrypting,
as it is not the case in CCM. Is it the intended behaviour ?

In order to rule out a possible bug in my program, I finally used the example code at :
https://github.com/openssl/openssl/blob/master/demos/evp/aesccm.c
https://github.com/openssl/openssl/blob/master/demos/evp/aesgcm.c
using OpenSSL 1.0.1h.

When altering line 91 of of aesccm.c with 'sizeof(ccm_tag)-1', decryption failed.
But doing the same with aesgcm.c, line 100 : sizeof(gcm_tag)-10, decryption succeeded.

Thanks in advance for any assistance with this.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Decryption succeed in GCM mode when tag is truncated

michel-60
In reply to this post by michel-60
Thank for your answer.

But isn't this strategy very hazardous ?
And why just for GCM and not CCM ?

Le 18/06/2014 14:37, Thulasi Goriparthi a écrit :
EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_TAG, sizeof(gcm_tag), gcm_tag);

When you change tag length with the above statement,  you are telling
the decrypt context to consider only those many number of bytes
for tag comparision.

Reply | Threaded
Open this post in threaded view
|

Re: Decryption succeed in GCM mode when tag is truncated

Thulasi Goriparthi
Truncate-able tags gave a way to truncated hmac extension.

Haven't gone through CCM RFC 3610 completely.

I can see the restriction of possible M values(Tag lengths) to 2, 4, 6, 8, 10, 12, 14, 16. Can you try reducing the tag size accordingly and see if it succeeds.


On Wed, Jun 18, 2014 at 6:52 PM, Michel <[hidden email]> wrote:
Thank for your answer.

But isn't this strategy very hazardous ?
And why just for GCM and not CCM ?

Le 18/06/2014 14:37, Thulasi Goriparthi a écrit :
EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_TAG, sizeof(gcm_tag), gcm_tag);

When you change tag length with the above statement,  you are telling
the decrypt context to consider only those many number of bytes
for tag comparision.


Reply | Threaded
Open this post in threaded view
|

Re: Decryption succeed in GCM mode when tag is truncated

michel-60
In reply to this post by michel-60
I tried all of 2, 4, 6, 8, 10, 12, 14, 16 values, and always got a
"Plaintext not available: tag verify failed".
Even when tag length of decryption was equal to tag length of encryption.
:-(
It just works for : tag length of decryption = tag length of encryption
= 16.

Thanks again for your help.

Le 18/06/2014 16:14, Thulasi Goriparthi a écrit :
> Truncate-able tags gave a way to truncated hmac extension.
> Haven't gone through CCM RFC 3610 completely.
>
> I can see the restriction of possible M values(Tag lengths) to 2, 4,
> 6, 8, 10, 12, 14, 16. Can you try reducing the tag size accordingly
> and see if it succeeds.
>


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Decryption succeed in GCM mode when tag is truncated

Thulasi Goriparthi
In the test program, you are feeding a fixed ccm_tag to decryption process. This will not work for CCM, as tag length itself will also be an input for tag generation. Change in tag length, will change the tag produced. I modified the decryption api(aes_ccm_decrypt) to take the tag generated by encryption api(aes_ccm_encrypt). It works fine.

Note: Tag length will internally be embedded within the IV(nonce).


On Wed, Jun 18, 2014 at 8:12 PM, Michel <[hidden email]> wrote:
I tried all of 2, 4, 6, 8, 10, 12, 14, 16 values, and always got a "Plaintext not available: tag verify failed".
Even when tag length of decryption was equal to tag length of encryption.
:-(
It just works for : tag length of decryption = tag length of encryption = 16.

Thanks again for your help.

Le 18/06/2014 16:14, Thulasi Goriparthi a écrit :

Truncate-able tags gave a way to truncated hmac extension.
Haven't gone through CCM RFC 3610 completely.

I can see the restriction of possible M values(Tag lengths) to 2, 4, 6, 8, 10, 12, 14, 16. Can you try reducing the tag size accordingly and see if it succeeds.



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Decryption succeed in GCM mode when tag is truncated

Thulasi Goriparthi
One more thing to correct myself.
2 as tag length is not allowed. only 4, 6,  8, 10, 12, 14, 16 are allowed.


On Wed, Jun 18, 2014 at 11:55 PM, Thulasi Goriparthi <[hidden email]> wrote:
In the test program, you are feeding a fixed ccm_tag to decryption process. This will not work for CCM, as tag length itself will also be an input for tag generation. Change in tag length, will change the tag produced. I modified the decryption api(aes_ccm_decrypt) to take the tag generated by encryption api(aes_ccm_encrypt). It works fine.

Note: Tag length will internally be embedded within the IV(nonce).


On Wed, Jun 18, 2014 at 8:12 PM, Michel <[hidden email]> wrote:
I tried all of 2, 4, 6, 8, 10, 12, 14, 16 values, and always got a "Plaintext not available: tag verify failed".
Even when tag length of decryption was equal to tag length of encryption.
:-(
It just works for : tag length of decryption = tag length of encryption = 16.

Thanks again for your help.

Le 18/06/2014 16:14, Thulasi Goriparthi a écrit :

Truncate-able tags gave a way to truncated hmac extension.
Haven't gone through CCM RFC 3610 completely.

I can see the restriction of possible M values(Tag lengths) to 2, 4, 6, 8, 10, 12, 14, 16. Can you try reducing the tag size accordingly and see if it succeeds.



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Decryption succeed in GCM mode when tag is truncated

michel-60
In reply to this post by michel-60
Ok, I have missed that point (and probably many others...)
I need to go deeper to better understand things,
and I am grateful for your explanations.

Le 18/06/2014 20:25, Thulasi Goriparthi a écrit :
In the test program, you are feeding a fixed ccm_tag to decryption process. This will not work for CCM, as tag length itself will also be an input for tag generation. Change in tag length, will change the tag produced. I modified the decryption api(aes_ccm_decrypt) to take the tag generated by encryption api(aes_ccm_encrypt). It works fine.

Note: Tag length will internally be embedded within the IV(nonce).

On Wed, Jun 18, 2014 at 8:12 PM, Michel <[hidden email]> wrote:
I tried all of 2, 4, 6, 8, 10, 12, 14, 16 values, and always got a "Plaintext not available: tag verify failed".
Even when tag length of decryption was equal to tag length of encryption.
:-(
It just works for : tag length of decryption = tag length of encryption = 16.

Reply | Threaded
Open this post in threaded view
|

Re: Decryption succeed in GCM mode when tag is truncated

Jeffrey Walton-3
On Thu, Jun 19, 2014 at 4:48 AM, Michel <[hidden email]> wrote:
> Ok, I have missed that point (and probably many others...)
> I need to go deeper to better understand things,
> and I am grateful for your explanations.
If AEAD schemes are your thing, then you might take a look at David
Wagner's http://www.cs.berkeley.edu/~daw/talks/FSE04eax.ppt. Slide 7
has a nice comparison of CCM, CWC, EAX and GCM modes of operation.

The three biggest seem to be (1) patent avoidance, (2) online vs
offline, and (3) parallelizable.

CWC is a single pass scheme but its patented (the CWC designers hold
the patent for the single pass). I believe the remainder of the
schemes are double pass to avoid the single pass patent.

CCM is probably the oldest of the three, its more complicated, and its
offline (you have to have all data beforehand - you cannot stream data
into it).

Personally, I don't care about GCM's parallelizability because I
require all data to be authenticated before being operated upon.

Jeff
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Decryption succeed in GCM mode when tag is truncated

michel-60
In reply to this post by michel-60
Hey, thanks Jeff !

I also inadvertently found an interresting article of a certain M. J. W. ...
;-)
I should have read more carefully :
http://www.codeproject.com/Articles/34380/Authenticated-Encryption
particularly when it states : "It is up to the receiver to determine
whether to accept a tag which is truncated".

I take the opportunity to thank the numerous people on this list from
whom I have learned a lot reading at their posts,
I cannot name them all, but Dave if one of them.

Le 19/06/2014 11:19, Jeffrey Walton a écrit :
> If AEAD schemes are your thing, then you might take a look at David
> Wagner's http://www.cs.berkeley.edu/~daw/talks/FSE04eax.ppt. Slide 7
> has a nice comparison of CCM, CWC, EAX and GCM modes of operation.
>

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Decryption succeed in GCM mode when tag is truncated

Jakob Bohm-7
In reply to this post by Jeffrey Walton-3
On 6/19/2014 11:19 AM, Jeffrey Walton wrote:
> ...
> CCM is probably the oldest of the three, its more complicated, and its
> offline (you have to have all data beforehand - you cannot stream data
> into it).
>
> Personally, I don't care about GCM's parallelizability because I
> require all data to be authenticated before being operated upon.
>
Note that the parallelizability applies to the sender too.

So with parallel GCM, the sender can start sending before it knows and
encrypts the last part of the plaintext, while a secure receiver still
needs to wait for the end before accepting the data.  So the total
delay is
   max(encrypt_time, transmit_time) + decrypt_time
while a non-parallelizable mode would have
   encrypt_time + transmit_time + decrypt_time

Of cause there are other drawbacks to the various mode that
needs to be considered before choosing one.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]