0

The requirement is we want to generate a bunch of keys, and we need a way to validate if this key is generated by us. My suggestion is to generate a UUID, do a HMAC use a secret key on the UUID, then the UUID+HMAC result should be the key. The problem here is UUID+HMAC is too long, so we can use only part of them as key.

Meanwhile, my colleague suggests another way is to generate a UUID, do an AES on it, use the encrypted data as a key, he thinks the encrypted data can not be faked, but I am afraid this is not a safe way. As we don't do any other validation here.

So the question is: is it possible to fake an AES-encrypted data, that can be decrypted by a given secret key? If it is not possible to fake an AES-encrypted data, which one should we use? HMAC or AES?

Performance should be considered, because we have about 1 billion requests to handle every day.

techraf
  • 9,141
  • 11
  • 44
  • 62
Xilang
  • 111
  • 1
  • Well... It's not (too) hard to just import the libraries needed to AES encrypt it. Probably easier than faking it. – Henry F Aug 15 '16 at 04:31
  • 2
    I think [When to use HMAC alongside AES?](http://security.stackexchange.com/questions/63132/when-to-use-hmac-alongside-aes) answers if AES alone is save to use for this purpose. As for the remaining question which algorithm to pick exactly given a specific set of restrictions (size, performance...) please ask a separate question, i.e. keep questions focused on the topic described in the title. – Steffen Ullrich Aug 15 '16 at 04:49
  • 2
    The full use case is not clear, but a couple of thoughts. Signing is a valid approach, but rather than shipping UUIDs, pick a long secret every day (could be UUID or longer) then generate a short random number, and HMAC the random number + secret, and use the random number + HMAC as a key. Validate with secrets from yesterday or today. AES approach is not better, it still requires a secret, and encryption is more expensive than signing. Finally, if sequence semantics apply, consider one-time algorithms like skey. – Jonah Benton Aug 15 '16 at 05:21
  • 2
    AES encrypted data is a bad idea, since AES is a symmetric key algorithm. That means your client code MUST contain the AES key (or everything needed to spoof the key). The code to validate the data can be used to spoof it. – Aron Aug 15 '16 at 07:03

1 Answers1

1

So the question is: is it possible to fake an AES-encrypted data, that can be decrypted by a given secret key?

If there is no authentication added to the data, then yes, easily. Block ciphers are really just permutations of all possible plaintext blocks to all possible ciphertext blocks. Or, in other words, any 128-bit block of data is a valid ciphertext for some plaintext, for any encryption key.

However, if we require that valid plaintext blocks have some structure, like trivially requiring the last 64 bits to be zeroes, with the data in the other 64 bits, then only 1/2^64 ciphertext blocks will produce a "valid" plaintext. But that only works for one-block messages, and is harder to do with multi-block messages, so one might as well use something designed for authentication.

The requirement is we want to generate a bunch of keys, and we need a way > to validate if this key is generated by us.

This doesn't sound like something that would require encryption (making sure third parties can't read it), but authentication (making sure third parties can't fake it). Some message authentication code would seem to be in order (be it HMAC with some hash function, CMAC if you prefer AES). Note that there's no need to use the full authentication tag produced by the MAC. You can instead truncate it to trade off some security for a shorter length.

ilkkachu
  • 2,086
  • 1
  • 11
  • 15