Support Strong > 128bit Encryption for Sensitive Data Egress from Browser #1283
Comments
|
Hi! When choosing the KEM, we considered X25519 to provide strong security (i.e. > 128-bit security was not needed). Could you elaborate on the requirement for even stronger security? Switching KEMs may be challenging as BoringSSL, the cryptographic library used in Chromium, does not currently support KEMs with more bits of security (see here). Still, we're certainly interested in understanding those needs better and could evaluate the option of adding support to BoringSSL, if necessary. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently data that is egressed from the browser is encrypted and bundled in an OHTTP request payload to allow transfer in obscurity to a secure TEE for decryption/processing. Atm this implementation is hardcoded/uses a lower 128bit x25519 KEM for encryption
EVP_HPKE_DHKEM_X25519_HKDF_SHA256.The OHTTP RFC looks to allow negotiation/specification of alternative KEMs and encryption configurations. Can this APIs usage be updated/support strong > 128bit Nist supported algorithms to allow for customer compliance in regions where this is important? Ideally we can just update the default to be a strong curve/configuration but allowing negotiation or support of other algorithms would be desirable.
What about P-384 (KEM 0x11)?
The text was updated successfully, but these errors were encountered: