Asymmetric Cryptosystems, Hashing, PKI and Digital Signatures

Public-key schemes have different capabilities. RSA has encryption and signature schemes; ECDSA signs; ECDH establishes shared material. Do not encrypt to an arbitrary signing key or treat one key pair as suitable for every operation.

Hard mathematical problems support security arguments under particular assumptions. RSA inversion is related to factoring but not generally proved equivalent to it; elliptic-curve discrete-log hardness is not the identical trapdoor construction.

The public key is intentionally public and often derivable from private material. The intended difficulty is recovering the private secret from public information, not hiding the public half from an attacker.

Public-key authentication needs a trusted binding. A certificate or verified fingerprint may help, but an attacker’s self-signed certificate is not trusted merely because its signature verifies.

Key lengths are not directly comparable across families. Common security-strength estimates place RSA-3072 and suitable 256-bit elliptic curves near 128-bit classical strength; implementation and parameter checks still matter.

RSA and conventional elliptic-curve systems are not post-quantum schemes. NIST’s ML-KEM standard is a different key-encapsulation construction; algorithm migration requires current protocol and policy guidance rather than larger RSA keys alone.

RSA key generation selects suitable primes and a public modulus n, with public exponent e and private exponent d satisfying the required relation. Validated generation includes more checks than this teaching outline.

Toy arithmetic: p = 11, q = 13, n = 143 and φ(n) = 120. Choose e = 7 and d = 103, since 7 × 103 ≡ 1 mod 120. For m = 9, c = 9^7 mod 143 = 48, and 48^103 mod 143 = 9.

This example demonstrates modular arithmetic only. Its tiny key and unencoded textbook operation provide no real security. Use a vetted scheme and implementation instead of translating the toy calculation into a production tool.

RSAES-OAEP is an encryption scheme; RSASSA-PSS is a signature scheme. They are not interchangeable, and signatures are not simply private-key encryption of a digest.

RSA PKCS#1 v1.5 encryption has serious oracle risks in vulnerable implementations. That is distinct from the status of properly implemented PKCS#1 v1.5 signatures; do not declare every v1.5 operation identically broken.

TLS 1.3 removed RSA key transport and can use RSA-PSS for appropriate certificate authentication. It does not use RSA-OAEP to transport every TLS session key.

Key-size and transition decisions depend on current security-strength targets, data lifetime and policy. Do not promise that RSA-2048 is automatically safe until a date or invent future national CA roadmaps.

DSA, ECDSA and EdDSA are signature families, not encryption algorithms. Under FIPS 186-5, DSA is retained for verification of existing signatures rather than generation of new ones.

ECDSA uses elliptic-curve arithmetic and requires correct per-message secret handling. Nonce reuse or bias can expose keys; approved deterministic generation can avoid dependence on a fresh external random value for every signature.

Ed25519 is an EdDSA signature scheme using an Edwards-curve representation related to Curve25519. X25519 is a distinct key-agreement function. The names and wire encodings must not be treated as interchangeable.

Deterministic signing does not remove the need for secure key generation, correct implementation or fault resistance. Neither an algorithm name nor a small key proves a deployment immune to side channels.

For evidence, record the actual algorithm identifier, curve, signature encoding, message representation and validation result. A system may use different algorithms for certificates, key agreement and application signatures.

Post-quantum signatures and key encapsulation are separate tasks. NIST standardised ML-DSA and SLH-DSA alongside ML-KEM in 2024; their existence does not imply every deployed protocol or document format supports them.

Preimage resistance, second-preimage resistance and collision resistance are distinct. A practical collision attack finds two matching digests; it does not automatically let an attacker create a replacement for any specified existing evidence file.

MD5 and SHA-1 have serious collision weaknesses and should not be selected as the sole new integrity mechanism. Preserve historical recorded values where relevant and add an appropriate modern digest such as SHA-256 under the laboratory’s actual procedure.

SHA-2 and SHA-3 are different families. SHA-3 is not a transparent drop-in for every signed format, protocol or validated module: algorithm identifiers, implementation support and policy matter.

A checksum is useful only with provenance. Record what bytes or container were hashed, when, by which method and where the trusted reference is retained. Matching hashes do not prove a message is true or establish a person’s identity.

HMAC combines a secret with a hash in a defined construction and avoids the naive secret-prefix length-extension problem for susceptible hashes. Use a vetted MAC, not an improvised hash concatenation.

Passwords need a suitable salted password-hashing/KDF construction with configured cost. bcrypt is cost-adjustable but not memory-hard in the same way as scrypt or Argon2id. A fast bare SHA-256 digest is unsuitable password storage.

Fuzzy or similarity hashes serve triage and clustering, not exact integrity verification. Similarity scores need content and tool interpretation; they do not replace cryptographic digests in an evidence manifest.

Verify the exact signed representation. Document formats may sign selected byte ranges, canonicalised structures or detached content, so a visible page screenshot is not necessarily the signed input.

A successful verification supports the scheme’s integrity and key-possession claim under its assumptions. Consider key compromise, automated signing and shared access before asserting a named human intended the transaction.

X.509 certificates carry a subject/public-key binding signed by an issuer. Identity assurance differs: a domain-validated server certificate does not establish a natural person’s identity or prove a business is trustworthy.

Path validation checks an appropriate trust anchor, signatures, validity, constraints, purposes and applicable policy. Application checks such as hostname matching are additional. Code signing is an extended-key-usage purpose, not simply another basic keyUsage bit.

CRLs and OCSP supply scoped certificate-status information. An OCSP “good” response does not establish every aspect of validity or even necessarily that the responder confirms issuance. Record freshness, responder authority, status and retrieval conditions.

Historical signature assessment differs from checking a certificate today. Preserve trusted timestamp evidence, relevant certificate/status material and the validation time/policy. Expiry today does not automatically invalidate a signature demonstrably made validly earlier.

Certificates and trusted timestamps support particular claims, not document truth. Legal recognition and evidentiary presumptions depend on the applicable jurisdiction and scheme. Use the final legal module for jurisdiction-specific statutory analysis.

A typical certificate-authenticated TLS 1.3 exchange combines supported key establishment, a signed transcript, a key schedule and AEAD records. PSK modes and 0-RTT have different properties; do not impose one handshake on every capture.

TLS 1.3 encrypts most handshake messages after ServerHello. A passive packet capture without appropriate secrets does not necessarily expose the certificate or signature. Traffic inspection results must reflect actual visibility.

The negotiated cipher suite does not by itself identify the authentication signature or key-agreement group. Record the relevant extensions and messages where available, and avoid transferring network TLS guarantees to application-level signed content.

Hypothetical technical example: an examiner receives a signed PDF and its associated validation records. They preserve the original, identify the signed byte ranges and revisions, verify the signature and build the appropriate certificate path.

They assess any timestamp and status evidence at the relevant time, report unsigned later changes and distinguish technical validation from the alleged signer’s consent. A green viewer badge alone is not the complete forensic report.

For a US case, use the applicable federal/state evidentiary framework; for a UK case identify the relevant legal system; for an Indian case consult the dedicated IT Act/BSA material. The technical verification remains explicit in each, without assuming equivalent legal effect.

For limits and attack models, continue to Cryptanalysis and Diffie–Hellman.