0

I have a keystring which allows customer to have additional features.

Obviously I would like the software to check that this string is valid, and not modified.

Is the following idea feasible:

  • get the key string as encrypted value, and encode it in Base64 (my encrypted string is around 100 characters, for my purpose)
  • calculate the checksum (MD5) of course using a private salt.
  • weave the checksum into the encrypted data

In principle :

xxxxCxxxxxxCxxxxxxxxCxxxxxxxxxxCxxxxxxxxxxxxxCxxx
  • the places to weave into the encrypted data could be determined by first cher of the encrypted, creating up to 16 different patterns.

On checking the code validity I simply "unweave" the checksum, test if it's correct, and thereby know if the data has been modified.

Is my line of thoughts correct ?

MyICQ
  • 987
  • 1
  • 9
  • 25
  • What you are really trying to implement is DRM, using some ad-hoc obfuscation techniques. If someone can reverse engineer your software then your technique is not particularly difficult to overcome. If they cannot reverse your software then your technique is pointlessly complicated, just use an appropriate encryption with MAC. – President James K. Polk May 20 '19 at 13:52

1 Answers1

1

The cryptographic feature you're thinking of is called "authentication," and there are many well-established approaches. You should strongly avoid inventing your own, particularly using a long-outdated hash like MD5. When an encryption system is authenticated, it can detect changes to the ciphertext.

Your best approach is to use an authenticated cipher mode, such as AES-GCM. Used correctly, that combines encryption an authentication in a single operation. While decrypting an authenticated scheme, the decryption will fail if the cipher text has been modified.

If you don't have access to AES-GCM, the next option is AES-CBC+HMAC, which uses the more ubiquitous AES-CBC with a random IV, and appends a type of encrypted hash (called an HMAC) to the end of the message to authenticate it. In order to authenticate, you need to remove the HMAC, use it to validate that the cipher text is unmodified, and then proceed to decrypt normally. This scheme is generally called "encrypt then MAC."

The implementation details will depend on your language and frameworks.

Rob Napier
  • 286,113
  • 34
  • 456
  • 610
  • Rob, this is good information. Certainly some useful pointers. Is it correctly understood that client key will be CCCCCCHHHHHHH (C= crypt, H=HMAC), and to authenticate I split the two, then compare computed H from C with stored ? – MyICQ May 20 '19 at 21:01
  • Yes, though generally you'll also need to attach an IV to the front, so it's IV+Crypt+HMAC. A random IV is required with CBC. See https://github.com/RNCryptor/RNCryptor-Spec/blob/master/RNCryptor-Spec-v3.md for an example of a format like this (which has implementations in several languages). That format includes salts, as well, which are required if you're using a password for encryption rather than random keys. – Rob Napier May 20 '19 at 21:21
  • Given that your entire data is only about 100 bytes, the full RNCryptor format may be too heavy. It adds 66 bytes of overhead. But if you can afford the space, it's a simple-to-use system with many implementations. There are ways to get it a bit smaller, though, if needed. – Rob Napier May 20 '19 at 21:24