Crypto data management and transport

When you store or transport crypto data, you can do it in two basic forms:

• Binary byte stream — Accessible through an ABL MEMPTR or RAW variable. This the native form in which key values and encrypted or hashed data are generated. The primary requirement for binary data is that you maintain byte-endian order for all hardware platforms where you transport the data. You can help to ensure this by using the GET-BYTE and PUT-BYTE functions to read and write the data instead of GET-LONG and PUT-LONG. You can also convert a binary data string into a string of hexadecimal character pairs using the ABL built-in HEX-ENCODE function, transport it to a different hardware platform, and convert hexadecimal character string back to binary on that platform using the ABL built-in HEX-DECODE function.
• Base64-encoded character string — Accessible through an ABL CHARACTER or LONGCHAR variable. You can convert binary data into this form using the ABL built-in BASE64-ENCODE function and convert it back to binary using the ABL built-in BASE64-DECODE function. The primary requirement for Base64-encoded and encrypted data is that you remember to decode it from Base64 before you decrypt the data.

If you store encrypted data in a database:

• Do not use it for searches or indexes unless duplicates are allowed, as there is no way to know that two different pieces of data have been encrypted to the same value.
• Plan for changes in the size of database items that you store in both clear text and encrypted form. When using AES and DES ciphers, both encryption and Base64-encoding increase the size of stored data.