Task 5.3: Describe the uses of transit secrets engine

• AA transit key of type aes256-gcm96, used with transit/sign and verify

  Incorrect

  aes256-gcm96 is a symmetric key for encryption and decryption; it does not support signing.

• BThe PKI secrets engine, with a role that issues the service a code-signing certificate

  Incorrect

  The issue endpoint returns the certificate together with its private key to the requester, so the key leaves Vault.

• CA transit key of type ed25519, used with transit/sign and transit/verify

  Correct

  Transit supports signing and verification with asymmetric key types, and keys stay in Vault unless marked exportable.

• DA transit key of type ed25519 with exportable=true, shared with the verifying services

  Incorrect

  exportable allows every key in the key ring to be exported, which takes the private key out of Vault; verification never needs it.

Transit performs cryptographic operations inside Vault: with an ed25519, ECDSA or RSA key it signs and verifies without releasing the key.

• AConvergent encryption, which shrinks repeated data blocks

  Incorrect

  Convergent encryption makes equal inputs give equal ciphertext; it does not avoid sending the data.

• BAn exportable transit key copied into the application

  Incorrect

  Exporting removes the key from Vault's sole control.

• CData key generation with transit/datakey

  Correct

  Transit returns a new high-entropy key, in plaintext and encrypted with the named key, so the application can encrypt each file locally.

• DTransit HMAC of each file

  Incorrect

  An HMAC proves integrity; it does not encrypt.

Data keys give envelope encryption: Vault protects the key, the application handles the bulk data.

• ABack the key up with transit/backup and load it with transit/restore

  Correct

  transit/backup returns a plaintext backup of every version and the HMAC key, for keys whose settings allow plaintext backups, and transit/restore loads it as a named key.

• BRead transit/keys/orders on the old cluster and write the result on the new one

  Incorrect

  That path never returns key material, so nothing usable could be written on the new cluster.

• CMove the transit mount to the new cluster with vault secrets move

  Incorrect

  secrets move relocates a mount within one cluster; it does not copy between clusters.

• DRewrap all ciphertext on the old cluster with a key from the new cluster

  Incorrect

  Rewrap re-encrypts with the latest version of the same key on the same mount; it cannot target another cluster.

Plaintext backups are possible only for keys with allow_plaintext_backup set, and the backup must be protected like the key itself; restoring to a new name first is a good way to test it.

• ARewrapping each payload with transit/rewrap

  Incorrect

  Rewrap moves ciphertext to a newer key version.

• BEncrypting each payload with transit/encrypt

  Incorrect

  Encryption hides content; an integrity check needs an HMAC or signature.

• CGenerating random bytes with transit/random for each payload

  Incorrect

  Random bytes cannot prove a payload was unchanged.

• DGenerating and verifying HMACs with transit/hmac

  Correct

  Transit generates HMACs of data and verifies them, with the HMAC key kept inside Vault.

Every transit key type also has an HMAC key, so HMACs work with existing encryption keys.

• Atransit/export/encryption-key/<key>

  Incorrect

  Export returns an exportable key's material, not fresh random bytes.

• Btransit/random

  Correct

  Transit can act as a source of random bytes.

• Ctransit/hash

  Incorrect

  Hashing returns a digest of the input, not random data.

• Dcubbyhole/random

  Incorrect

  Cubbyhole stores data; it does not generate it.

Besides encryption, transit signs, hashes, HMACs and generates random data.