Unit 2: Symmetric and Public Key Cryptography - Subjective Questions

Cryptographic primitives are fundamental algorithms or low-level building blocks used to construct secure communication and information-processing systems.

Major categories include:

• Symmetric encryption: Uses the same secret key for encryption and decryption. AES is a common example.
• Asymmetric encryption: Uses a public-private key pair. The public key encrypts or verifies, while the private key decrypts or signs.
• Cryptographic hash functions: Convert arbitrary-length input into a fixed-length digest. Examples include SHA-256 and SHA-3.
• Message Authentication Codes (MACs): Use a secret key to verify data integrity and authenticity. HMAC is a widely used construction.
• Digital signatures: Provide authenticity, integrity, and non-repudiation using asymmetric cryptography.
• Key-agreement algorithms: Allow parties to establish a shared secret over an insecure channel, as in Diffie–Hellman.
• Secure random-number generators: Generate unpredictable keys, initialization vectors, salts, and nonces.

Secure protocols combine these primitives into higher-level constructs such as TLS, digital certificates, cryptocurrency wallets, and blockchains.

OpenSSL is a command-line toolkit that provides implementations of cryptographic algorithms, certificate operations, and key-management functions.

Useful commands include:

• Display the installed version: openssl version
• Display detailed build information: openssl version -a
• List available commands: openssl list -commands
• List supported digest algorithms: openssl list -digest-algorithms
• List supported cipher algorithms: openssl list -cipher-algorithms
• List public-key algorithms: openssl list -public-key-algorithms
• Obtain help for a subcommand: openssl enc -help or openssl dgst -help

The exact algorithms available depend on the OpenSSL version and the loaded providers. For example, OpenSSL 3.x organizes implementations through providers such as the default and legacy providers. Users should verify the version before following command examples because some options may differ between releases.

OpenSSL uses a cryptographically secure pseudorandom number generator to produce unpredictable data.

Generating random data:

• Generate 32 random bytes in hexadecimal form: openssl rand -hex 32
• Generate 32 random bytes in Base64 form: openssl rand -base64 32
• Write 32 raw random bytes to a file: openssl rand -out key.bin 32

Random data is used for:

• Symmetric keys
• Initialization vectors
• Salts
• Nonces
• Session identifiers

Calculating a SHA-256 digest:

• Hash a file: openssl dgst -sha256 document.txt
• Hash text supplied through standard input: printf 'blockchain' | openssl dgst -sha256
• Produce a binary digest: openssl dgst -sha256 -binary document.txt -out digest.bin

SHA-256 maps an arbitrary-length message to a 256-bit value:

Digests are used to check integrity, identify data, build Merkle trees, and link blockchain blocks. A digest alone does not authenticate its source because anyone can calculate it.

AES is a symmetric block cipher standardized by NIST. It processes data in 128-bit blocks and supports keys of 128, 192, or 256 bits.

The number of rounds depends on the key length:

• AES-128: 10 rounds
• AES-192: 12 rounds
• AES-256: 14 rounds

The 128-bit input block is represented as a byte state matrix. Encryption uses the following transformations:

1. AddRoundKey: Combines the state with a round key using XOR.
2. SubBytes: Replaces each byte using a nonlinear substitution box.
3. ShiftRows: Cyclically shifts rows to spread byte positions.
4. MixColumns: Mixes bytes within each column using arithmetic over .

The initial stage performs AddRoundKey. Intermediate rounds perform all four transformations, while the final round omits MixColumns. A key schedule derives the required round keys from the original key.

AES is secure and efficient because it has a large key space, strong resistance to known practical cryptanalytic attacks when properly used, and efficient hardware and software implementations. However, AES must be combined with a secure mode, unique nonce or IV, and preferably authentication.

AES encrypts only one 128-bit block directly, so a mode of operation is required for longer messages.

• ECB: Encrypts each block independently. Identical plaintext blocks produce identical ciphertext blocks, revealing patterns. It should not be used for ordinary data encryption.
• CBC: XORs each plaintext block with the previous ciphertext block before encryption. It requires an unpredictable IV and padding. CBC provides confidentiality but not integrity, so it must be combined with a MAC using a secure construction.
• CTR: Encrypts counter values and XORs the resulting keystream with plaintext. It does not require padding and supports parallel processing. Reusing a key-counter or key-nonce pair can reveal relationships between plaintexts.
• GCM: Combines counter-mode encryption with an authentication mechanism. It provides authenticated encryption with associated data, protecting confidentiality, integrity, and authenticity.

