Would this be secure enough? (ZF3 & Doctrine module using halite)

Question

Recently PHP7.2 was released with the Sodium library included for encryption.

Of course there were already encryption modules available, even working with Zend Framework 2 or Symfony. We were in need of an implementation for Zend Framework 3 and not wanting to rely on our own encryption method ideas, we created a ZF3 & Doctrine 2 module that uses paragonie's encryption implementation.

The purpose, at the moment, is to be able to automatically encrypt and decrypt on read/write of certain properties, detected via a listener hooked into the Doctrine ORM.

How we've set it up is the following:

Default

1. Receive a string (do not encrypt null)
2. Add in-code (config) salt to string
3. Use in-code (config) private key for encryption

Obviously, not the strongest method of extending a string, but this is to make sure we can encrypt data marked with a tag using default settings. Data such as a street name.

Options

1. Receive a string (do not encrypt null)
2. Add generated 32 char salt and/or pepper before (and after) string (stored in separate db table, though records linked via foreign key)
3. Add in-code (config) salt to string
4. Use in-code (config) private key for encryption

---

This is the module we, actually just me, created. The actual implementation of the encryption/decryption starts about here.

• processFields function - decides whether to encrypt/decrypt, passes values and, on decrypt, tries a type cast (to support value types) to return original value type
• encrypt function - decides if salt and/or pepper need to be added based upon passed options. Then calls "encrypt" on adapter.
• decrypt function - decides if salt and/or pepper were added based upon passed options. Removes them from string to return original string to encrypt.
• Halite adapter - This is the default encryption/decryption adapter

---

Why am I asking?

Because I hope I've understood most everything right and thus created something awesome. However, as I'm not cryptology expert and we have no such person in-house, I thought to ask here, hoping to gain some feedback.

The code is provided as is and open source. It's extendable and re-usable so others can use the same service but can use their own encryption adapter. However, I wouldn't want them using something sub-par.

Answer 1

What you did right

You're using a library

You chose to use a library to do the encryption for you. Good job! Somehow people still screw this up. Don't be a Dave, never roll your own crypto (unless you really, really understand what you're doing).

What you did wrong

You're misusing terminology

A salt is used when hashing passwords. It must be unique per password, and thus can't be located in a config. A pepper is similar to a salt, but it's the same for each password, and so it can be located in a config. Neither of these has anything to do with encryption.

You're trying to "improve" the encryption without understanding it

Adding a unique value to each string is unnecessary because (good) encryption algorithms use initialization vectors or nonces to randomize their output when encrypting duplicate data. Halite uses XSalsa20 MACed with a keyed BLAKE2b hash. Don't try to make it better, you'll just add complexity to your implementation for no reason.

There is a legitimate reason to pad data before encrypting, and that is to hide the length of the data. Some encryption algorithms allow an attacker to determine the length of the plaintext rounded to a number of bytes, and others allow to determine the exact length of the plaintext. In this case however you should pad all data to the same length (or a multiple of the same length), and the padding needn't be random.