2.1Cryptographic techniques

When a Registered Information Security Specialist designs or reviews the cryptographic scheme for a communication infrastructure or application, simply "knowing the algorithms" is not enough. What matters is the judgment to select the optimal combination of cryptographic schemes given business constraints such as performance requirements, the safety of key distribution, and forward secrecy (protecting past communications). This section covers the respective strengths of common-key and public-key cryptography, why real communication paths combine both into "hybrid cryptography," and how the choice of key-exchange method affects long-term security—all from a decision-making perspective.

2.1.1Common-key, public-key, and hybrid cryptography

• Common-key (symmetric) cryptography uses the same key for encryption and decryption. AES is a representative example. It is computationally light and well suited to encrypting large volumes of data, but a separate secure means of distributing the key to each communication partner is required (key-management overhead is the challenge).
• Public-key (asymmetric) cryptography uses a separate public key for encryption and private key for decryption. It solves the key-distribution problem (the public key can be handed to anyone safely), but is computationally heavier and less suited to encrypting large volumes of data than common-key cryptography.
• Hybrid cryptography uses public-key cryptography to securely distribute a common key (a session key), then encrypts the actual data payload with lightweight common-key cryptography. Most real communication protocols, including TLS, adopt this combination, achieving both secure key distribution and the performance needed for bulk data processing.

2.1.2RSA and elliptic curve cryptography (ECC/ECDSA)

• RSA is a public-key cryptosystem whose security rests on the difficulty of factoring large composite numbers. It has a long track record and is widely used, but achieving equivalent security requires longer key lengths, which tends to increase computational load and certificate size.
• Elliptic curve cryptography (ECC) is a public-key cryptosystem whose security rests on the difficulty of the discrete logarithm problem over an elliptic curve. It achieves equivalent security with a shorter key length than RSA, giving it a performance advantage in resource-constrained environments such as mobile devices and IoT equipment. Its application to digital signatures is ECDSA.

2.1.3Diffie-Hellman key exchange and PFS (Perfect Forward Secrecy)

• Diffie-Hellman (DH) key exchange lets two communicating parties derive a shared secret key on the spot, using only publicly exchanged information, in a way that a third party cannot reproduce. Its distinguishing feature is that the key itself is never transmitted.
• PFS (Perfect Forward Secrecy) is the property that, even if a server's long-term private key is compromised in the future, communications recorded/intercepted in the past cannot be decrypted. PFS is achieved by using a fresh, temporary key pair for each session, via DHE (ephemeral DH) or ECDHE (ephemeral elliptic-curve DH).

Suppose a SaaS provider's security lead is reviewing the TLS configuration for an API platform that handles sensitive customer data. There are three requirements: (1) even if the server certificate's private key is compromised in the future, past intercepted/recorded traffic must not become decryptable (a regulatory requirement), (2) many IoT gateway devices (with limited compute resources) will also connect, so key length must be kept short while maintaining sufficient strength, and (3) the bulk of API request bodies must be encrypted/decrypted at high throughput. Requirement (1) is met not by static DH/RSA key exchange but by using ECDHE (ephemeral elliptic-curve DH key exchange) to achieve PFS—because a disposable key pair is generated per session, a later leak of the long-term key cannot reproduce past session keys. Requirement (2) is met by choosing ECC (ECDSA signatures) rather than RSA for the certificate's public-key algorithm, given the IoT gateways' compute constraints, achieving equivalent security with a shorter key length and lighter computation. Requirement (3) is met by establishing a session key via public-key cryptography (exchanged through ECDHE) and then encrypting the actual data payload with common-key cryptography such as AES in a hybrid configuration, combining the security of public-key cryptography with the speed of common-key cryptography. In short, the lead settles on "TLS 1.2/1.3 with ECDHE key exchange, an ECDSA certificate, and AES for the data payload"—a decision that satisfies all three requirements: performance constraints, forward secrecy, and secure key distribution. In addition, the chosen algorithms and key lengths must be selected from the recommended schemes listed in the CRYPTREC Cipher List and the SSL/TLS Cipher Suite Configuration Guidelines, and compromised legacy schemes (short-key RSA, old SSL versions, etc.) must never be used.

2.1.4Section summary

• Common-key cryptography is fast but faces key-distribution challenges; public-key cryptography solves key distribution but is slower. Hybrid cryptography, combining both, is the standard form for real communications
• RSA relies on the difficulty of factoring; ECC/ECDSA relies on the difficulty of the elliptic-curve discrete logarithm problem, with ECC achieving equivalent strength at a shorter key length
• When forward secrecy (PFS) is required, choose ECDHE/DHE (ephemeral key exchange), and periodically review cryptographic schemes to guard against compromise (危殆化)