3
$\begingroup$

I am trying to have something like JWT but kinda ad hoc and encrypted. The token itself is simply a stringified JSON that contains the user ID and Unix timestamp.

Now, I tried to use AES-128-GCM, however I did some simple modification in the ciphertext before decrypting, just appended some bytes to the ciphertext, and found that it decrypts successfully, does that mean that those bytes were counted as padding and that AES GCM is authenticate then encrypt algorithm?

I feel that encrypt-then-authenticate feels more secure to me. Also, is AES GCM authentication even secure enough to be compared to SHA256 for example or is it CRC tier for quick integrity and cannot be used for secure authentication like HMAC?

In other words: is AES-128-CBC then SHA-256 more secure than AES-128-GCM?

Improve this question
$\endgroup$
3
  • $\begingroup$ What is the delegation structure? Do you have a single server minting and verifying credentials? Can users delegate their credentials to other users? Can users add additional caveats? If all of these are yes, you would be better off using Macaroons. $\endgroup$
    – cypherfox
    May 11, 2018 at 3:35
  • $\begingroup$ Thanks, I heard of Macaroons but I think it's too complex for my use case, I just want a token that contains the user id so that it can be verified in my own server. I could just use JWT but I wanted to create an ad hoc alternative that is simple just the json containing the user id and timestamp, encrypted and authenticated $\endgroup$
    – pls no
    May 11, 2018 at 3:38
  • $\begingroup$ Macaroons are as simple as it gets. No need to encrypt. $(0, \operatorname{HMAC}_\text{server-secret}(0 \| 0))$ as the (UID=0) user's credential and $(0, \text{msg}, \operatorname{HMAC}_\text{previous-tag}(1 \| \text{msg}))$ as the authenticated invocation over the message $\text{msg}$. If you don't need any provisioning caveats, don't implement them. But if you later want them. They are trivial to add. Your "unix timestamp" looks like a caveat to expire after some time and may be better encoded as TAI64. If you want to encrypt anything, you've conveniently got a preshared key already. $\endgroup$
    – cypherfox
    May 11, 2018 at 3:42

1 Answer 1

Reset to default
3
$\begingroup$

just appended some bytes to the ciphertext, and found that it decrypts successfully

Normally this shouldn't happen, as the appended bytes surely aren't a valid authentication tag for the previous "ciphertext". I suppose (but don't know!) the implementation you are using encoded the length of the ciphertext, the associated data and the tag and retrieved these values upon decryption, ignoring the added values, yielding a correct decryption.

AES GCM is authenticate then encrypt algorithm? because I feel that encrypt then authenticate feels more secure to me

AES-GCM is an authenticated encryption algorithm. Encrypt-then-Authenticate is one specific construction that achieves this general definition and is indeed preferable to Authenticate-then-Encrypt, which is why GCM internally does encrypt-then-authenticate and so AES-GCM achieves the same security definition as CBC-then-HMAC.

is AES-128-CBC then SHA-256 more secure than AES-128-GCM?

When you say "AES-128-CBC then SHA-256" I suppose you actually mean AES-128-CBC with HMAC-SHA256 authentication on the ciphertext.

Then yes, technically that is more secure, because HMAC-SHA256 requires $2^{128}$ operations to come up with a forgery, whereas AES-128-GCM allows you to perform a multi-target search for a key that works dropping security slightly below $2^{128}$. So it also has a serious security level unlike CRC. Also from this we can infer that both are secure, as neither $2^{128}$ nor $2^{100}$ operations are feasible making them both "secure" (a.k.a. "meh, can't break"), so you might as well use the easier-to-use and faster AES-GCM, assuming you have hardware support available, which is the case on modern x86 processors.

See Squeamish's comments below for a more detailed discussion of the actual values. Also see their answer here.

Improve this answer
$\endgroup$
8
  • $\begingroup$ The authentication tags for GCM are typically shorter (80 or 96 bits) and not as equally distributed so a HMAC (even truncated) does add quite some additional confidence (which is especially important for tokens where forgery is a threat). However 12byte Tags might still be acceptable if compactness is required. $\endgroup$
    – eckes
    May 13, 2018 at 4:06
  • $\begingroup$ Isn't GHASH provides $\sqrt{n}$-bit protection againts forgery ? $\endgroup$
    – kelalaka
    Feb 12, 2019 at 16:48
  • $\begingroup$ @kelalaka indeed $2^{n/2}$ online queries are sufficient to break GCM authenticity (the attacker advantage scales quadratically with the number of total queries and plaintext length). I'm currently unsure whether this implies 64-bit security for GCM in general. $\endgroup$
    – SEJPM
    Feb 12, 2019 at 19:30
  • $\begingroup$ Ok, Whoever gets it first, note it here :) $\endgroup$
    – kelalaka
    Feb 12, 2019 at 19:32
  • 2
    $\begingroup$ @kelalaka so I wrote up a question and while writing the answer for this case came to my mind: In this case the security is probably $2^{128}$, assuming the server re-keys / re-issues on encountering an invalid tag. I asked anyways, because I'm still not 100% sure / confused. $\endgroup$
    – SEJPM
    Feb 12, 2019 at 19:53

Your Answer

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

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