What is the difference between confidentiality, authenticity, and integrity in public-key cryptography?

How the three properties differ in practice

In public-key cryptography, these terms describe different security goals. Confidentiality is about keeping content unreadable to anyone without the right private key. Authenticity is about proving who created the message or signature. Integrity is about detecting whether the message changed after it was created. A well-designed system often uses both encryption and signatures because one property does not automatically provide the others.

The distinction matters because the same key pair can support different functions, but the control objective changes. Encryption primarily protects confidentiality, while digital signatures primarily support authenticity and integrity. If you only encrypt data, you may hide it from outsiders without proving who sent it. If you only sign data, you may prove origin and tamper evidence, but the content may still be visible to intermediaries.

That separation is why public-key design is usually described in terms of purpose, not just algorithm. RSA, ECC, and related schemes can be used for encryption, key agreement, or signing, but the security property depends on how the keys and protocol are used. The practical test is simple: ask whether you are trying to hide the message, prove its origin, or detect modification.

Where public-key systems provide each property

Confidentiality is typically achieved by encrypting a message or, more commonly, a symmetric session key with the recipient’s public key. Only the matching private key can recover the protected data. The central operational requirement is custody of the private key, because if that key is exposed, the confidentiality promise collapses for any data protected with it. For a broader explanation of public-key primitives and key handling, see the Cryptography Basics Guide.

Authenticity comes from a signature or equivalent proof that only the private-key holder could have produced. The recipient verifies the signature with the corresponding public key and then decides whether the stated sender is credible. In practice, authenticity still depends on trust in the public key itself, which is why certificate validation, key distribution, and identity binding matter. If the public key is not reliably associated with the right party, the verification step can be technically correct but semantically misleading. The broader PKI context is covered in the PKI Basics Guide.

Integrity means the recipient can tell whether the content was altered after it was protected. Signatures provide this by invalidating verification when even one bit changes, and authenticated encryption modes can also provide integrity for ciphertext and, when used correctly, the decrypted plaintext. Integrity does not mean secrecy, and it does not by itself prove who authored the content. It only tells you whether the object you received matches what was originally protected.

Why the distinction matters for key management and protocol design

Public-key cryptography only delivers these assurances when the protocol matches the security goal. For example, a signature can give authenticity and integrity without confidentiality, while envelope encryption can give confidentiality without origin proof unless a signature is added. That is why real systems often combine a signed message with encrypted transport or encrypted storage. The property you get is determined by the full design, not by the mere presence of a public key.

Key management is the hidden dependency across all three properties. If private keys are exposed, authenticity can be forged, integrity checks can be bypassed with counterfeit signatures, and confidentiality can be lost for any data encrypted to that key. If public keys are swapped, authenticity fails even when the cryptography is mathematically sound. If signatures are accepted without validating the certificate chain or context, integrity may be checked against the wrong trust anchor.

That is why cryptographic hygiene includes rotation, revocation, validation, and restricted key custody, not just algorithm choice. For key lifecycle guidance, the NIST SP 800-57 Key Management recommendation is the most direct external reference for this topic. It is also why general security controls such as the PCI DSS v4.0 document library and ISO/IEC 27001:2022 Information Security Management remain relevant whenever keys, signatures, and protected data are part of an operational control set.

Risk and Threat Considerations

The main security risk is assuming one property implies the others. Attackers rarely need to break the mathematics if they can steal the private key, replace the trusted public key, or exploit weak validation in the surrounding protocol. Once the trust anchor is wrong, a system may still appear to “work” while producing false confidence.

Failure mechanism: Private-key compromise enables forgery, decryption, or both, depending on how the key was used. Public-key substitution or certificate misbinding lets a recipient verify the wrong party, which undermines authenticity even when signatures are technically valid.

Impact: The result can be silent message disclosure, accepted tampered content, fraudulent sender attribution, or a trusted communication channel that no longer deserves trust. In operational settings, the damage often shows up as an undetected trust failure rather than an obvious crypto failure.

Practitioner Guidance

What to verify: Verify that the implementation actually matches the intended property. If you need confidentiality, confirm the data is encrypted for the correct recipient and that the private key is protected. If you need authenticity or integrity, confirm the signature is validated against the correct public key and trust chain, not just checked for mathematical validity.

Decision rule: If the message must remain secret, use encryption. If the message must be attributable and tamper-evident, use signatures. If you need both, combine them deliberately rather than assuming one mechanism covers the other.

Common mistake: Treating “encrypted” as a blanket security label is the fastest way to miss an integrity or authenticity gap. Many real failures come from protecting content while failing to bind it to the right sender, the right key, or the right validation context.

Practitioner takeaway: In public-key systems, confidentiality protects reading, authenticity protects origin, and integrity protects against change, but all three rise or fall on whether the right key is used, validated, and kept secret.

Related resources from NHI Mgmt Group

• Why does the TLS handshake use both public key and symmetric key cryptography?
• Why does quantum computing create risk for current public key cryptography?
• How should security teams plan a transition from classic public key infrastructure to post-quantum cryptography without breaking existing protocols?
• What is the difference between public key cryptography and digital certificates in PKI?