Asymmetric encryption separates the ability to encrypt from the ability to decrypt. A recipient creates a key pair, distributes the public key, and protects the private key. Anyone with the public key can encrypt data for that recipient, but only a party able to use the matching private key can decrypt it. Unlike symmetric encryption, the sender and recipient do not need to possess the same secret key.
A practical cloud example is a partner application submitting a confidential value to a backend. The backend publishes an authenticated public key, and the partner encrypts the value locally using a supported algorithm such as RSA with OAEP padding. The backend then requests decryption through a managed key service. The partner does not need permission to use the private key or, when encrypting locally, credentials for the backend's key service. However, the partner must verify that the public key really belongs to the intended backend; substituting an attacker's public key defeats confidentiality.
In AWS Key Management Service, an application can create an asymmetric RSA KMS key with an encryption-and-decryption key usage. It can call Encrypt through AWS KMS or retrieve the public key with GetPublicKey and encrypt outside AWS. Decryption requires access to the corresponding private-key operation through AWS KMS, with authorization controlled by key policies and, where applicable, IAM policies or grants. For a KMS-generated asymmetric key, the private key remains protected within AWS KMS and cannot be downloaded.
When encrypting outside AWS KMS, the application must select a supported algorithm and preserve the key identifier and encryption algorithm alongside the ciphertext. Unlike symmetric KMS ciphertext, asymmetric ciphertext does not contain the KMS metadata needed to identify these automatically. A Decrypt request therefore needs the correct KeyId and EncryptionAlgorithm. AWS KMS encryption context is not supported for asymmetric encryption operations, so applications must not assume they can bind contextual metadata using that parameter.
Asymmetric encryption is not a practical bulk-data encryption mechanism. It is more computationally expensive than symmetric encryption and accepts only small plaintexts. For example, RSA with a 2048-bit key and OAEP using SHA-256 can encrypt at most 190 bytes per operation. A common hybrid design encrypts a file with a randomly generated symmetric data key, then encrypts that data key with the recipient's public key. The recipient decrypts the data key with its private key and uses the recovered key to decrypt the file. Use authenticated symmetric encryption, such as AES-GCM, to detect changes to the encrypted file.
Encryption and digital signatures are distinct operations, even though both use asymmetric cryptography. Encryption uses the recipient's public key to provide confidentiality; signing uses a signer's private key so others can verify authenticity and integrity with the public key. Signing is not simply encrypting with a private key, and a signature does not conceal the message. Choose a key type and permitted usage that support the intended operation rather than assuming every asymmetric key supports encryption.
Operational trade-offs include private-key access control, public-key authenticity, key replacement, request latency, and service quotas. Retain old decryption keys while ciphertext still depends on them, and distribute replacement public keys through a trusted channel. Do not assume that an asymmetric KMS key can replace a symmetric KMS key in an AWS service integration: integrations such as Amazon S3 server-side encryption with AWS KMS require symmetric encryption KMS keys. Likewise, modern TLS typically combines asymmetric authentication and key agreement with symmetric encryption for application traffic rather than encrypting every network message directly with RSA.
AWS CloudHSM