Overview
RSA-AES Hybrid encryption combines RSA-2048 for secure key exchange and AES-256-CBC for high-performance data encryption, providing both the security of asymmetric encryption and the efficiency of symmetric encryption.
Key Features
- RSA-2048 for encrypting session keys
- AES-256-CBC with 256-bit session keys for data encryption
- SHA256withRSA digital signatures for integrity verification
- Per-request session keys for forward secrecy
How It Works
RSA-AES Hybrid encryption uses a two-layer approach — asymmetric encryption for securely exchanging a temporary key, and symmetric encryption for fast bulk data encryption. Below is a step-by-step breakdown of the entire process:
1. Key Exchange (One-Time Setup)
Both parties generate their own RSA-2048 key pairs and exchange only their public keys with each other. Private keys are never shared.
- An RSA-2048 key pair is generated on the server side, and the server’s public key is shared with the client.
- An RSA-2048 key pair is generated on the client side, and the client’s public key is shared with the server.
This one-time setup establishes the trust foundation for all subsequent encrypted communication.
2. Sending an Encrypted Request (Client → Server)
When an API request is sent:
- A random session key is generated — A fresh 32-byte AES key is created for each request, ensuring every request uses a unique encryption key.
- The request data is encrypted — The JSON payload is encrypted using AES-256-CBC with the session key. The first 16 bytes of the session key serve as the IV.
- The session key is encrypted — The session key itself is encrypted using the server’s public key with RSA. Only the server can decrypt it using its private key.
- The encrypted data is signed — The encrypted data is signed using the client’s private key. This proves the request originated from the client and has not been tampered with.
- The payload is sent — The encrypted session key, encrypted data, and signature are combined into a single JSON payload and transmitted to the server.
3. Receiving an Encrypted Response (Server → Client)
When a response is sent back:
- The response is encrypted by the server using an AES session key, and the session key is encrypted with the client’s public key — ensuring only the client can decrypt it.
- The encrypted data is signed with the server’s private key — allowing the client to verify its authenticity.
- The session key is decrypted by the client using the client’s private key.
- The signature is verified using the server’s public key to confirm authenticity.
- The response data is decrypted using the decrypted session key.
This ensures that every message is confidential (only the intended recipient can read it), authenticated (signed by the sender), and integrity-protected (any tampering invalidates the signature).
Key Setup
Step 1: Generate Client RSA Key Pair
An RSA-2048 key pair must be generated on the client side. The client’s public key is to be shared with the server. The client’s private key must be kept secret and securely stored.
Step 2: Exchange Public Keys
Private keys must never be shared with anyone. Only public keys are exchanged between parties.
Algorithms & Parameters
All encrypted requests and responses use the following JSON structure:
Request Payload
Response Payload
Encryption Flow
Implementation Examples
Encrypting a Request (Client → Server)
Steps Breakdown
- Generate Session Key: 32 random bytes are generated using a secure random generator
- Extract IV: The first 16 bytes of the session key are used as the IV
- Encrypt Data: The request JSON is encrypted with AES/CBC/PKCS5Padding using the session key and IV
- Encrypt Session Key: The session key is encrypted with the server’s public key using RSA/ECB/PKCS1Padding
- Sign: The
encrypted_data string (Base64 string, as UTF-8 bytes) is signed with the client’s private key using SHA256withRSA
- Send: All three fields are combined into the JSON payload
Decrypting a Response (Server → Client)
Steps Breakdown
- Decrypt Session Key: The
encrypted_session_key is decrypted with the client’s private key using RSA/ECB/PKCS1Padding
- Verify Signature: The
signature is verified against the encrypted_data string using the server’s public key with SHA256withRSA. The response should be rejected if verification fails.
- Extract IV: The first 16 bytes of the decrypted session key are used as the IV
- Decrypt Data: The
encrypted_data is decrypted with AES/CBC/PKCS5Padding using the session key and IV
Important Notes
- All Base64 encoding uses standard Base64 (not URL-safe)
- The signature is computed over the Base64-encoded
encrypted_data string, not over the raw encrypted bytes
- The IV is derived from the session key (first 16 bytes) — it is not sent separately in the payload
- The session key is re-encrypted with the client’s public key in the response, allowing the client to decrypt it with its private key
- For POST requests, the server reuses the same AES session key from the request for encrypting the response
- For GET requests/callbacks, a new session key is generated by the server
Security Best Practices
Key Management
- Keys should be generated using cryptographically secure random number generators
- Keys must be stored securely and never logged or transmitted in plain text
- A request can be placed with the tech team to rotate keys
Implementation Guidelines
- The digital signature should always be verified before decrypting the data
- Proper error handling should be implemented to avoid information leakage
- Secure key storage mechanisms must be in place
- Private keys must never be shared or exposed