I need to send some encrypted data to MySQL db server to store as encrypted. Another non-labview application (C#, MS Visual Studio?), written by another person, will connect to the MySQL later to get this data. The ideal solution when this non-labview application will get encrypted data and decrypt it. But I predict this person will have a problem with decrypting data in his application so, as a first step, I would like to give him ability to decrypt data by MySQL on the db server side. So, I need to come up with some more or less good encryption algorithm which allow me to encrypt data in Labview and decrypt it using MySQL functions. I have selected AES encryption 128 bit key, and we have Crypto-G library bought around 10 years ago we were used in some other projects. The problem is data encrypted by Labview cannot be decrypted by MySQL functions, and visa versa, although own encryption both can decrypt easily. There is a difference in encrypted string coming from LV and MySQL, first 32 hex characters are the same, but last 32 characters are totally different. MySQL function accept any length of plain text, but LV library required both to be multiple of 16, so I have to do padding, and I believe there is a compatibility issue here, in Labview I have to do padding on the same way how MySQL internally does it.
Are there any idea how to solve the problem? It is not required to use specifically AES encryption, other algorithms are also acceptable, but it should be better than XORing and it should work on both sides, on Labview and on MySQL.
I think I should not distribute commersial VIs, so I will give only screenshots, sorry...
Solved! Go to Solution.
Are you able to send something that falls exactly on the boundary so you can rule out padding issues? If not, what are you padding with? NULLs? Unfortunately, that is about as much help as I can give. 😞
Yes, I can remove padding on labview encryption and send exactly 16 chars plaint text. But encrypted text is still different, 64 chars in mysql and 32 chars (matching to first 32 in mysql case) in labview... So, cross-platform decrypting will not work.
Your problem most likely is how you pad the data. There are various padding schemes. One popular is PKCS7 (described in RFC 5652). This pads data to the blocksize with the number that is equal to the number of added bytes. If the original data is an integer multiple of N bytes, then an extra block of bytes with value N is added.
Yes! Thank you, I have just now find out MySQL uses PKCS7 padding, and came here to write it down, I was able to decrypt in Labview (with no padding) ciphered in text in MySQL and saw padding characters. A little experiments and I have realized how MySQL padding schema is working. A little googling and I know how it calls :-). Anyway, thank you for your help.
Just for information: this padding schema (PKCS#7) is described here: rfc5652#page-12
Some content-encryption algorithms assume the input length is a multiple of k octets, where k > 1, and let the application define a method for handling inputs whose lengths are not a multiple of k octets. For such algorithms, the method shall be to pad the input at the trailing end with k - (l mod k) octets all having value k - (l mod k), where l is the length of the input. In other words, the input is padded at the trailing end with one of the following strings: 01 -- if l mod k = k-1 02 02 -- if l mod k = k-2 . . . k k ... k k -- if l mod k = 0 The padding can be removed unambiguously since all input is padded and no padding string is a suffix of another. This padding method is well-defined if and only if k < 256; methods for larger k are an open issue for further study
More information is here: https://bugs.mysql.com/bug.php?id=16713
Btw, MySQL allow to use any key length too, although it should match obviously to used key length (16, 24 or 32 bytes for 128, 192 or 256 bits key). And it is padded with zeroes.