Unable to access Google API after loading ApiWrapper

[Vinspi]

Hello, my issue is the following :
I'm creating a bean :

@Bean
    public ApiWrapper apiWrapperTestnet() {
        ApiWrapper test = ApiWrapper.ofShasta(privKey);
        log.info("[TRON_CONFIG] ApiWrapper for testnet is created");
        return test;
    }

and after creating this bean all attempt to access the google API results in

Caused by: java.security.InvalidKeyException: cannot identify XDH private key

The SSL Handshake fail, so i'm wondering if the trident lib will alter the global crypto configuration of the JVM uppon creating the ApiWrapper instance.

I'm quite sure this is the case because when i comment the '@bean' annotation to the class is not instanciate at startup all my google API calls are good.

Can you help me with that ?

[Vinspi]

I found this :

Security.removeProvider("BC");
Security.insertProviderAt(new BouncyCastleProvider(), 1);

in the SECP256K1.class file, i guess this is where the problem is because it will set the bouncyCastle provider app wide and then it will be picked up by the Google API and will not work.

It is really necessary ? How can i work around this ?

[endiaoekoe]

@Vinspi
I just walked through the past code changes.These two code change were made in version 0.6.0.which aims to fix a error on Android platform that a NoClassDefFound exception would be thrown when importing trident.jar.

Try to restore the original cryptographic provider configuration before or after the ApiWrapper is created,as below:

// Save the original cryptographic provider configuration before creating the ApiWrapper
Provider originalProvider = Security.getProvider(“BC”);
int originalProviderPosition = Security.getProviders().length + 1; 

// Create the ApiWrapper
@Bean
public ApiWrapper apiWrapperTestnet() {
    ApiWrapper test = ApiWrapper.ofShasta(privateKey);
    log.info(“[TRON_CONFIG] ApiWrapper for testnet is created”);
    // Restore the original cryptographic provider configuration after the ApiWrapper is created
    Security.removeProvider(“BC”); 
    Security.insertProviderAt(originalProvider, originalProviderPosition);  
    return test; }
}

This ensures that the global cryptographic provider configuration of the JVM is not affected when creating the ApiWrapper, thus avoiding compatibility issues with the Google API.

[Vinspi]

Yes that's exactly what i though after seeing this code so i tried to reverse the provider and it works.
So my strategy is to create an annotation and an aspect to reset the provider to bouncy castle every time i use trident.
The problem is 'What if i need to perform a trident operation and a google API opeeration ?' as i'm building an decentralized app, that problem can occur because the Provider is modified system wide and my app can access Google for User A and try to do something using trident with User B and the two are exclusive in this case.

So in order to solve that i can still use an aspect with a reentrant lock to be sure that no operations concerning Google API or trident API are performed at the same moment but at the sake of simplicity and performance.

But one last question remains, if i reset the "SUN" crypto provider will trident work as expected or does it needs BouncyCastle to be the default provider ?

Anyway, thanks for your help this is very appreciated.

[endiaoekoe]

But one last question remains, if i reset the "SUN" crypto provider will trident work as expected or does it needs BouncyCastle to be the default provider ?

per my understanding, trident needs Bouncycastle as the default provider.