Asymmetric cryptography

A pair of keys with different responsibilities

Asymmetric cryptography uses mathematically related public and private key material. Depending on the algorithm and protocol, public-key techniques can support encryption, digital signatures, or key agreement. Do not assume every public-key algorithm supports all three operations or that the operations can be safely substituted for one another.

The public part can be distributed. The private part requires protection appropriate to its purpose. Distributing a public key creates another question: how does the recipient know which person, service, or organization that key belongs to? The mathematics does not answer that identity question by itself.

A substituted key changes the recipient

Imagine a fictional consultant needs to send a confidential file to a colleague. A message supplies a public encryption key and claims it belongs to that colleague. If an attacker substituted their own key, encrypting successfully could protect the file for the attacker rather than the intended recipient.

The consultant needs an authentic way to obtain or verify the key. The precise route depends on the system: a managed directory, a certificate-based trust process, or another established verification procedure. The exercise illustrates why successful cryptographic processing is different from choosing the right party.

Digital certificates and PKI explains one approach to associating public keys with identities. Such a process also needs validation rules and a way to handle expired or no-longer-trusted credentials.

Encryption, signing, and agreement

Public-key encryption schemes allow a sender to protect information for a recipient who controls the corresponding private material. Signature schemes let a signer produce evidence that can be verified using an appropriate public key. Key-agreement schemes let participants establish shared key material according to a protocol.

A digital signature should not be taught as simply “encrypting with the private key.” That shortcut blurs the purpose and requirements of real schemes. Digital signatures develops the signing case separately.

Protocols often combine techniques. TLS 1.3, for example, specifies authentication and key-establishment behavior while protecting application traffic using negotiated symmetric cryptography. It is not accurately described as encrypting every web page directly with the server's public key.

Private-key access is a capability

Return to the consultant's organization. A signing key used for releases should not become a general-purpose secret available to every employee. The team needs to identify who may invoke signing, where the key is protected, and what happens after suspected misuse.

A private key that stays in a protected module can still be misused if an attacker gains an identity allowed to request operations. Key management therefore includes controlling use, not only preventing extraction of a key file.

A useful comparison exercise

Draw three tasks: sending a confidential report, verifying a software release, and establishing a protected connection. For each, label the intended security goal, the relevant keys, and the trust information required before accepting the result.

If your explanation gives every task the same arrows, revisit the difference between encryption, signatures, and key agreement. Continue with RSA and Elliptic-curve cryptography for algorithm families, while remembering that a maintained protocol defines how the individual primitives fit into a secure system.