Breaking up BC into smaller sub-libraries

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Breaking up BC into smaller sub-libraries

Dominik Schuermann
Hi BC developers,

we are working on OpenKeychain, an OpenPGP implementation for Android
and are using Bouncy Castle as our primary crypto library.

Unfortunately, on Android versions < 5.0, which are still pretty common,
there is a limitation to allow only 64K methods per app [0]. Also, for
mobile development it makes sense to keep the app size as small as possible.

Our current BC dependency is on core, prov, and pg. We are doing
post-compilation optimization with ProGuard to strip away the huge
packages which are not used by us:
* org.bouncycastle.crypto.tls in core
* org.bouncycastle.pqc in core
* org.bouncycastle.x509 in prov

The downside of this is that ProGuard significantly increases the
compile time and makes it more error prone (as an open source project we
don't need their obfuscation techniques).

For a better long-term solution, we propose to separate the huge TLS and
PQC sub-packages into different Gradle modules and not include them in
"core".

A similar separation has been done by Google and their Play Libraries.
After some criticism [1], they split up their library into several small
sub-libraries [2].

What do you think of this proposal?

Cheers
Dominik


[0] https://developer.android.com/studio/build/multidex.html
[1]
http://jakewharton.com/play-services-is-a-monolith/
[2] https://developers.google.com/android/guides/setup


Reply | Threaded
Open this post in threaded view
|

Re: Breaking up BC into smaller sub-libraries

Dominik Schuermann
I forgot to mention:
We would volunteer to do this via a pull request on GitHub, if we can
agree on a specific separation :)

Cheers
Dominik

On 02/01/2017 11:35 PM, Dominik Schuermann wrote:

> Hi BC developers,
>
> we are working on OpenKeychain, an OpenPGP implementation for Android
> and are using Bouncy Castle as our primary crypto library.
>
> Unfortunately, on Android versions < 5.0, which are still pretty common,
> there is a limitation to allow only 64K methods per app [0]. Also, for
> mobile development it makes sense to keep the app size as small as possible.
>
> Our current BC dependency is on core, prov, and pg. We are doing
> post-compilation optimization with ProGuard to strip away the huge
> packages which are not used by us:
> * org.bouncycastle.crypto.tls in core
> * org.bouncycastle.pqc in core
> * org.bouncycastle.x509 in prov
>
> The downside of this is that ProGuard significantly increases the
> compile time and makes it more error prone (as an open source project we
> don't need their obfuscation techniques).
>
> For a better long-term solution, we propose to separate the huge TLS and
> PQC sub-packages into different Gradle modules and not include them in
> "core".
>
> A similar separation has been done by Google and their Play Libraries.
> After some criticism [1], they split up their library into several small
> sub-libraries [2].
>
> What do you think of this proposal?
>
> Cheers
> Dominik
>
>
> [0] https://developer.android.com/studio/build/multidex.html
> [1]
> http://jakewharton.com/play-services-is-a-monolith/
> [2] https://developers.google.com/android/guides/setup
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Breaking up BC into smaller sub-libraries

David Hook
In reply to this post by Dominik Schuermann

Funny you should say that...

Okay org.bouncycastle.crypto.tls and org.bouncycastle.x509 are slowly
getting removed - the tls library is now being distributed in a separate
jar (bctls-*).

The pqc package is a bit tricky - a provider shouldn't to call out to an
external jar so pulling out the pqc provider would require a substantial
amount of code duplication.

That said, you should just be able to remove the packages from the
source without affecting anything - there may still be some hang overs
though (as in classes in x509 or tls might still be getting used in some
places), if there are let me know and we'll get them removed.

Regards,

David

On 02/02/17 09:35, Dominik Schuermann wrote:

> Hi BC developers,
>
> we are working on OpenKeychain, an OpenPGP implementation for Android
> and are using Bouncy Castle as our primary crypto library.
>
> Unfortunately, on Android versions < 5.0, which are still pretty common,
> there is a limitation to allow only 64K methods per app [0]. Also, for
> mobile development it makes sense to keep the app size as small as possible.
>
> Our current BC dependency is on core, prov, and pg. We are doing
> post-compilation optimization with ProGuard to strip away the huge
> packages which are not used by us:
> * org.bouncycastle.crypto.tls in core
> * org.bouncycastle.pqc in core
> * org.bouncycastle.x509 in prov
>
> The downside of this is that ProGuard significantly increases the
> compile time and makes it more error prone (as an open source project we
> don't need their obfuscation techniques).
>
> For a better long-term solution, we propose to separate the huge TLS and
> PQC sub-packages into different Gradle modules and not include them in
> "core".
>
> A similar separation has been done by Google and their Play Libraries.
> After some criticism [1], they split up their library into several small
> sub-libraries [2].
>
> What do you think of this proposal?
>
> Cheers
> Dominik
>
>
> [0] https://developer.android.com/studio/build/multidex.html
> [1]
> http://jakewharton.com/play-services-is-a-monolith/
> [2] https://developers.google.com/android/guides/setup
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Breaking up BC into smaller sub-libraries

Dominik Schuermann
Hi David,

great to hear that org.bouncycastle.crypto.tls and org.bouncycastle.x509
will be moved to bctls.
If we can help getting there quicker, let us now.

Regarding removal of the specific packages: We are now doing that partly
with the TLS package to speed up the compile process [0].

Cheers
Dominik

[0]
https://github.com/open-keychain/bouncycastle/commit/0e07510b807926042faa670c41315848233f3528

On 02/02/2017 12:29 AM, [hidden email] wrote:

>
> Funny you should say that...
>
> Okay org.bouncycastle.crypto.tls and org.bouncycastle.x509 are slowly
> getting removed - the tls library is now being distributed in a separate
> jar (bctls-*).
>
> The pqc package is a bit tricky - a provider shouldn't to call out to an
> external jar so pulling out the pqc provider would require a substantial
> amount of code duplication.
>
> That said, you should just be able to remove the packages from the
> source without affecting anything - there may still be some hang overs
> though (as in classes in x509 or tls might still be getting used in some
> places), if there are let me know and we'll get them removed.
>
> Regards,
>
> David
>
> On 02/02/17 09:35, Dominik Schuermann wrote:
>> Hi BC developers,
>>
>> we are working on OpenKeychain, an OpenPGP implementation for Android
>> and are using Bouncy Castle as our primary crypto library.
>>
>> Unfortunately, on Android versions < 5.0, which are still pretty common,
>> there is a limitation to allow only 64K methods per app [0]. Also, for
>> mobile development it makes sense to keep the app size as small as possible.
>>
>> Our current BC dependency is on core, prov, and pg. We are doing
>> post-compilation optimization with ProGuard to strip away the huge
>> packages which are not used by us:
>> * org.bouncycastle.crypto.tls in core
>> * org.bouncycastle.pqc in core
>> * org.bouncycastle.x509 in prov
>>
>> The downside of this is that ProGuard significantly increases the
>> compile time and makes it more error prone (as an open source project we
>> don't need their obfuscation techniques).
>>
>> For a better long-term solution, we propose to separate the huge TLS and
>> PQC sub-packages into different Gradle modules and not include them in
>> "core".
>>
>> A similar separation has been done by Google and their Play Libraries.
>> After some criticism [1], they split up their library into several small
>> sub-libraries [2].
>>
>> What do you think of this proposal?
>>
>> Cheers
>> Dominik
>>
>>
>> [0] https://developer.android.com/studio/build/multidex.html
>> [1]
>> http://jakewharton.com/play-services-is-a-monolith/
>> [2] https://developers.google.com/android/guides/setup
>>
>>
>>
>
>
>