[TIMOB-23595] Android: Recompile ti.crypto module against latest SDK

[sgtcoolguy]

https://jira.appcelerator.org/browse/TIMOB-23595

[ashcoding]

Could you include the compiled zip/binary as well so that it could be tested easily as well as a sample app.js? It would be very helpful.

[sgtcoolguy]

ti.crypto-android-3.0.0.zip

https://github.com/appcelerator-modules/ti.crypto/tree/master/android/example

Note that I had to update our usage of Base64 on this module. It was using the apache commons version (which is now gone), and I changed it to the android.util.Base64 version.

[cheekiatng]

I created a new app and used the new packaged module with latest master build. The app builds and runs normally. But it's giving inconsistent results compared to using version 2.0.2 on Ti SDK 5.3.1.
Using the example app:

ti.crypto 2.0.2 + ti.sdk 5.3.1.GA
AES-128->Single Call->Encrypt = bs9V7YCfwsqGb8yWgXFlxMO1......
Decrypt = Titanium Crypto Module
vs
ti.crypto 3.0.0 + ti.sdk 6.0.0.v20160711212308
AES-128->Single Call->Encrypt = ZjdioBTkZDjea6steeigUQ==
Decrypt = ""

[sgtcoolguy]

The example test.js all ran and passed for me:

[INFO]  ENCODE PASS (type: hexstring, input: 68656c6c6f, out: hello)
[INFO]  DECODE PASS (type: hexstring, input: hello, out: 68656c6c6f)
[INFO]  ENCODE PASS (type: hexstring, input: 676f6f64627965, out: goodbye)
[INFO]  DECODE PASS (type: hexstring, input: goodbye, out: 676f6f64627965)
[INFO]  ENCODE PASS (type: base64string, input: dGVzdCBiYXNlIDY0IGVuY29kaW5n, out: test base 64 encoding)
[INFO]  DECODE PASS (type: base64string, input: test base 64 encoding, out: dGVzdCBiYXNlIDY0IGVuY29kaW5n)
[INFO]  PASS AES-128x128 (type: single, direction: encrypt)
[INFO]  PASS AES-128x128 (type: single, direction: decrypt)
[INFO]  PASS AES-128x128 (type: multiple, direction: encrypt pass 1)
[INFO]  PASS AES-128x128 (type: multiple, direction: encrypt pass 2)
[INFO]  PASS AES-128x128 (type: multiple, direction: decrypt)
[INFO]  PASS AES-128x192 (type: single, direction: encrypt)
[INFO]  PASS AES-128x192 (type: single, direction: decrypt)
[INFO]  PASS AES-128x192 (type: multiple, direction: encrypt pass 1)
[INFO]  PASS AES-128x192 (type: multiple, direction: encrypt pass 2)
[INFO]  PASS AES-128x192 (type: multiple, direction: decrypt)
[INFO]  PASS AES-128x256 (type: single, direction: encrypt)
[INFO]  PASS AES-128x256 (type: single, direction: decrypt)
[INFO]  PASS AES-128x256 (type: multiple, direction: encrypt pass 1)
[INFO]  PASS AES-128x256 (type: multiple, direction: encrypt pass 2)
[INFO]  PASS AES-128x256 (type: multiple, direction: decrypt)
[INFO]  PASS DES (type: single, direction: encrypt)
[INFO]  PASS DES (type: single, direction: decrypt)
[INFO]  PASS DES (type: multiple, direction: encrypt pass 1)
[INFO]  PASS DES (type: multiple, direction: encrypt pass 2)
[INFO]  PASS DES (type: multiple, direction: decrypt)
[INFO]  PASS 3DES (type: single, direction: encrypt)
[INFO]  PASS 3DES (type: single, direction: decrypt)
[INFO]  PASS 3DES (type: multiple, direction: encrypt pass 1)
[INFO]  PASS 3DES (type: multiple, direction: encrypt pass 2)
[INFO]  PASS 3DES (type: multiple, direction: decrypt)
[INFO]  PASS CASTxMin (type: single, direction: encrypt)
[INFO]  PASS CASTxMin (type: single, direction: decrypt)
[INFO]  PASS CASTxMin (type: multiple, direction: encrypt pass 1)
[INFO]  PASS CASTxMin (type: multiple, direction: encrypt pass 2)
[INFO]  PASS CASTxMin (type: multiple, direction: decrypt)
[INFO]  PASS CASTxMax (type: single, direction: encrypt)
[INFO]  PASS CASTxMax (type: single, direction: decrypt)
[INFO]  PASS CASTxMax (type: multiple, direction: encrypt pass 1)
[INFO]  PASS CASTxMax (type: multiple, direction: encrypt pass 2)
[INFO]  PASS CASTxMax (type: multiple, direction: decrypt)
[INFO]  PASS RC2xMin (type: single, direction: encrypt)
[INFO]  PASS RC2xMin (type: single, direction: decrypt)
[INFO]  PASS RC2xMin (type: multiple, direction: encrypt pass 1)
[INFO]  PASS RC2xMin (type: multiple, direction: encrypt pass 2)
[INFO]  PASS RC2xMin (type: multiple, direction: decrypt)
[INFO]  PASS RC2xMax (type: single, direction: encrypt)
[INFO]  PASS RC2xMax (type: single, direction: decrypt)
[INFO]  PASS RC2xMax (type: multiple, direction: encrypt pass 1)
[INFO]  PASS RC2xMax (type: multiple, direction: encrypt pass 2)
[INFO]  PASS RC2xMax (type: multiple, direction: decrypt)

[sgtcoolguy]

Hmm, you're right, the manual single encrypt/decrypt seems to fail...

[sgtcoolguy]

Even weirder, if you keep clicking encrypt, it keeps appending to the encrypted value

[sgtcoolguy]

