What is Cryptography?

Definition and scope

Cryptography is the mathematical science of transforming data to render its meaning unintelligible, prevent its undetected alteration, or prevent its unauthorized use. Those purposes correspond to different security needs. Concealing meaning addresses confidentiality; detecting alteration addresses integrity; and preventing unauthorized use addresses a broader protection goal than secrecy alone. Cryptography therefore should be understood as a set of mechanisms that can be selected and combined according to the problem an application must solve.1

The cryptographic part of a system is not limited to an algorithm. A cryptographic system includes cryptographic algorithms together with the key-management processes that support their use in an application context. The application context matters because the same mathematical operation can have different security consequences depending on how keys are created, protected, established, used, and retired.1

Core security objectives

Before choosing a cryptographic mechanism, identify the property that must be protected. Confidentiality, integrity, and authentication are related but distinct objectives. Confidentiality protects information so that an unauthorized party cannot read it even when that party can see the information’s container. Integrity protects information from unauthorized modification. Authentication verifies the identity of the source of information.2

These objectives should not be collapsed into a single label such as secure or encrypted. A design may need to keep content unreadable, detect whether it changed, and establish where it came from. The mechanisms described below address those needs in different ways. Encryption is commonly associated with confidentiality; hash functions and message authentication codes concern integrity-related checking; and digital signatures can allow a recipient to verify a data object’s origin and integrity.21

Encryption and confidentiality

Encryption is a mechanism commonly used to provide confidentiality. It transforms plaintext into ciphertext, a different form that conceals the original meaning. The corresponding reverse operation is decryption, which restores the encrypted data to its original form. In conceptual terms, encryption protects the content from being understood by an unauthorized reader who encounters the ciphertext.21

Confidentiality is not the same as authenticity. Encryption alone does not provide assurance that encrypted data is authentic. A recipient may need a separate integrity or origin-verification mechanism, or a construction that supplies those properties together, depending on the application context. The important design question is therefore not simply whether data is encrypted, but also what evidence the recipient has that the data was not altered and came from the expected source.5

Hashing and integrity checking

A hash function maps an arbitrary, variable-length bit string to a fixed-length string called a hash result. The result is a compact representation of the input for purposes defined by the surrounding security mechanism. Hashing is therefore different from encryption: the cited definition describes a variable-length-to-fixed-length mapping, whereas encryption transforms plaintext into ciphertext and has a corresponding decryption process.1

A suitable hash function may be a candidate for a security mechanism that detects accidental changes in data. That qualification is important. A plain hash is not necessarily sufficient for detecting changes made by an active wiretapper or other active attacker, because the attacker may be able to alter both the data and an unprotected value used for comparison. The evidence supports the narrower conclusion: hashing can contribute to integrity checking, but the surrounding threat model and mechanism determine what changes can actually be detected.1

Message Authentication Codes

A Message Authentication Code, or MAC, is described in the cited IETF glossary as a keyed checksum. Its primary function in that wording is data integrity rather than sender authentication. This distinction prevents a common overstatement: the word authentication in the name of the mechanism should not be read as proof that every MAC independently establishes the identity of a human, organization, or other real-world sender.1

A MAC and encryption answer different questions. Encryption is commonly used to make content unreadable and therefore addresses confidentiality. A MAC is discussed here as an integrity-oriented mechanism. Encryption alone also does not assure authenticity, so a design that requires confidentiality and an authenticity or integrity property must account for both requirements rather than assuming that one automatically supplies the other.215

Digital signatures

A digital signature is a value computed with a cryptographic algorithm and associated with a data object so that a recipient can use the signature to verify the object’s origin and integrity. It is therefore not simply another name for encryption. A signature is associated with verification of a data object, while encryption is a transformation intended to conceal the data’s original meaning.1

In the asymmetric signing flow, the signer uses a private key to create the signature. The recipient uses the matching public key to verify it. This arrangement allows recipients to perform verification with the public component while the private component is used for signature creation. The origin conclusion still depends on how the public key is associated with an identity; the signature definition itself supports origin and integrity verification, not a universal legal conclusion about non-repudiation.12

Symmetric versus asymmetric cryptography

The practical distinction is the structure and use of the keys. Symmetric cryptography uses the same key for two counterpart cryptographic operations, such as encryption and decryption. Asymmetric cryptography, also called public-key cryptography, uses a pair consisting of a public key and a private key, with a different component used for each of two counterpart operations.1

With symmetric cryptography, the parties performing the counterpart operations rely on the same key. That creates a key-distribution disadvantage: the communicating parties must keep the shared key secret when it is distributed to both parties. The algorithm can be strong while the overall arrangement remains exposed if the shared key cannot be distributed and protected appropriately.1