GCM is generally preferred when supported because it provides encryption and authentication in one standardized construction. Its nonce must be unique for every encryption under the same key. A 96-bit nonce is commonly recommended. Authentication tags must be verified before decrypted plaintext is accepted.

A file can be encrypted with a password by using OpenSSL's enc command.

Encryption:

openssl enc -aes-256-cbc -salt -pbkdf2 -in plain.txt -out encrypted.bin

Decryption:

openssl enc -d -aes-256-cbc -pbkdf2 -in encrypted.bin -out recovered.txt

OpenSSL prompts for the password unless a supported password source is supplied.

• Salt: A random value combined with the password during key derivation. It ensures that the same password does not always generate the same key material and reduces the effectiveness of precomputed dictionary attacks.
• PBKDF2: A password-based key derivation function that repeatedly applies a pseudorandom function. Its computational cost slows password guessing.
• IV: The initialization vector randomizes the first CBC block. For CBC, the IV should be unpredictable and does not need to be secret.

AES-256-CBC provides confidentiality but does not inherently provide authentication. In a real application, an authenticated-encryption mode or an encrypt-then-MAC construction should be preferred. Passwords should not be included directly in shell commands because they may be exposed through shell history or process listings.

These values serve different purposes and should not be treated as interchangeable.

• Cryptographic key: A secret value that controls encryption, decryption, or MAC generation. Disclosure can reveal plaintext or permit forgery. Keys must have sufficient entropy and be protected throughout their life cycle.
• Salt: A usually non-secret random value used with passwords in a key derivation function. Reusing a salt is less catastrophic than reusing a nonce, but unique salts prevent identical passwords from producing identical derived keys and defeat precomputed tables.
• Initialization vector: An initial value required by modes such as CBC. A CBC IV should be unpredictable and normally unique. A fixed or predictable IV may leak relationships between messages.
• Nonce: A value that must generally be used only once under a given key. In CTR or GCM, nonce reuse repeats the keystream and may expose plaintext relationships; in GCM it can also enable authentication forgeries.

Keys are normally secret, whereas salts, IVs, and nonces are commonly stored or transmitted with the ciphertext. Their required properties—randomness, uniqueness, or unpredictability—depend on the algorithm and mode.

Symmetric-key cryptography uses the same secret key, or easily related secret keys, for encryption and decryption. Asymmetric cryptography uses a mathematically related public-private key pair.

Key differences are:

• Performance: Symmetric algorithms such as AES are fast and suitable for bulk data. Asymmetric algorithms are computationally more expensive.
• Key distribution: Symmetric systems require parties to establish a shared secret securely. Asymmetric systems allow public keys to be distributed openly, although their authenticity must be verified.
• Confidentiality: Symmetric encryption uses a shared key. Asymmetric encryption may encrypt data or, more commonly, protect a temporary symmetric key.
• Authentication: MACs provide shared-key authentication. Digital signatures provide publicly verifiable authentication and stronger non-repudiation properties.
• Scalability: A network of many symmetric-only users may need many pairwise keys. Public-key systems simplify key establishment.
• Applications: Symmetric cryptography protects files, disks, and communication sessions. Asymmetric cryptography supports digital signatures, certificates, key exchange, and blockchain ownership.

Modern systems are usually hybrid: public-key cryptography establishes or protects a session key, and symmetric encryption protects the actual data.

RSA is based on the difficulty of factoring a large composite integer.

Key generation:

1. Select two large distinct primes and .
2. Compute .
3. Compute , or use .
4. Choose a public exponent such that .
5. Compute the private exponent satisfying:

The public key is and the private key contains and is commonly stored with and for efficient computation.

For a properly encoded message representative , encryption is:

Decryption is:

The relation works because of modular arithmetic and Euler's theorem.

In practice, textbook RSA is insecure. RSA encryption should use OAEP padding, while signatures should use RSA-PSS. Keys must be sufficiently large, generated from secure randomness, and protected against side-channel attacks. RSA normally encrypts a random symmetric session key rather than a large message directly.

Diffie–Hellman enables two parties to establish a shared secret over a public channel.

Let be a large prime and a suitable generator. Alice selects a secret and publishes:

Bob selects a secret and publishes:

Alice calculates:

Bob calculates:

Both obtain the same value because:

The shared value is normally processed by a key derivation function instead of being used directly as an encryption key.