This is driving me insane. It is not very easy to find nice input test data and see if we get what we expect here... So I can't even validate whether one is "right" or not. Clearly the old module at least decrypts back to the original text, so it must be correct. But I don't understand why the changes I made would be the difference here. I'm more concerned that somehow buffer/string translation across the KrollBridge might be a cause. I can't see how the Base64 update would have done it... I suppose I can try and compile with the base64 changes against 5.4.x and verify that way...

[sgtcoolguy]

So I recompiled against 5.4.x with the Base64 changes and that worked fine. So... 😢 looks like the V8 update must be the root cause of the issue. Ugh.

Need to look into what exactly may have changed here that would cause this. The tests all pass just fine in this module, but obviously the UI based variant fails. So the bug lies somewhere in the difference between the two implementations.

[sgtcoolguy]

So something really weird is happening here. I was trying to have Titanium spit out the key/iv used to encrypt to see how it differed. Using 5.4.x/2.0.2, I had it spit out the key at the end of the createKey method and it'd always show as undefined. With 6.0.0/3.0.0, it seemed to hold the last buffer's decrypted text in it already!

See old output:

[INFO]  ENCODE PASS (type: hexstring, input: 68656c6c6f, out: hello)
[INFO]  DECODE PASS (type: hexstring, input: hello, out: 68656c6c6f)
[INFO]  ENCODE PASS (type: hexstring, input: 676f6f64627965, out: goodbye)
[INFO]  DECODE PASS (type: hexstring, input: goodbye, out: 676f6f64627965)
[INFO]  ENCODE PASS (type: base64string, input: dGVzdCBiYXNlIDY0IGVuY29kaW5n, out: test base 64 encoding)
[INFO]  DECODE PASS (type: base64string, input: test base 64 encoding, out: dGVzdCBiYXNlIDY0IGVuY29kaW5n)
[INFO]  key: undefined
[INFO]  PASS AES-128x128 (type: single, direction: encrypt)
[INFO]  PASS AES-128x128 (type: single, direction: decrypt)
[INFO]  key: undefined
[INFO]  PASS AES-128x128 (type: multiple, direction: encrypt pass 1)
[INFO]  PASS AES-128x128 (type: multiple, direction: encrypt pass 2)
[INFO]  PASS AES-128x128 (type: multiple, direction: decrypt)
[INFO]  key: undefined
[INFO]  PASS AES-128x192 (type: single, direction: encrypt)

And new:

[INFO]  ENCODE PASS (type: hexstring, input: 68656c6c6f, out: hello)
[INFO]  DECODE PASS (type: hexstring, input: hello, out: 68656c6c6f)
[INFO]  ENCODE PASS (type: hexstring, input: 676f6f64627965, out: goodbye)
[INFO]  DECODE PASS (type: hexstring, input: goodbye, out: 676f6f64627965)
[INFO]  ENCODE PASS (type: base64string, input: dGVzdCBiYXNlIDY0IGVuY29kaW5n, out: test base 64 encoding)
[INFO]  DECODE PASS (type: base64string, input: test base 64 encoding, out: dGVzdCBiYXNlIDY0IGVuY29kaW5n)
[INFO]  key: test base 64 encoding
[INFO]  PASS AES-128x128 (type: single, direction: encrypt)
[INFO]  PASS AES-128x128 (type: single, direction: decrypt)
[INFO]  key: Titanium Crypto Module
[INFO]  PASS AES-128x128 (type: multiple, direction: encrypt pass 1)
[INFO]  PASS AES-128x128 (type: multiple, direction: encrypt pass 2)
[INFO]  PASS AES-128x128 (type: multiple, direction: decrypt)
[INFO]  key: Some additional text to encrypt
[INFO]  PASS AES-128x192 (type: single, direction: encrypt)
[INFO]  PASS AES-128x192 (type: single, direction: decrypt)
[INFO]  key: Titanium Crypto Module
[INFO]  PASS AES-128x192 (type: multiple, direction: encrypt pass 1)
[INFO]  PASS AES-128x192 (type: multiple, direction: encrypt pass 2)

[sgtcoolguy]

So, apparently it's holding onto the value from last buffer created before it, or something?

[sgtcoolguy]

Ok, narrowed it down to a simple test case:

var buffer1 = Ti.createBuffer({ value: 'One' }),
    buffer2 = Ti.createBuffer({ value: 'Two' }),
    buffer3 = Ti.createBuffer({ value: 'Three' }),
    buffer4 = Ti.createBuffer({ value: 'Four' });


Ti.API.info(buffer1.value);
Ti.API.info(buffer2.value);
Ti.API.info(buffer3.value);
Ti.API.info(buffer4.value);

6.0.0 prints "Four" four times. 5.4.x prints correctly. I have a theory as to why, I'll see if I can come up with a fix now.

[sgtcoolguy]

Ugh, so that's a dead-end. Odd that it behaves differently in that use case, but irrelevant for this, since value is a "normal" property and the module actually calls for the underlying byte[] in Java. Also, printing toString() on each buffer gives us the expected buffer contents.

So I guess there's a bug here with the V8 update in that "normal" JS properties are getting shared across instances of the same type (weird).

Still trying to figure this one out. Thought it was an issue of aggressive GC moving the JS objects around and our pointers getting stale in C++, but that's not the case.

[sgtcoolguy]

Still working on this...

The issue of the value being shared across instances is the root cause, as the two text areas stomp over each other and the encryption input value becomes empty, leading to the issue.

So I'm trying to debug just where we're falling down in terms of setting the generic JS properties. It's really freaking hard to get useful debug statements logged out for this though...

[sgtcoolguy]

Nailed it down, here's the fix: tidev/titanium-sdk#8128

[cheekiatng]

CR and FT Passed! APPROVED!