Which column type is best for storing $tag, $iv, $key, $encryptedData generated by openssl_encryption, and in which format I should save these values?
I am using "aes-128-gcm" cipher method.
$\begingroup$
$\endgroup$
1
-
$\begingroup$ @kelalaka sorry i didn't understood, kindly explain it more please $\endgroup$ – Noman marwat Sep 23 '20 at 5:43
Add a comment
|
$\begingroup$
$\endgroup$
2
One can store all of the information as $$IV\mathbin\|encryptedData\mathbin\|tag$$ as concatenated in a blog object (though there is a limit for the size of a column).
But not the key!
- The key must never be stored with the data itself. This simply a bad way for security since there is no need to store the data as encrypted beacuse if an attacker can access the database we can assume that the data is not encrypted at all. One need to store the key elsewhere like HSM or drive from a password with a KDF.
As it is well-known for AES-GCM that one need to use an IV and Key pair only once. If a pair occurs twice the confidentiality is lost. The crib-dragging technique removes the messages but not the key. The attacker will x-or the two or more encrypted messages to the x-or of the messages
$$C_1 = M_1 \oplus keystream$$ $$C_2 = M_2 \oplus keystream$$ then
$$M_1 \oplus M_2 = C_1 \oplus C_2$$ and a passive attacker has the access $C_1 \oplus C_2$ since they are listening the channel. Now, they need to execute crib-dragging and that can be automated.
Only the key stream of CTR mode of operation is revealed. AES-CTR secure against the key finding, actually more formally it is CPA secure. (The GCM forgery is another case Even a single AES-GCM nonce reuse can be catastrophic.).
To mitigate this one needs to check the IV reuse, assuming there is only one key, then using a single column for the IV is a good choice. Querying the database for the existing of the IV can prevent the issue and faster than storing all in one column.
Actually, one can use the unique rowID for the IV for the GCM if data is not updated. This is like the counter mode suggested by the NIST.
There is one big issue here, though. If one updates a row and if an attacker observed the row before and after the update then the IV reuse occurs here. In this case, one need to generate the IV independent of the rowID and this is better since the data may be fixed today but not tomorrow.
-
$\begingroup$ sorry i dont understand crypto that much and i am also newbie. You explain very good but it's much deep which i cannot understand. Please elaborate in simple words $\endgroup$ – Noman marwat Sep 23 '20 at 18:00
-
