Apparently i have screwed up something by installing a php library. this is the result i get from xcall crypto now

-32
CRYPT Log: DecryptBytes:
DllDate: Nov 13 2016
ChilkatVersion: 9.5.0.64
Unlock

what do i need to get crypto working again?

Not sure what to make of that. It looks like the library is being called but is failing for some cryptic reason (sorry).

In theory, from A-Shell's perspective you only need the /usr/lib/libashnet.so.1 library to be loadable. You can check its dependencies with ldd ...

The above is the -el5 version; the details may be different for the -el7, but it's not so much the details but whether you get an error.

If that doesn't reveal something, perhaps we should proceed to an actual test case, like one of the options in the CRYPTO.BP program in [908,55] perhaps?

[root@valli-prod1 /eis/vm/miame/bin]# ldd /usr/lib/libashnet.so.1
linux-gate.so.1 => (0x004a0000)
libc.so.6 => /lib/libc.so.6 (0x001ab000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00928000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00342000)
/lib/ld-linux.so.2 (0x56556000)

i installed chilkat-9.5.0-php-5.3-x86_64-linux.tar when i was trying to find a way to encrypt soap packets for irs submissions so i find it strange that the result back from a decrypt in crypto states chilkat_version in it ?

here is a simple program , it fails on the decryption portion maybe i just thought it was working correctly. probably really obvious what i messed on ?

.type tt.bas
++include ashinc:ashell.def
++include ashinc:crypto.def
map1 keybits,b,2,256
map1 src$,s,50
map1 enc$,s,90
map1 dec$,s,50
map1 status,f,6
map1 cflags,b,4

define symkey = "123E853C2E7C521FE6ECD4CA7A0601233BDC199F2230B123C1DC4DECD123BDA2"
define iv$ = "1230F2819DC38123B5BCAE35566D0123"
? tab(-1,0)
src$ = "123456789"
GOSUB ENCRYPT'SSN
? str(status)
? src$
? enc$
src$ = enc$
GOSUB DECRYPT'SSN
? STR(status)
? src$
? enc$
end
ENCRYPT'SSN:
XCALL TRIM,src$
IF keybits = 0 then keybits = 256
! src$ = src$+CHR(10)
cflags = CRYPF_SRCTEXT+CRYPF_DSTTEXT+CRYPF_KEYHEX+CRYPF_IVHEX+CRYPF_BIGENDIAN
xcall CRYPTO, CRYPTOP_ENCRYPT, status, src$, "", enc$, "base64", &
cflags, CRYPTO_CIPHER_AES,symkey, keybits, CRYPTO_MODE_CBC, CRYPTO_PAD_PKCS5,0,iv$
RETURN
DECRYPT'SSN:
XCALL TRIM,src$
IF keybits = 0 then keybits = 256
! src$ = src$+CHR(10)
cflags = CRYPF_SRCTEXT+CRYPF_DSTTEXT+CRYPF_KEYHEX+CRYPF_IVHEX+CRYPF_BIGENDIAN
xcall CRYPTO, CRYPTOP_DECRYPT, status, src$, "", enc$, "base64", &
cflags, CRYPTO_CIPHER_AES,symkey, keybits, CRYPTO_MODE_CBC, CRYPTO_PAD_PKCS5,0,iv$
RETURN

It's just a bug in the program, not in the library/installation. You need to move the "base64" parameter from the dst encoding position to the source decoding for the decrypt routine since the source for the decrypt is the base64-encoded destination of the encryption....
The -32 status (CRYPTERR_BADCRYPT) isn't providing a lot of help, other than that your encrypted source can't be decrypted as is.

thankyou , may you find a little extra in your xmas stocking this year..