Symmetric, Asymmetric Encryption and Hashing

Symmetric encryption uses a shared secret key for encryption and decryption under the scheme. It can efficiently protect substantial data, but the communicating parties need a secure way to establish and protect that shared secret. Sending the key unprotected alongside the ciphertext defeats the intended confidentiality.

Asymmetric cryptography uses a related public/private key pair. In an appropriate encryption scheme, data encrypted for a recipient using their public key can be decrypted with their private key. The public key may be distributed widely, but its association with the intended recipient must be authenticated. A substituted public key can otherwise redirect trust to an attacker.

Practical secure communication can use asymmetric mechanisms to authenticate or establish keys and symmetric mechanisms for the bulk data. Explain the role of each rather than assuming every byte must be encrypted with a public-key operation. Digital signatures use a private signing key and a corresponding public verification key to support origin and integrity checks; signing is not simply a universal synonym for encrypting a message.

A cryptographic hash maps data to a fixed-size digest and is designed to make certain attacks computationally difficult. It is not reversible encryption with a hidden decryption key. Collisions must exist because the input space is larger than the output space; the security goal concerns the difficulty of finding useful collisions or preimages. A classroom hash-table function has a different performance purpose and need not provide cryptographic security.

A trusted file digest can help detect changed data by recomputing and comparing. If an attacker can replace both a file and its unauthenticated digest, matching values do not establish the file’s origin. The trustworthiness of the reference digest or signature matters. A checksum for accidental errors also need not resist deliberate tampering.

For password verification, store an appropriate salted password hash using a password-hashing scheme with a suitable work factor, rather than plaintext or a single fast unsalted general-purpose digest. A salt makes identical passwords less directly recognisable across records and frustrates reused precomputed tables; it need not be secret. Hashing does not make weak passwords unguessable, so online access controls and protection of the verifier still matter.

Attempt the task before opening its worked response. Record each change of state, explain the rule used, and check the result against the original requirements. Code examples labelled Python 3 use that language’s conventions; pseudocode states its own assumptions.