Read the original article：Incompatible Encryption Algorithm Between App and Backend
Problem Description
The application fails to decrypt sensitive data received from the backend. The error occurs when the backend uses AES/CBC/PKCS7Padding, while the HarmonyOS app encrypts and decrypts using AES/GCM/NoPadding through the Crypto Kit.
Background Knowledge
- AES/GCM provides authenticated encryption (confidentiality + integrity) and is recommended by HarmonyOS for modern apps.
- AES/CBC is widely used in legacy backend systems but lacks integrity checks.
- If encryption algorithms or padding schemes differ between client and server, encrypted payloads cannot be decrypted properly, leading to errors or data loss.
Troubleshooting Process
- Checked app logs and confirmed that decryption was failing with an
InvalidCipherTextException. - Reviewed backend implementation and found it still relies on AES/CBC mode.
- Verified that the HarmonyOS client was configured with AES/GCM.
- Confirmed that mismatched algorithms and padding caused incompatibility.
Analysis Conclusion
The root cause was a mismatch in encryption schemes: HarmonyOS app used AES/GCM/NoPadding, while the backend required AES/CBC/PKCS7Padding.
Solution
- Implement a hybrid encryption strategy in the HarmonyOS app:
- Use AES/GCM for new services and features.
- Support AES/CBC only for legacy backend compatibility.
- Dynamically select the algorithm during runtime based on metadata from the server.
- Add an
"alg"field in the encrypted payload to identify the encryption scheme.
Verification Result
- Successfully decrypted data from backend when AES/CBC mode was selected.
- Verified that new endpoints supporting AES/GCM worked seamlessly.
Top comments (0)