EXERCISE 2 — Feeling the symmetric vs asymmetric speed gap
==========================================================

SETUP — make a data file and an RSA key:
  # ~5 MB of random data to encrypt
  head -c 5000000 /dev/urandom > data.bin

  # a 2048-bit RSA key pair
  openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out rsa.pem
  openssl rsa -in rsa.pem -pubout -out rsa.pub

SYMMETRIC (AES) — encrypt the whole 5 MB file, timed:
  time openssl enc -aes-256-cbc -pbkdf2 -in data.bin -out data.enc -k secret

  Typical result: real ~0.0X s — a few hundredths of a second for 5 MB.

ASYMMETRIC (RSA) — a single public-key operation:
  # RSA can only encrypt a small amount (< key size), so encrypt a tiny file
  head -c 200 /dev/urandom > small.bin
  time openssl pkeyutl -encrypt -inkey rsa.pub -pubin \
       -in small.bin -out small.enc

  Then run RSA key generation itself, which is heavier still:
  time openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out k.pem

WHAT YOU OBSERVE:
  - AES churns through MEGABYTES in a fraction of a second.
  - RSA can only handle a couple HUNDRED BYTES per operation, and key
    generation is measurably slow (and gets dramatically slower at 4096
    bits). Per byte, asymmetric is orders of magnitude more expensive.

WHY TLS USES ASYMMETRIC ONLY TO SET UP SYMMETRIC:
  - Encrypting a whole web page / video / download with RSA would be
    impractically slow and RSA can't even take large inputs directly.
  - But you can't start with AES because the two parties share no secret.
  - So TLS uses the slow asymmetric step ONCE, briefly, only to agree on
    (or transport) a fresh symmetric key, then does ALL the bulk data
    with fast AES/AEAD. Slow-but-clever setup, fast-and-simple bulk —
    the hybrid model. This exercise makes the "why" tangible: the speed
    gap is the reason.