Luis J. Dominguez P.
Mastodon Bluesky X YouTube

Consulting

Work

Most systems do not fail because the cipher was broken. They fail at the joins — a nonce reused under load, a signature verified after the branch that trusted it, a key that outlived the threat model written for it. That is the work: finding where the proof stops and the software starts.

Start a conversation See the research

What I do

Protocol design & review

New constructions, and old ones under new assumptions

A threat model written down in plain language, an argument for why the construction meets it, and an honest account of what it does not cover. Whether that is a key-agreement handshake, a threshold signing scheme, a commitment protocol, or a migration plan toward post-quantum primitives, the deliverable is the same: a document your engineers and your auditors can both read, that says what is proven, what is assumed, and what is merely hoped.

  • Threat model and security goals, stated before the design
  • Security argument, with the assumptions named
  • Parameter selection and the reasoning behind every number
  • The gap between the paper and what will actually ship

Implementation & code audit

Where correct cryptography goes wrong

Reading the parts of a library nobody reads. Key generation, storage and rotation; randomness and its sources; constant-time behaviour and the side channels that survive it; the error paths where verification quietly becomes optional. Findings are ranked by what an adversary would actually do first, not by what a scanner scored highest, and each one comes with the concrete conditions that trigger it.

  • Key management across its whole lifecycle, including the end
  • Randomness: sources, seeding, failure under fork and restore
  • Constant-time review, and where the compiler undid it
  • Verification and error handling — the branch that trusts too early

Privacy engineering

What a system still leaks once the encryption is right

Encryption settles who can read a payload. It settles very little about who talked to whom, how often, from where, and how that pattern survives being joined against another dataset. This is work on data minimisation, de-identification that holds up under linkage, retention that is actually enforced, and metadata — usually the part nobody budgeted for.

  • Data inventory and minimisation, with retention that is enforced
  • De-identification assessed against realistic re-identification
  • Metadata and traffic analysis exposure
  • Regulatory obligations translated into technical requirements

Advisory & training

For teams who will keep owning this after I leave

Retained advisory for teams making cryptographic decisions without a cryptographer on staff: design review as work proceeds, a second opinion before a commitment is expensive to reverse, and vendor claims read closely. Also workshops — for engineers who will maintain this, and for the people who have to decide about it without reading the maths.

  • Design review while decisions are still cheap to change
  • Vendor and third-party cryptographic claims, assessed
  • Workshops for engineering teams
  • Expert input for technical due diligence

How an engagement runs

four phases, in order
  1. 01

    Scope

    A call and a look at what exists. I say what I think the real risk is, what I would examine, and what I would not. No charge, and sometimes the answer is that you do not need me.

  2. 02

    Threat model

    Written down and agreed before any review begins. Who the adversary is, what they can do, and what counts as a failure. Most disagreements about findings are really disagreements about this.

  3. 03

    Review

    The work itself, with findings raised as they appear rather than saved for the report. Anything that needs fixing today gets said today.

  4. 04

    Report & retest

    A written report with findings, reproduction conditions and recommendations, a walkthrough with the team, and a retest of the fixes once they land.

What you end up holding

A report that survives handover

Written so that an engineer who joins in a year can still act on it: each finding with its preconditions, its consequence, and what would make it go away.

A threat model you can reuse

The document from phase two outlives the engagement. It is what you check the next design against, and what you hand the next auditor.

Findings ranked by adversary, not by scanner

Ordered by what someone attacking you would try first and what it would cost them — not by a severity number detached from your deployment.

A clear account of what was not covered

Every review has a boundary. Stating it plainly is the difference between a useful report and one that implies a guarantee nobody made.

Selected engagements

This section is empty on purpose. Client work is confidential by default, and I will not list a name or describe a result here without written permission. If you need references, ask and I will arrange them directly.

Bring me in early, or bring me in honestly

The cheapest review happens while the design is still a document. The second cheapest happens before the thing ships. After that it is incident response, which I would rather you never need.