Base64decode causing decrypt fault on Android?

[sphere]

Hi,

i'm guessing that base64decode does something wrong with the encrypted data, but only on Android.

I'm using the same kind of script in WIndows and there it works perfectly without errors.
The result from decrypt says:Bad Decrypt or Wrong Final Block Length
I did some tests to rule some thing out:
delete first 16 characters, works on windows, bad decrypt on Android
leave first 16 characters where they are, then it's Wrong Final Block Length on both platforms

tried with and without URLencode when encrypting, no change. URLdecode messes it up while decrypting.
So no URLDecode while decrypting. And as this works on Windows IDE/Standalone, it should work on Android too, it's the same engine.

Decrypting itself with a encrypted pasword and salted, decrypting works OK on Android.
So i checked if it had to do with getting the data from DB, but that's not the case.

If you Encrypt it, Base64Encode it and then Base64Decode it and Decrypt it directly on Android it gives an error as result too. Works ok on Windows.

So after retreiving some data from DB

Code: Select all

on mouseUp
put "some encrypted and base64encoded data" into tMe
      #base64 decode
           put the base64Decode of tMe into tSixfour
           #decrypt it
           put fDecr(tSixfour) into tDecry
           #put it somewhere
           put tDecry into fld"i can read it can i"
           end mouseUp
           
           private function fDecr vText 
   set the itemDelimiter to comma
   decrypt vText using "aes256" with password "!@#$%^&*" and salt"*&^%$#@" at "256" bit
   --answer the result
   return it
end fDecr          
           

and this partly in the program which encrypts

Code: Select all

function fEncr vText 
   set the itemDelimiter to comma
   encrypt vText using "aes256" with password "!@#$%^&*" and salt"*&^%$#@" at "256" bit
   delete char 1 to 16 of it 
   return it
end fEncr

and the base64Encode and URLEncode (although the last seems not always neccesary)

Hope anyone understand what i mean.
Seems like a bug to me for Android.

cheers.
Sphere

[jacque]

The dictionary suggests that all data coming from outside sources needs to be textEncoded. It's likely the database is using UTF8, and LC needs UTF16. TextDecode the base64 string before working with it, and see if that works.

[sphere]

Hi Jacque,

indeed the DB is UTF8mb4.
I tried it to textDecode -->base64decode-->decrypt but i get the same wrong final block length on Win and Android

the dictionary says textDecode converts text to binary, but it's already binary due to the base64Encoding.
LC needs UTF16, but on IDE and standalone windows it works ok with utf8 (even UTF8mb4) data from db

[jacque]

Try textDecode instead of textEncode. I think I gave you the wrong command, I get them confused until I think about which direction the encoding is going.

[sphere]

Do you mean this:

Encrypt-->base64encode-->textEncode

textDecode-->base64Decode-->Decrypt

