Cloud engineering / Applied Cryptography
Applied Cryptography
Verify the original. Reject the altered.
An isolated OpenPGP exercise that encrypts and recovers a synthetic message, verifies a detached signature and rejects a modified copy. Each run uses a disposable keyring separate from personal keys and publishes only a compact verification report.
Applied Cryptography / Architecture
01 / The question
Can the evidence distinguish confidentiality from integrity?
Successful encryption alone does not show that a recipient will detect a changed message. This lab checks byte-for-byte plaintext recovery and signature verification, then introduces a deliberate modification and requires rejection.
My contributionImplemented and reran the isolated GnuPG exercise, validated positive and negative cryptographic outcomes, tested orchestration failures and narrowed the cloud key-management claims.
02 / System walkthrough
From input to evidence.
The stages of the implementation and its verification boundary.
- 01
Isolate the keyring
Create a new GnuPG home for each run, with short-lived signing and encryption test keys.
- 02
Encrypt and recover
Use the encryption subkey and compare the decrypted synthetic message with the original bytes.
- 03
Sign and verify
Create a detached signature and require GnuPG to emit a valid-signature status for the original message.
- 04
Reject modification
Change the message and require a failing verification result with a bad-signature status.
03 / Engineering decisions
Why the implementation matters.
Negative checks matter
The experiment is successful only if the original verifies and the changed message fails.
Personal keys stay separate
The runner refuses an existing home and uses an explicit disposable GnuPG directory. Test passphrases travel through stdin, not command arguments.
Cloud key management has separate evidence
The Azure Key Vault helper prints a plan only. It does not establish deployed RBAC, HSM protection or successful cloud operations.
04 / Results & interpretation
What the checks establish.
Four real GnuPG checks passed with GnuPG 2.4.8. Five offline orchestration tests also passed. Key Vault was not executed.
GnuPG execution
4 / 4 passedGnuPG 2.4.8 confirmed plaintext recovery, decryption status, a valid signature and rejection of a modified message.
Failure contracts
5 passedOffline tests check existing-directory refusal, missing executables, failed key generation, isolated command orchestration and incorrect tamper acceptance.
Azure Key Vault
Plan onlyA separate helper documents operations for an existing approved key; no new Azure calls or role grants were made.
05 / Scope & limitations
Scope & limitations.
- A functional cryptography exerciseThis is not a cryptographic audit, identity-verification service or compliance certification.
- Test keys are disposableOne-day synthetic test keys and process-memory passphrases are not a production key backup, rotation or recovery policy.
- Replay is a separate threatEncryption and signatures do not by themselves prevent replay. Nonces, timestamps and application-side replay handling would need separate design and tests.
06 / Next iteration
Where I would take it next.
The next technical priorities for this project.
Verify the cloud extension separately
In an approved vault, record the key type, version and operations; test an authorized operation and a denied unauthorized request.
Add an application trust model
Define identity binding, key distribution, rotation, revocation and recovery before applying this pattern to real data.
07 / Code & reproducibility
Explore the implementation.
Source, execution commands, verification reports and architecture are documented in the linked GitHub project.
- verify_openpgp.py — isolated execution and sanitized result report
- test_openpgp.py — offline failure-path tests
- evidence/openpgp-result.json — fresh, executed cryptographic checks
- keyvault_plan.py — plan-only extension for an existing approved Azure key
Original architecture diagrams describe the implementation and its verification boundary. They are explanatory diagrams, not screenshots of a deployed system.