Hi, I’ve been exploring an experimental Android JCA-based backend for package:webcrypto, and I wanted to check whether this direction would be useful for the project before preparing any formal contribution.
I’ve built a working prototype (published on pub.dev):
https://pub.dev/packages/jc_crypto_hashing
The prototype currently:
Implements core primitives such as SHA-256/512, HMAC, and AES-GCM using Android’s Java Cryptography Architecture (JCA) via JNI
Avoids bundling native BoringSSL binaries by relying on platform-provided cryptographic providers
Includes basic benchmarking, where JCA shows noticeable performance benefits for larger inputs (while also highlighting trade-offs for smaller payloads due to JNI overhead)
My goal would be to evolve this into a backend that integrates cleanly with the existing webcrypto API, without changing developer-facing behavior. I’m particularly interested in ensuring:
Full API compatibility with existing interfaces
Maintainability and alignment with project design decisions
A gradual, reviewable contribution approach (starting small and iterating)
Before moving forward, I wanted to ask:
Would an Android-specific JCA backend be considered useful or in scope for this project?
Are there any architectural constraints, prior discussions, or concerns (e.g., portability, consistency across platforms, security expectations) that I should take into account?
If this direction is acceptable, would you prefer contributions to start with a minimal subset (e.g., hashing/HMAC) and expand incrementally?
I understand this touches core cryptographic infrastructure, so I’d be happy to align closely with maintainers’ expectations and adjust scope accordingly.
Thanks for your time, and I’d really appreciate any guidance on whether (and how) to proceed
Hi, I’ve been exploring an experimental Android JCA-based backend for package:webcrypto, and I wanted to check whether this direction would be useful for the project before preparing any formal contribution.
I’ve built a working prototype (published on pub.dev):
https://pub.dev/packages/jc_crypto_hashing
The prototype currently:
Implements core primitives such as SHA-256/512, HMAC, and AES-GCM using Android’s Java Cryptography Architecture (JCA) via JNI
Avoids bundling native BoringSSL binaries by relying on platform-provided cryptographic providers
Includes basic benchmarking, where JCA shows noticeable performance benefits for larger inputs (while also highlighting trade-offs for smaller payloads due to JNI overhead)
My goal would be to evolve this into a backend that integrates cleanly with the existing webcrypto API, without changing developer-facing behavior. I’m particularly interested in ensuring:
Full API compatibility with existing interfaces
Maintainability and alignment with project design decisions
A gradual, reviewable contribution approach (starting small and iterating)
Before moving forward, I wanted to ask:
Would an Android-specific JCA backend be considered useful or in scope for this project?
Are there any architectural constraints, prior discussions, or concerns (e.g., portability, consistency across platforms, security expectations) that I should take into account?
If this direction is acceptable, would you prefer contributions to start with a minimal subset (e.g., hashing/HMAC) and expand incrementally?
I understand this touches core cryptographic infrastructure, so I’d be happy to align closely with maintainers’ expectations and adjust scope accordingly.
Thanks for your time, and I’d really appreciate any guidance on whether (and how) to proceed