[utkrishtsahu]

Changes

Users who saved credentials with Auth0.Android 3.12.1 or older (incl. 2.x) are logged out on the first launch after updating to 3.21.1 / 3.21.2 (and 4.2.0).

Root cause. Those versions created a PKCS1-only RSA key. Since #1048, when RSADecrypt gets InvalidKeyException (Keystore INCOMPATIBLE_PADDING_MODE), it deletes the RSA and AES keys before throwing. Its only caller, tryRecoverCurrentAESKey, then runs attemptPKCS1Migration, which needs that RSA key. The key is already gone (No RSA key found for migration), so new keys are generated and the stored credentials are cleared.

The ProviderException branch has a smaller version of the same problem: deleteAESKeys() also removes the legacy IV. Credentials saved by SDK 2.x use the legacy format, so on devices that report the padding mismatch as ProviderException, the AES key migrates but the credentials can't be decrypted afterwards.

Fix (CryptoUtil.RSADecrypt only):

• InvalidKeyException | InvalidAlgorithmParameterException: no longer deletes keys; still throws CryptoException (never IncompatibleDeviceException).
• ProviderException: no longer calls deleteAESKeys(); still throws CryptoException.
• Comments and log messages updated to cover both causes (legacy PKCS1 key, MGF1 digest mismatch).

Recovery stays in tryRecoverCurrentAESKey: it tries the PKCS1 migration first, and if that fails it deletes both keys and a new key pair is generated.

Case	Before	After
Legacy PKCS1 key (2.x / ≤ 3.12.x)	Keys deleted → logged out	Migrated to OAEP, stays logged in
PKCS1 key + ProviderException, 2.x data	Legacy IV deleted → logged out	IV kept, stays logged in
OAEP key with MGF1 digest mismatch (#1016 / #1048)	Keys regenerated	Unchanged: PKCS1 attempt fails, keys regenerated (deleted one step later)
OAEP key (3.13+), fresh install	Works	Unchanged

No public API changes.

Testing

Unit tests (CryptoUtilTest)

• Updated shouldKeepKeysAndThrowCryptoExceptionOn{InvalidKeyException,InvalidAlgorithmParameterException}WhenTryingToRSADecrypt and shouldWrapProviderExceptionFromCipherInitInRSADecryptAsCryptoException to assert that RSADecrypt no longer deletes keys.
• Added tests that run the real RSADecrypt before the migration, with a KeyStore mock where a deleted key is really gone. The existing migration tests stub RSADecrypt, which is why this wasn't caught:
  • shouldMigratePKCS1KeyWhenRealRSADecryptThrowsInvalidKeyException
  • shouldMigratePKCS1KeyAndKeepLegacyIVWhenRealRSADecryptThrowsProviderException
  • shouldRegenerateKeysWithoutIncompatibleDeviceWhenMgf1DigestIsRejected (guards fix(storage): authorize MGF1 digest to prevent INCOMPATIBLE_DEVICE on…3.x #1048)
  • shouldMigratePKCS1KeyWhenEncryptIsTheFirstOperationAfterUpgrade
• Without the fix, 6 of these tests fail; the MGF1 test passes with and without it.
• ./gradlew testReleaseUnitTest lintRelease: all unit tests pass, lint 0 errors.

Device (Pixel 10, Android 17). Each run is an in-place update (adb install -r) of a sample app that uses SecureCredentialsManager, with a real login against a test tenant:

#	Scenario	Steps	Key logs	Result
1	2.10.2 → this fix	Log in on 2.10.2 (key [PKCS1Padding], legacy key_iv), update, launch	RSA key rejected … (legacy PKCS1 key or MGF1 digest mismatch) → PKCS1 migration successful → AES key re-encrypted with OAEP and stored	✅ Stays logged in; key now [OAEPPadding], key_iv kept; cold start: no migration, success
2	3.12.0 → this fix	Log in on 3.12.0 (key [PKCS1Padding]), update, launch	Same as #1	✅ Stays logged in; cold start: no migration, success
3	MGF1 mismatch (#1016) on 3.21.1 (baseline)	Recreate the RSA key with OAEP and MGF1 digest SHA-256 only, log in, getCredentials(), then log in again	INCOMPATIBLE_MGF_DIGEST → Deleting corrupted keys → New AES key generated	✅ CRYPTO_EXCEPTION, keys regenerated; second login + getCredentials() succeed
4	MGF1 mismatch on this fix	Same as #3	RSA key rejected … → Migration failed due to key access error → Deleting corrupted keys → New AES key generated	✅ Same as #3: CRYPTO_EXCEPTION (not INCOMPATIBLE_DEVICE); second login + getCredentials() succeed
5	3.21.0 (OAEP key) → this fix	Log in on 3.21.0, update, launch, cold start	No CryptoUtil logs	✅ Stays logged in, no migration, key unchanged
6	Credentials already cleared by 3.21.1 → this fix	3.12.0 log in → 3.21.1 → this fix → log in again	No CryptoUtil warnings	✅ No Credentials were previously set; new login, getCredentials() and cold start succeed
7	2.10.2 → 4.2.0 + this fix (same CryptoUtil patch applied to main)	Log in on 2.10.2 (key [PKCS1Padding], legacy key_iv), update, launch	Same as #1	✅ Stays logged in; key now [OAEPPadding], key_iv kept; cold start: no migration, success

• This change adds unit test coverage
• This change adds integration test coverage
• This change has been tested on the latest version of the platform/language or why not

Checklist

• I have read the Auth0 general contribution guidelines
• I have read the Auth0 Code of Conduct
• All existing and new tests complete without errors

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: 3a085917-242c-4e00-ad70-50f13cc07004

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}