Asymmetric cryptography separates the public and private components. For asymmetric encryption, a sender can encrypt data with the recipient’s public key, and only the recipient’s matching private key is needed to decrypt it. For an asymmetric digital signature, the direction is different: the signer uses a private key to create the signature, and the recipient uses the matching public key to verify it.1

These categories describe key relationships, not a complete ranking of security or a recommendation for a particular algorithm. The evidence cited for this article does not compare performance, security strength, regulatory approval, or product-specific implementations. Those questions must be evaluated separately for the application and its requirements.1

Encoding and obfuscation are not encryption

Encoding represents information with a system of symbols. It is not necessarily intended to conceal meaning. Encoding can change how data is represented so that another system or process can handle it, but the representation change alone should not be described as encryption.1

Obfuscation is also not automatically encryption. The cited IETF protocol explicitly distinguishes the two when an obfuscation algorithm does not meet modern encryption standards: it avoids calling that process encryption. The practical lesson is to evaluate what a mechanism is designed and qualified to provide, rather than relying on labels such as protected, scrambled, encoded, or obfuscated.6

Why cryptography is not total system security

Cryptography is a security capability, not a guarantee of complete system security. NIST expresses the key-management risk with a safe analogy: if an adversary knows the combination, even the strongest safe provides no security against penetration. The same principle applies to cryptographic systems: poor key management may easily compromise strong algorithms.3

This is why the cryptographic system must be considered in its application context. The algorithm is only one part of the design. Keys must be handled through their lifecycle, public keys may need identity associations, and protocols and implementations must use the mechanisms in the way the application requires. Cryptography can address important properties without resolving every other security question in the surrounding system.132

• Do not treat encryption as automatic proof of authenticity.
• Do not treat a plain hash as a complete defense against active tampering.
• Do not assume that a strong algorithm compensates for weak key handling.
• Do not infer universal legal non-repudiation from the existence of a digital signature.
• Do not use this article as a complete taxonomy of algorithms or protocols, a comparison of implementation security or performance, or an exhaustive treatment of operational risks.

Enterprise implications: keys, certificates, libraries, protocols, and data protection

For an enterprise, the question is rarely just which algorithm to select. A cryptographic system combines algorithms with the key-management processes that make them usable in an application context. A review should therefore connect the desired security objective to the keys, certificates, protocols, cryptographic libraries or other implementations, and data-protection mechanisms that will carry it into operation.1

Key management covers the full lifecycle of cryptographic keys and related security parameters: generation, storage, establishment or distribution, use, and destruction. Each stage is part of the security design. For symmetric cryptography, the need to distribute a shared key while keeping it secret is an explicit disadvantage. For asymmetric cryptography, the private key must support signature creation or decryption as appropriate, while the public key may be distributed more broadly but still needs the correct identity association when identity verification is required.132

A public-key certificate can associate a public key with the identity of a person, system, or role and authenticate that association. This makes certificates relevant to decisions about how a recipient determines whose public key is being used. The certificate is not a replacement for the cryptographic operation: it supplies an identity association around a public key, while the asymmetric operation uses the corresponding public or private component for encryption, decryption, signing, or verification.21

Key establishment is another distinct decision area. NIST identifies automated protocols such as TLS and SSH as examples of protocols used for cryptographic key establishment. In an enterprise review, the protocol choice should be considered alongside the application context and the handling of the resulting keys, rather than treated as an isolated protocol-label decision.31

1. State the required objective: confidentiality, integrity, authentication, or a combination.
2. Identify where encryption, hashing, MACs, or digital signatures fit and what each mechanism does not establish.
3. Map the key lifecycle from generation through storage, establishment or distribution, use, and destruction.
4. Determine how public keys are associated with people, systems, or roles when origin or identity verification is required.
5. Review the selected protocol, cryptographic library, and implementation in the application context rather than assuming that a mechanism’s name proves its suitability.
6. Evaluate data-protection mechanisms and operational controls without treating cryptography as a substitute for complete system security.

The NIST key-management material cited for this article identifies SP 800-57 Part 1 Revision 5 as the final recommendation and describes guidance covering algorithms, key types, protection requirements, protection methods, and key-management issues. The evidence also identifies Revision 6 as a draft; it is therefore not treated here as final guidance. This status distinction matters whenever enterprise teams turn a conceptual explanation into policy or architecture decisions.4

Conclusion

Cryptography is the mathematical foundation for transforming data to conceal meaning, detect unauthorized alteration, or prevent unauthorized use. Understanding the distinctions among confidentiality, integrity, authentication, encryption, hashing, MACs, and digital signatures prevents overclaiming what a mechanism provides. Symmetric and asymmetric cryptography also create different key-management considerations. In enterprise systems, the practical design extends beyond algorithms to lifecycle management, certificates, protocols, implementations, libraries, and data protection. The central discipline is to match each mechanism and its supporting controls to the security objective and threat being addressed.1253