>>Hi,
>>
>>This is a follow up my thread on the same subject. Just to refresh:
>>I store (un-encrypted) a string that consists of "Y" and "N" in a 250 char field GRP_ACCESS (in SQL Server). Each position corresponds to a feature in the application. When a user logs in, based on his credentials, he may or may not have access to a feature (based on the value in the GRP_ACCESS field).
>>
>>I tried to encrypt the values in this field using the function cipher() (created by S. Berezniker). This function creates an encrypted string (based on the "YYYYNNNNYN..." But if one were to look at the encrypted field you can clearly see a pattern. For example, the users who have/had all "Y"s in the un-encrypted field get the same encrypted string. It is just the encrypted string has many non-ascii characters; so it looks unreadable. But if someone wants to, they can simply store the field value into a variable and then execute the UPDATE table and set this value in all records. I doubt my customer would do it. But, I would like to explore other ways to encrypt the field.
>>
>>If you have any suggestions, please let me know.
>
>Dmitry,
>
>Just to add two more things to this thread that is already filled with nice stuff, as usual.
>
>Symmetric encrypt implementations often face the same problem you noticed while looking at the encrypted strings. One common way to solve this problem is to lead the encryption with an initialization vector, which is a string of random characters of a known size (for block ciphers, normally the size of a block). This will generate different strings for the same input data but will, of course, require extra space to hold the additional leading block and the decrypting will need to substring the result.
>
>Regarding Mike Gagnon's suggestion, remember that you have already a series of integer values, not of 32-bit integers, but of 8-bit integers. That's what a string is. To hold 250 different logical values, CEILING(250 / 8) = 32 characters would be enough, and a string like yours "YYYNYYNN" could be represented as a single CHR(236).

Hi Antonio,

Thank you for your suggestions. As far as your explanation of 250 logical values and 32-bit integers, I hang my head in shame. I don't understand it off the typed message (lack of formal computer education shows). But I will read it again and hopefully get it, at some point. Thank you.