I would like to use this thread to discuss a possible replacement for
If you currently use
This is not intended as a final polished release post yet. It is a work-in-progress beta thread and a proposal for how these problems could be addressed.
What I am trying to solve
This project currently has two goals:
Current status of this beta:
Why I think iRSA should be replaced
The old
The reasons are both practical and technical:
There is also a maintenance concern behind this:
And there is a platform API concern as well:
While working on this beta I also built a dedicated B4i test suite and boundary investigation. That confirmed an important point:
Why I am starting with a B4XLib
At this stage I intentionally want to publish this as a
There are two reasons for that:
The second point matters more than it might seem:
So one practical goal of this project is not only to replace an outdated RSA API, but also to move away from a fragile legacy
There is also an important architectural point from the B4X forum:
For this beta that leads me to a simple conclusion:
What this beta currently provides
Right now the beta contains two facades:
Legacy API compatibility
My first goal was to preserve the old four-method API shape:
That means existing code using:
can potentially be moved to the new library without first rewriting the public call shape.
Limits of the old API and why I still think a new API is needed
The legacy API remains available because compatibility matters. But it should also be clear why it is not ideal as the future-facing API:
That is exactly why this beta also introduces a cleaner API.
Modern API example
The idea is simple:
Current scope of version 0.5 Beta
This beta is intentionally limited:
Important note about compatibility claims
The goal is backward compatibility of the public API and practical migration support.
However, based on both the forum history and the current boundary tests,
So the current proposal is to keep the old surface where that helps users, while also documenting where the old library itself has technical limits.
Relevant background threads
Attachments for beta testing
Feedback welcome
If you would like to try this beta on B4i, I would especially appreciate:
iRSA on B4i and to invite feedback before I continue with the next steps.If you currently use
iRSA, or if you have B4i code that depends on RSA encryption / decryption, I would be very interested in:- feedback on the API direction
- feedback on compatibility expectations
- real-world PEM test material
- beta-test feedback on B4i
This is not intended as a final polished release post yet. It is a work-in-progress beta thread and a proposal for how these problems could be addressed.
What I am trying to solve
This project currently has two goals:
- replace the outdated
iRSAlibrary for B4i - keep the old
iRSA-style API available for existing code - offer a cleaner modern API for new code
Current status of this beta:
- Platform status: B4i only for now
- State: work in progress
- Focus of this beta: explain the overall direction and illustrate the current B4i implementation
Why I think iRSA should be replaced
The old
iRSA library was useful for its time, but I no longer think it is a good foundation for new work.The reasons are both practical and technical:
iRSAitself is not an original RSA implementation. In the original B4X library thread it is explicitly described as a wrapper around the GitHub projectObjective-C-RSA.- The original B4X thread around
iRSAalready raised concerns about key size support. - In the
iRSAthread Erel explicitly stated on February 14, 2019 that the underlying library does not support 2048 / 4096-bit keys. - In later B4i RSA support discussions, users explicitly pointed out that
iRSAdoes not provide a proper signing API and is not a good cross-platform answer anymore. - The old library is also highly sensitive to PEM and key container details such as
PUBLIC KEY,RSA PUBLIC KEY,PRIVATE KEYandRSA PRIVATE KEY. - And more recently, the new B4i 10 builder and library pipeline exposed that
iRSAis also a problematic dependency operationally, not only cryptographically.
There is also a maintenance concern behind this:
- The wrapped GitHub project
ideawu/Objective-C-RSAappears to have been quiet for years. - The repository currently shows only a small commit history and no published releases.
- That does not automatically mean it is broken, but for security-sensitive code it is not a comfortable long-term basis.
And there is a platform API concern as well:
- Apple documents the old
SecKeyEncrypt/SecKeyDecryptfunctions as deprecated and points developers toSecKeyCreateEncryptedData/SecKeyCreateDecryptedData. - Apple also documents
SecKeyRawSign/SecKeyRawVerifyas deprecated in favor ofSecKeyCreateSignature/SecKeyVerifySignature. - So even before talking about RSA semantics, key sizes, or interoperability, the old Objective-C code path is built around APIs that Apple itself has moved away from.
While working on this beta I also built a dedicated B4i test suite and boundary investigation. That confirmed an important point:
the new library can be made stable on modern iOS APIs, but the old
iRSA library itself is not a fully reliable gold standard for every historical operation direction.Why I am starting with a B4XLib
At this stage I intentionally want to publish this as a
.b4xlib, even though the old library it is meant to replace was delivered as a native library.There are two reasons for that:
- from a B4X distribution perspective, source-based B4X libraries are a better fit for this kind of reusable library
- from a B4i build-pipeline perspective, the old legacy native
iRSAsetup has become increasingly awkward in the newer builder flow
The second point matters more than it might seem:
- In December 2025 there was already a report that the new hosted builder in B4i 10.00 was missing
iRSAcompletely until it was manually uploaded. - In May 2026 there was a follow-up report showing that a normal B4i app build could still work with legacy
iRSA, whileCompile To Libraryfailed becauselibtoolcould not resolve-liRSA. - There was also a larger builder discussion around long or fragile B4i build flows, where Erel explicitly suggested compiling parts of large projects as libraries.
So one practical goal of this project is not only to replace an outdated RSA API, but also to move away from a fragile legacy
.a-style dependency and toward a B4X-friendly library format.There is also an important architectural point from the B4X forum:
Erel wrote in the duplicate-b4xlib discussion that native libraries should not reference b4xlibs because this is an inherent limitation of how b4xlibs work.
For this beta that leads me to a simple conclusion:
- do not create yet another legacy native
iRSA-style wrapper as the main delivery format - deliver the reusable library itself as a
.b4xlib - keep the native iOS-specific implementation inside the project where needed, but publish the library in the format that best matches current B4X usage
What this beta currently provides
Right now the beta contains two facades:
B4XRsafor backward compatibility with the oldiRSA-style APIB4XRsa2for a clearer modern API
Legacy API compatibility
My first goal was to preserve the old four-method API shape:
B4X:
Dim rsaLegacy As B4XRsa
Dim plain() As Byte
Dim cipher() As Byte
Dim restored() As Byte
rsaLegacy.Initialize
plain = "Hello legacy RSA".GetBytes("UTF8")
cipher = rsaLegacy.EncryptWithPublicKey(plain, PublicKeyPem)
restored = rsaLegacy.DecryptWithPrivateKey(cipher, PrivateKeyPem)
Log(BytesToString(restored, 0, restored.Length, "UTF8"))That means existing code using:
EncryptWithPublicKeyDecryptWithPrivateKeyEncryptWithPrivateKeyDecryptWithPublicKey
can potentially be moved to the new library without first rewriting the public call shape.
Limits of the old API and why I still think a new API is needed
The legacy API remains available because compatibility matters. But it should also be clear why it is not ideal as the future-facing API:
EncryptWithPrivateKeyandDecryptWithPublicKeyare legacy operations with awkward semantics.- They are often confused with real signing and verification.
- The historical
iRSAbehavior is not stable enough to treat every legacy path as a normative modern contract. - The old library is also limited by key size support and format sensitivity.
That is exactly why this beta also introduces a cleaner API.
Modern API example
B4X:
Dim rsa As B4XRsa2
Dim plain() As Byte
Dim cipher() As Byte
Dim restored() As Byte
Dim signature() As Byte
Dim verified As Boolean
rsa.Initialize
plain = "Hello modern RSA".GetBytes("UTF8")
cipher = rsa.EncryptWithPublicKey(plain, PublicKeyPem)
restored = rsa.DecryptWithPrivateKey(cipher, PrivateKeyPem)
signature = rsa.Sign(plain, PrivateKeyPem)
verified = rsa.Verify(plain, signature, PublicKeyPem)
Log(BytesToString(restored, 0, restored.Length, "UTF8"))
Log("Verified = " & verified)The idea is simple:
- use
B4XRsawhen you need drop-in compatibility - use
B4XRsa2for new code
Current scope of version 0.5 Beta
This beta is intentionally limited:
- B4i only
- native implementation based on modern iOS Security APIs
- legacy compatibility facade included
- modern Encrypt / Decrypt and Sign / Verify included
- work on B4A and B4J would come later, after the B4i behavior is considered stable enough
Important note about compatibility claims
The goal is backward compatibility of the public API and practical migration support.
However, based on both the forum history and the current boundary tests,
iRSA itself should not be treated as an unrestricted reference for:- 2048 / 4096-bit coverage
- real Sign / Verify semantics
- all private/public legacy directions
So the current proposal is to keep the old surface where that helps users, while also documenting where the old library itself has technical limits.
Relevant background threads
- iRSA - RSA encryption / decryption
- RSA support in B4i
- RSA wrapper needed (B4i)
- B4X RSA Encrypt and Decrypt
- Hosted Builder in Version 10.00 is missing iRSA-Lib
- Compile To Library fails with legacy iRSA library, while normal app build works on B4i 10.00
- Hosted Builder reports Error: BUILD INTERRUPTED on a large B4i project
- How to handle duplicate b4xlib dependencies in compiled native libraries?
- Objective-C-RSA on GitHub
- Apple documentation for deprecated SecKeyEncrypt
- Apple documentation for deprecated SecKeyDecrypt
Attachments for beta testing
B4XRSA2.b4xlibB4XRSA2-b4i-beta-example.zip
Feedback welcome
If you would like to try this beta on B4i, I would especially appreciate:
- migration feedback from existing
iRSAusers - interop feedback with real PEM material
- opinions on the modern API shape before B4A / B4J are added
- beta-test feedback from anyone willing to try the attached B4i 0.5 work in progress