Which part of your AWS app used a post-quantum key?
Follow a sales report from its database to a supplier. Aurora and AWS Key Management Service can protect different exchanges, and each leaves different evidence.
Reading tools for text size, copying, printing and your reading list
A retailer sends its supplier a sales report. First its app reads the figures from a database. Later it sends the supplier an encrypted file. Even if both steps run in the same AWS account, the secret that protects the database connection can be entirely separate from the one that protects the file. Two October releases let developers choose post-quantum cryptography at those different points.[1][2][3][4]
Follow the file
On October 26, AWS announced support for ML-KEM in its Key Management Service (KMS). Its documentation history records the change on October 23. ML-KEM lets two parties establish a secret over a public channel using ordinary computers. The application can then use that secret to derive a key for encrypting the report.[1][3][6][7]
In this example, the supplier gives the retailer a public key. The retailer verifies whose key it is and uses it to produce a random 32-byte secret and a ciphertext that can travel to the supplier. The supplier uses the matching private key in KMS to recover the same secret. Neither party needs to send the secret itself to the other. Encrypting the file and checking who signed it are separate jobs.[1][3][7]
Trace a sales report
Which exchange does the evidence describe?
The app reads a report from a database and sends a copy to a supplier. Open each step to see who chooses the key exchange and what a reviewer could check.
1. The app connects to the database
- What Aurora offers
- A hybrid key exchange for traffic between a client and Aurora PostgreSQL 18 or later.
- Who chooses
- The database team sets the allowed groups and their order. The application needs a compatible TLS client. For version 18, the documented default list contains two classical groups.
- Evidence for this connection
- Look for the group selected in a fresh, full handshake with the relevant client. For example, X25519MLKEM768 includes a post-quantum component. X25519 alone is classical. Either can appear in a TLS 1.3 connection.
2. The app shares a secret with the supplier
- What KMS offers
- The supplier can hold an ML-KEM private key in KMS. The sender uses the corresponding public key to create a secret and an encapsulated value to send.
- Who chooses
- The application team verifies the supplier’s public key and uses it in the export workflow. The team also chooses how the resulting key material protects the file.
- Evidence for this handoff
- Match the identity of the recipient’s key to the encapsulation and recovery steps for the exchange. To establish that the file was encrypted, trace the application step that used the resulting key material.
These are examples of evidence a reviewer could request. Both exchanges are illustrated from public documentation.
Follow the database connection
On October 29, AWS announced a different option for Aurora PostgreSQL 18 and later. Here the application and the database choose how to establish a secret during their TLS handshake, when the connection opens. The database team controls which groups the server offers through a setting named ssl_groups. The client has to support a group on that list.[2][4][5]
The default list for version 18 contains two classical groups. An administrator can instead offer the hybrid X25519MLKEM768 group, which combines classical key exchange with ML-KEM. If the server prefers that group but also allows classical X25519, a compatible client can use the hybrid exchange and an older client can still connect with X25519. Both connections can report TLS 1.3.[4][5]
What would establish which path was used?
For the supplier handoff, identify the intended recipient’s key and the application operation that used it. A record of making a key available leaves open how the file was encrypted.[1][3][7]
For the database, check the key-exchange group from a fresh, full handshake with the actual client. AWS says the PostgreSQL logs report TLS version and cipher suite. Those fields alone cannot distinguish the two connections above. A client using OpenSSL can ask the library for the group selected for a session.[4][5][8]
The practical question is which exchange a piece of evidence describes. A successful KMS operation can account for how two parties obtained matching key material. A negotiated hybrid group can account for how a particular database connection began. Neither observation, by itself, establishes how an exported file or a stored database backup was protected. The retailer is an illustrative example based on the service documentation.[1][3][4][5][7]