Unauthenticated Diffie–Hellman is vulnerable to a man-in-the-middle attack. An attacker can establish one secret with Alice and another with Bob while impersonating each party. Authentication can be added through digital signatures, certificates, or pre-shared keys. Ephemeral Diffie–Hellman uses temporary private values and can provide forward secrecy. Elliptic-curve Diffie–Hellman offers equivalent functionality with smaller keys.

Elliptic-curve cryptography uses algebraic structures formed by points on an elliptic curve over a finite field. A simplified curve equation over a prime field is:

The parameters must satisfy conditions that prevent the curve from becoming singular. Given a base point and a private scalar , the public key is:

Computing from is efficient, but recovering from and is believed to be computationally infeasible for secure curves. This is the elliptic-curve discrete logarithm problem.

Advantages include:

• Smaller keys than RSA for comparable classical security
• Lower storage and communication overhead
• Efficient signature verification and key exchange
• Suitability for mobile devices and distributed networks

Blockchain systems use elliptic curves primarily for transaction signatures and address ownership. Bitcoin historically uses the secp256k1 curve, while other platforms may use Ed25519 or different curves and signature schemes. Security depends on valid curve parameters, secure nonce generation, private-key protection, and correct public-key validation.

A cryptographic hash function maps an input of arbitrary length to a fixed-length digest:

Important properties are:

• Determinism: The same input always produces the same digest.
• Efficiency: The digest can be calculated quickly.
• Avalanche effect: A small input change should significantly change the output.
• Preimage resistance: Given a digest , it should be infeasible to find an input such that .
• Second-preimage resistance: Given a specific message , it should be infeasible to find a different message such that .
• Collision resistance: It should be infeasible to find any two distinct messages and with the same digest.

For an ideal -bit hash, generic preimage search requires approximately operations, while a collision can be found in approximately operations because of the birthday effect. Blockchain systems use hashes for block linking, transaction identifiers, Merkle trees, proof-of-work, and data-integrity checks.

HMAC is a keyed message authentication code constructed from a cryptographic hash function. It provides integrity and authentication for parties that share a secret key.

Its construction is:

Here, is the key adjusted to the hash function's block size, is the message, and ipad and opad are fixed inner and outer padding values.

Difference from an ordinary hash:

• A normal digest such as detects accidental changes only when the expected digest is obtained through a trusted channel.
• HMAC uses a secret key, so an attacker who does not know the key cannot generate a valid tag for a modified message.
• HMAC does not provide confidentiality; the message remains visible.
• Unlike a digital signature, HMAC is not publicly verifiable because every verifier must know the shared key.

OpenSSL can calculate an HMAC with a command such as openssl dgst -sha256 -hmac secret message.txt. Production systems should use securely generated keys rather than weak human-readable secrets.

A digital signature uses a private key to authenticate data and a corresponding public key to verify it.

Signing process:

1. The sender serializes the message in a defined format.
2. A cryptographic hash of the message is calculated.
3. A signature algorithm uses the private key and the digest to generate a signature.
4. The message and signature are transmitted or stored together.

Conceptually:

Verification process:

The verifier uses the public key to check:

A valid signature provides evidence of:

• Authenticity: The signer possessed the relevant private key.
• Integrity: Modification of the signed message causes verification to fail.
• Non-repudiation: The signature may provide evidence linking the key holder to the action, subject to key control and legal context.

In a blockchain transaction, the owner signs transaction data specifying how assets or state may be changed. Network nodes verify the signature using the public key before accepting the transaction. The signature does not encrypt transaction contents; it authorizes and authenticates them.

Generate an RSA private key:

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out private.pem

The private-key file should be protected with restrictive file permissions and, where appropriate, encrypted using a strong passphrase.

Extract the public key:

openssl pkey -in private.pem -pubout -out public.pem

Sign a file with SHA-256:

openssl dgst -sha256 -sign private.pem -out signature.bin document.txt

Verify the signature:

openssl dgst -sha256 -verify public.pem -signature signature.bin document.txt

If the signature matches the file and public key, OpenSSL reports successful verification. If the file, signature, or public key is changed, verification fails.

The private key must never be distributed. The public key may be shared, but users need a trusted method—such as a certificate or verified fingerprint—to confirm who owns it. For protocol design, the precise signature padding and parameters must also be specified; modern RSA signatures generally use RSA-PSS where interoperability permits.

A digital certificate binds an identity or other attributes to a public key. An X.509 certificate commonly contains:

• Subject information
• Subject public key
• Issuer information
• Serial number
• Validity period
• Signature algorithm
• Extensions such as key usage and subject alternative names
• Certification authority's digital signature

A Public Key Infrastructure includes certification authorities, registration processes, certificate repositories, trust anchors, certificate chains, expiration policies, and revocation mechanisms. A relying party validates the issuer's signature, certificate chain, validity period, intended key usage, identity constraints, and revocation status.

An X.509 certificate can be displayed with:

openssl x509 -in certificate.pem -text -noout

Its SHA-256 fingerprint can be obtained with:

openssl x509 -in certificate.pem -noout -fingerprint -sha256

A certificate can be verified against a trusted CA file with:

openssl verify -CAfile ca-certificates.pem certificate.pem

A certificate does not make a key trustworthy by itself. Trust depends on validating its chain and confirming that the certificate is appropriate for the intended identity and purpose.

Hybrid encryption combines asymmetric cryptography with efficient symmetric authenticated encryption.

A high-level scheme works as follows:

1. The sender generates a random symmetric session key and a unique nonce .
2. The message is encrypted with an authenticated-encryption algorithm such as AES-GCM:

Here, is the plaintext, is associated metadata, is the ciphertext, and is the authentication tag.

3. The sender protects using the recipient's authenticated public key, for example with RSA-OAEP or an elliptic-curve key-encapsulation method.
4. The sender transmits the encapsulated key, nonce, ciphertext, tag, and required algorithm identifiers.
5. The recipient uses the private key to recover and then verifies and decrypts the AEAD ciphertext.

This scheme provides:

• Confidentiality: Only the holder of the recipient's private key can recover the session key.
• Integrity: AEAD detects ciphertext and metadata modification.
• Recipient authentication: Encryption uses the recipient's verified public key.

If sender authentication is required, the sender must additionally sign the appropriate protocol transcript. Public keys must be authenticated to prevent key-substitution attacks.

A Merkle tree is a binary hash tree that summarizes many data items with one root hash.

For transaction leaves , leaf hashes are calculated using an unambiguous encoding, for example:

Adjacent hashes are combined recursively:

The process continues until one value, the Merkle root, remains. The root is included in the block header, thereby committing the block to its transaction set and ordering.

A Merkle proof for one transaction contains the sibling hash at each level and information indicating whether each sibling is on the left or right. The verifier:

1. Hashes the transaction to form its leaf.
2. Combines it with the supplied sibling hash.
3. Repeats the process up the tree.
4. Compares the calculated root with the trusted root in the block header.

For leaves, a balanced proof requires approximately sibling hashes. This enables efficient inclusion verification without downloading every transaction. Domain separation or clearly defined encodings should be used to avoid ambiguity between leaf and internal-node representations.

A blockchain account or spendable output is controlled according to rules connected to a public key or an identifier derived from that key.

The process generally includes:

1. A user generates a private-public key pair.
2. An address or account identifier may be derived by hashing and encoding the public key.
3. The user constructs a transaction containing recipients, amounts or state changes, fees, nonces, and other network-specific fields.
4. The transaction is serialized according to a canonical format and hashed.
5. The user signs the required transaction data with the private key.
6. The transaction, signature, and necessary public-key information are broadcast.
7. Nodes reconstruct the signed message, verify the signature, and apply consensus rules such as balance, ownership, transaction nonce, and script or smart-contract conditions.
8. The validated transaction is identified by a hash and may be included in a block and Merkle tree.

Hashing provides compact identifiers and tamper evidence. Digital signatures prove authorization by the relevant private key. Public-key cryptography allows every node to verify authorization without learning the private key. A valid signature alone does not guarantee transaction validity; all consensus and state-transition rules must also pass.

A block header typically contains information such as the previous block's hash, a Merkle root, a timestamp, consensus parameters, and a nonce. If block has header , its identifier can be represented as:

The next block records . If an earlier transaction changes, its transaction hash and Merkle root change. This changes the block header hash, so the reference stored in the next block no longer matches. Recomputing only that block is insufficient because every later reference is affected.

In proof-of-work, miners vary a nonce and sometimes other header fields until the block hash satisfies a target condition:

where is the network target. A smaller target implies greater expected computational work. Verification is fast because nodes only need to hash the proposed header and compare it with the target.

Hash linking provides tamper evidence, while proof-of-work makes rewriting confirmed history computationally expensive. Security also depends on decentralized validation, consensus rules, network participation, and the attacker's fraction of total mining power; hashing alone does not make stored data absolutely immutable.