# Data encription
These classes will handle encryption for various use cases.

# encrypt()
Will encrypt the input data, and return the multi-part result:
 - `$encryptedData` - the encrypted data, in binary form
 - `$encryptionParams` - an array with the parameters used when generating the data above. These params should be saved in a "safe" place. **You will need them for decryption**.

Each part of the `$encryptionParams` result can be set via setter functions if we don't want to generate new ones for each call. It's actually recommended to have `$encryptedData` and `$encryptionParams` stored in separate storage "boxes". This way of one of the "boxes" leaks, an attacker would not be able to recover the whole data back.

# decrypt()
Will decrypt the input data It needs the exact same data as the output from `encrypt()`:
 - `$encryptedData` - the encrypted data, in binary form
 - `$encryptionParams` - the parameters used when the data above was generated

### Storage
When `encrypt()` is called, it generates multiple output data, that should be safely stored. Best case, we store each part of the output on separate servers. Ex: store `$encryptedData` on server1, `$encryptionParams['key']` on server2, `$encryptionParams['nonce']` on server3, `$encryptionParams['algo']` on server4. This would make decryption extremly hard for the developer, so simpler local solutions are needed.

Depending on the stored screts and limitations, you might pick a "easy" storage solution" or a really complex one. Also, when storing another encryption layer sould be used.

It's acceptable (in this order) to:
 - store `$encryptedData`, `$encryptionParams` in DB.table1
 - store `$encryptedData` in DB.table1, `$encryptionParams` in DB.table2
 - store `$encryptedData` in DB.table1, `$encryptionParams` on disk, in separate files
 - store `$encryptedData` in the DB.table1, `$encryptionParams['key']` in the app config (php-based), `$encryptionParams['nonce']` in DB.table2

You could reuse `key` but let the `nonce` get re-generated for each call, so that you only need to safely store `$encryptedData` and `$encryptionParams['nonce']`. `$key` could be safely loaded from the app config (php-based, when php source files are encoded by Zend Encoder) or from `$ENV`.

You could also reuse `key` and `nonce`, but they should at least get generated per client instance, and stored safely on their server. This way if one TINA instance leaks, the data cannot be used to attack another instance.




### Adding new classes
Each class should implement `encrypt()`, `decrypt()` calls and any adjacent methods.
Ex: if the encryption will need `$passphrase`, then the class should also implement `setPassphrase()`. If the passphrase was never set, then `encrypt()` should auto-generate it and return it.