or do you actually mean: textEncode--base64Decode-->Decrypt (so then it's first encoded from utf8 to utf16)--edit-- this gives also Wrong Final Block Length

[jacque]

Well, I spent half of last week dealing with encryption and now I can't find the entry in the dictionary that recommends textEncode/decode. I know it's in there somewhere.

But that probably isn't the problem. I just asked my Android tablet what its ciphernames are, and "aes256" isn't in there. There are a dozen variations of aes-256, including "aes-256-cbc" which is what the dictionary example uses. Try that one. Your original method should work:

Code: Select all

-- encrypt
encrypt vText using "aes-256-cbc" with password "!@#$%^&*" and salt"*&^%$#@" at 256 bit
put base64Encode(vText) into vText

-- decrypt:
put base64Decode(vText) into vText
decrypt vText using "aes-256-cbc" with password "!@#$%^&*" and salt"*&^%$#@" at 256 bit

I also might leave out the bit value and let LC use its default. It will be 256 anyway, and I'm not sure where or if the quotes should occur (but I think no quotes at all is correct.)

[dave.kilroy]

I do encrypt and decrypt similarly to Jacque which seems to work on all platforms (but I shouldn't use the default salt though).

Recently I've started to use the new secureKey external. I have a little function that fires on preOpenStack that checks the platform and minimum OS version and if secureKey can run it checks whether a secureKey has been made for the app, and if there isn't one, makes a new named secureKey. Then when the app needs to encrypt or decrypt something I call one of the functions below. Works on Android (but seems a fair bit slower than on iOS).

One day I'll make a scriptOnly library and include normal encrypt/decrypt if secureKey can't be used (the app I've used it on so far doesn't need this ... yet)

Code: Select all

function doEncryptAnd64 pData    
   put "xxxxxxxxxxxxxxx" into tPassword
   encrypt pData using "aes-256-cbc" with password tPassword 
   put it into tEncrypted
   put char 9 to -1 of tEncrypted into tEncrypted
   
   if the result is empty then 
      
      --carry out secureKey encryption
      if isMobile() OR the platform = "MacOS" then 
         if securekeyExists("xxxxxx") then
            
            try
               put securekeyEncrypt("xxxxxx", tEncrypted) into tEncryptedDone
               put tEncryptedDone into tEncrypted
            catch e
               answer e
               exit to top
            end try
         end if   
      end if
      
      put base64Encode(tEncrypted) into tBase64
      return tBase64
   else 
      return "Bad encrypt:" && the result
   end if
end doEncryptAnd64


function do64AndDecrypt pData
   put "xxxxxxxxxxxxxxx" into tPassword
   put base64Decode(pData) into tBase64Decoded
   
   --carry out secureKey decryption
   if isMobile() OR the platform = "MacOS" then 
      if securekeyExists("xxxxxx") then
         try
            put securekeyDecrypt("xxxxxx",tBase64Decoded) into pDataDone
            put pDataDone into tBase64Decoded
         catch e
            answer e
            exit to top
         end try
      end if   
   end if
   
   put "Salted__" before tBase64Decoded
   decrypt tBase64Decoded using "aes-256-cbc" with password tPassword
   put it into tDecrypted
   
   if the result is empty then return tDecrypted
   else return "Bad decrypt:" && the result
end do64AndDecrypt

[sphere]

Yes Jacque you're correct.

I overlooked it. there is indeed no aes256 only.
But aes-256-cbc,256 until 256-xts,512

so i have to correct the encryption and try again with one of the available options.
Thanks for your sharpness on this.

Will report back if it works or not.

Kind regards,
Sphere

[sphere]

Oops sorry, you're not correct Jaqcue...

i checked again and i did not overlook it, there is indeed aes256.
It's a bad pic but you can see it

So it should be able to use it.

aes256

any more ideas?

thanks Sphere

[jacque]

You're right, I overlooked it too. It's buried under all the hyphenated ones. Sorry about that.

I'm not sure why you would delete the first 16 characters, that doesn't seem necessary. I suppose you could try using the default bit length and salt to see if that works. If it does, add a salt. In other words, start with the bare basics and go from there.

I wish I could find the dictionary entry that talked about textEncoding/decoding. There was a warning that transferring data without that may fail in some cases. I suppose you'd textEncode to UTF8, then encrypt. When getting the data, decrypt and then textDecode...I think. If I get more time I'll try looking for the entry again. Right now I'm trying to fix a mess I made while trying to "improve" a project.

[sphere]

Thanks Jacque.
I will do some more trying, hope to find the culprit.

I know exactly what you mean, if i do this and that, that would make it a lot better...damn what did i change, it worked so great...

[bwmilby]

...if i do this and that, that would make it a lot better...damn what did i change, it worked so great...

Take a look at my Script Tracker... it can help you keep track of the changes made to the scripts of a stack (even without Git).
viewtopic.php?f=77&t=31079

[sphere]

Thanks Brian i will take a look at it.

[bwmilby]

Been playing around with encryption and "aes256" yields the same encrypted text at "aes-256-cbc" so my guess is that they are synonyms. I was able to encrypt with one and decrypt with the other.

The textEncode reference you are looking for is in the messageDigest dictionary entry. When computing hash values, you need to be sure the input data is in a common format or you could get different results.

On my computers, the salt (first 16 bytes) can be stripped if the salt is provided on the decrypt side. If the salt is not stripped, then the salt can be included or not, but if included it must be correct. Also note that only 8 bytes of the provided salt are used.

Your next to last line before the code in your initial post is interesting to me. You said that when you encrypt -> base64encode -> base64decode -> decrypt that the same code which works on Windows will cause an error on Android. That certainly appears to be a possible bug. If your DB contains content encrypted on Windows, then that would point to a possible issue with the base64decode side. You would also want to do a base64encode on Android and check that you can decode on Windows to the correct result.

Today I was looking at some VBA code that implements base64 encode/decode. It isn't that complicated and there is probably a LCS version somewhere that could be used to do some checks.

One easy thing that I can think to check would be trailing null characters after base64decode. If they were not trimmed properly that could generate a block length error. Not really sure how that type of thing could exist on only one platform though.

[[-hh]]

Did you already try to
        replace linefeed with empty
after base64Encode ?