>>However depending of the number of records, suddenly a field somewhere in the middle of the table which decrypted correctly earlier will throw up an error and leave the table 1/2 decrypted and useless.
>>
>>So I have a situation where everything works fine and then I add a single record at the end and a field in the middle which decrypted correctly earlier will not anymore making the table useless . It was because of this that I had to stop using it in my app.
>>
>>BErnard
>
>Given your use of ALLTRIM() on the encrypted data before decrypting it, I'm not surprised you found this code to be flaky. Instead of encoding the encrypted binary (such as turning it into hex) before stuffing it into the character fields you're stuffing the raw binary into the fields. This means that 0x20 (a.k.a. chr(32)) will occasionally start or end the binary ciphertext being placed into the field. So, instead of the decrypt function being handed the entire 32 bytes of the ciphertext (AES 256 is a 32 byte block cipher) you are handing it 31 (or even 30 if there was a 0x20 on both ends) bytes of the actual ciphertext the FLL produced when encrypting the original plaintext. Granted the FLL could do a much better job of letting you know what is happening or more gracefully handle the exception, but the origin of the problem is with your code not with the FLL.
>
Hi Craig

I understand what you are saying, but I had no idea that the return from the Decrypt/Encrypt function was returning binary data. I always assumed it was a string and did not know about the CHR(32)

However my use of Alltrim would strip CHR(32) off either/both end/s, causing an error.
So what you suggest would be to parse the encrypted string, convert each chr to hex and insert the HEX string into the field and vice versa for decryption?

>Another thing that could happen here (it would depend on your data) is that more than 32 bytes of plaintext were being encrypted which would cause the AES block cipher to add another 32 byte block making the ciphertext 64 bytes long which wouldn't fit into the fields as specified in your post. While the stripping of 0x20 was surely happening, this other scenario i provide for completeness. If you had needed the plaintext to be able to fill more than 32 bytes of the 50 byte fields you gave it then you would have needed to use a stream cipher or increase the fields to the appropriate block size multiple for the block cipher you were using.

The strings I usually enter are like this:

Pieces                                  toopen                                 stringx                     ofx
--------------------------------------------------------------------------------------------------------
Zest Health Clubs                  UBSCOMPANY                     ZESMENU            ZESALLOW 

toopen - last 3 chrs from the pieces field + "company"
stringx - first 3 chrs from the pieces field + "menu"
ofx first 3 chrs from the pieces field + "allow"

The reason I am doing concatenation of these strings is that the encrypt FLL always returns the same string for a similar passed string so if I try to encrypt "ALLOW" on its own, the pattern could be obvious when viewing the encrypted string as the return value is always the same for "Allow"

That is why this threw me off because a field that decrypted correctly earlier would not, once I added a couple of new records.after it.

So while I understand how my using ALLTRIM() could strip off CHR(32), given that the encrypted string returned is always the same, I cannot see how the same string, will decrypt properly sometimes and when a few more records are added after it, it will throw an error.

Besides, as I see it, (I may be wrong) the function of the Encrypt/decrypt is to return an appropriate string back to me irrespective of what string I pass it. So even if I strip off the CHR(32)'s it should still return a string, although the string will be garbage. Am I right about this? If so then why does it just throw an error instead of just returning garbage?


>The number of records in the table have nothing to do with the FLL's encrypt function failing. I'm more than willing to look at this further with you if you think there is still a reproduceable problem somewhere with the latest version of vfpencryption71.fll.

This is the latest version as posted on your site. I have just conducted some tests and the FLL works as it should except that after I added a couple of records, it started failing at recno() = 39. All I did was add a record and a previously decrypted record is now failing leaving the table partly unreadable. The error is :

Program Error
****************
API call caused an exception.

I have saved the partly decrypted table and now this error occurs whenever I try to decrypt this table.

I can send you the table and code if you will be good enough to look at it.

Thanks

Bernard