Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better spongyCastle initialisation / decoupling #22

Open
ligi opened this issue Jan 29, 2018 · 7 comments
Open

Better spongyCastle initialisation / decoupling #22

ligi opened this issue Jan 29, 2018 · 7 comments

Comments

@ligi
Copy link
Member

ligi commented Jan 29, 2018

This is a follow-up for: #21

There are now multiple of these blocks in kethereum:

    init {
        Security.insertProviderAt(org.spongycastle.jce.provider.BouncyCastleProvider(), 1)
    }

I would really like a cleaner way of initializing spongyCastle - and ideally a decoupling from sponygCastle from kethereum so it can also be used with bouncyCastle in a JVM context where the whole spongyCastle is not needed.

One Idea:

  • create a kethereum-android module that has to be included when using kethereum in combination with Android
  • inside this module there is a content-provider that initializes spongyCastle

@mirceanis what do you think?

@issueth
Copy link

issueth bot commented Jan 29, 2018

This issue now has a bounty-address via issuETH.

Your bounty-address is 9eb20a6e6af0ae23d80692dedd0457f54ccc6f9f
Watch on rinkeby
Watch on main

@mirceanis
Copy link
Member

The ContentProvider sounds like a good idea to try. Firebase does the init that way and I remember they had a few problems in the beginning.
A successful completion of this would have to account for that and avoid it.

A link to start one off: https://firebase.googleblog.com/2016/12/how-does-firebase-initialize-on-android.html

@ligi
Copy link
Member Author

ligi commented Jan 29, 2018

@ligi
Copy link
Member Author

ligi commented Jan 29, 2018

Thinking a bit longer about this: in the end this does not need to be that clean as it will get obsolete with #1 anyway ..-)
A nice small modular Kotlin crypto lib replacing *castle would be so great!

@ligi
Copy link
Member Author

ligi commented Feb 1, 2018

Was recently talking to @cketti recently and I think he is correct that the best way is not to use the providers at all but the lower bouncycastle API - so we do not need the split spongy/bouncy at all. This way we also can avoid the multiple insertProvider calls.
Perhaps when doing so we can also hide bouncycastle behind some crypto-interface so we can replace it with a pure Kotlin implementation at a later point.

@mirceanis
Copy link
Member

what do you mean by lower bouncycastle API ?

@ligi
Copy link
Member Author

ligi commented Feb 1, 2018

you can directly use the functions without going through providers. So you are sure you do not run into the problem of using varying platform implementations. Will cc you once I make the PR for it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants