-1

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? because 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?

  • If you modified a GCM ciphertext and it decrypted successfully, you didn't verify the authentication tag. I'm guessing you used OpenSSL to do this (or a wrapper around OpenSSL), which has a notoriously terrible API that makes it easy to make this sort of mistake. – Stephen Touset May 10 '18 at 20:58
  • 1
    This question should be closed here because it is only about cryptography, where it was actually cross posted and answered. pls no, it's considered extremely rude to cross post. – Maarten Bodewes May 11 '18 at 11:53
3

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

They are not at all comparable. SHA-256 is not a MAC! A MAC requires a secret. AES-128-CBC with an HMAC-SHA-256 on the ciphertext would be more similar to AES-128-GCM, but GCM would still be preferred simply because it gives you less opportunity to screw it up.

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

This sounds like you are either using the library incorrectly or the library has a bug. What is the library, and do you have an example that reproduces the issue?

AES GCM is authenticate then encrypt algorithm?

Not really. I'm not completely sure about the terminology here, but I don't think it's really considered MAC-then-encrypt or encrypt-then-MAC, it's in a separate class of AEAD modes that include a MAC in the encryption algorithm instead of before or after it. I'd say it's closer to encrypt-then-MAC though, as you can see in the diagram on Wikipedia it is the ciphertext that gets fed into the GHASH function, not the plaintext.

encrypt then authenticate feels more secure to me

See this question about encrypt-then-MAC vs MAC-then-encrypt. Encrypt-then-MAC is generally recommended, as it prevents things like the padding oracle attack (if done correctly), however you also have to be aware of things like not forgetting to include the IV in the MAC. You should not be doing this yourself, you should use a library that handles all of the "crypto stuff" for you.

AES GCM authentication even secure enough to be compared to SHA256 for example or is it CRC tier for quick integrity

As stated previously, SHA-256 is not a MAC, but the best comparison I found of HMAC-SHA-256 and GHASH is here. HMAC-SHA-256 truncated to 16 bytes seems to be secure to the full 128 bits, while GHASH's security is dependent on the ciphertext size. If an attacker tries to forge a 1 block ciphertext it has a 1/2128 chance of succeeding, however if they try a 232 - 1 block message (the maximum size for GCM) their chance increases to about 1/296. This is unlikely to matter in practice, as 296 is still prohibitively large, especially given that it requires using a many gigabyte ciphertext.

The other thing to remember about GCM is that its authenticity is reliant on unique nonces. If a nonce is ever reused you can no longer trust the authenticity of messages, which is a concern if you're not extremely confident that nonces will never be reused. The tradeoff is that GCM is generally much faster than CBC+HMAC, which is why it's usually preferred by TLS where keys are short-lived (making nonce reuse even less likely). As explained here, as long as you use either a 12 byte counter that you are very sure will never roll back (eg due to hardware failure) or a random 16 byte IV you should be fine.

  • Thanks for the detailed answer! by mentioning MAC here I meant HMAC. I am using Node crypto api Have a look at my code repl.it/repls/BlueViolentBookmark just press on run to see the results – pls no May 10 '18 at 18:24
  • @plsno I'd hoped you meant HMAC, but given how many people ask questions without knowing what they're talking about I generally assume the worst :) As for why adding ddd to the ciphertext doesn't break it, new Buffer(data, 'base64') seems to silently ignore characters after the == padding. If you add valid base64 data it works as intended. – AndrolGenhald May 10 '18 at 18:44
  • Great! so this wasn't related to the algorithm after all. Thanks! but now the final question is: is the authentication in AES GCM secure enough to be compared to SHA256 for example or I need to hash the ciphertext again with SHA? – pls no May 10 '18 at 19:07
  • @plsno I added a much better comparison of GHASH and HMAC. In general I'd just stick to GCM as it means the code handling the authenticity check is part of the library you're using, and hence probably much better vetted than your code will be. – AndrolGenhald May 10 '18 at 20:36

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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