Le Vrai
Adversarial by principle

A check has to reject the wrong thing.
And accept the right thing.

Our research pairs negative cases with valid ones. A verifier that refuses everything has proved very little.

Put the check to the test
The testing process

Scrutiny belongs
in the process.

We care about what happens when assumptions fail. Authorized adversarial testing is part of the research we pursue.

  1. Bound the question.

    Name the claim and the material being checked. Keep the test within published material or systems you have explicit permission to examine.

  2. Keep a valid control.

    Start with an example that should pass. Without it, a check that refuses everything can look reassuring while proving very little.

  3. Change one assumption.

    Alter a record, use the wrong reference, or supply a malformed value. Make the expected outcome clear before looking at the result.

  4. Compare the outcomes.

    Did the valid example still pass? Did the changed example fail for the right reason? A surprise in either direction is useful information.

  5. Make it repeatable.

    Keep the example, the expected result and the observed result together. Another person should be able to repeat the check and understand its limits.

The principle

Our research tests verification designs against malformed inputs, altered records, and invalid signatures. Valid cases matter just as much: rejecting every input is not a useful security property.

Put the principle to work

Failure is information.
So is a valid result.

A check can fail by trusting everything. It can also fail by trusting nothing. Try all three rules against the same four cases.

A sound comparison accepts the original and rejects the other three cases.

The original record

Should acceptNot run

The record and reference match. A useful check must allow this valid case.

Inspect the comparison
Calculated fingerprintRun the checks to calculate this value.
Reference supplied to the ruleRun the checks to inspect this value.

The selected rule’s result will appear here.

An edited record

Should rejectNot run

A new line, “[edited]”, is appended to your record. The reference remains unchanged.

Inspect the comparison
Calculated fingerprintRun the checks to calculate this value.
Reference supplied to the ruleRun the checks to inspect this value.

The selected rule’s result will appear here.

A different reference

Should rejectNot run

The record stays the same. One hexadecimal character in the reference is replaced.

Inspect the comparison
Calculated fingerprintRun the checks to calculate this value.
Reference supplied to the ruleRun the checks to inspect this value.

The selected rule’s result will appear here.

An incomplete reference

Should rejectNot run

One character is removed from the reference. It is no longer a complete SHA-256 value.

Inspect the comparison
Calculated fingerprintRun the checks to calculate this value.
Reference supplied to the ruleRun the checks to inspect this value.

The selected rule’s result will appear here.

This is an illustrative fingerprint test, not a security assessment of a system. The two unconditional rules are deliberately flawed. A matching fingerprint establishes consistency with a reference; it does not establish truth or who supplied that reference. Your text stays in this browser.

The boundary is part of the result.

The demonstrations here expose their own limits. A hash does not establish truth. A signature does not establish identity by itself. A chain needs an independent reference to reveal a coordinated rewrite.

Try those boundaries yourself
This website

The site, open to inspection.

Inspect this site’s security files

security.txt

Download 
Contact: mailto:security@levrai.io
Expires: 2027-11-13T00:00:00Z
Preferred-Languages: en
Policy: https://levrai.io/security/
Canonical: https://levrai.io/.well-known/security.txt
curl --fail --silent --show-error 'https://levrai.io/.well-known/security.txt'

Headers configuration

Download

The exact _headers file from this build, published as headers.txt.

/*
  Content-Security-Policy: default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self'; media-src 'self'; font-src 'self'; connect-src 'none'; base-uri 'none'; form-action 'none'; frame-ancestors 'none'
  X-Content-Type-Options: nosniff
  Referrer-Policy: no-referrer
  Permissions-Policy: camera=(), microphone=(), geolocation=()
  Cross-Origin-Opener-Policy: same-origin
curl --fail --silent --show-error 'https://levrai.io/headers.txt'

Compare the configuration with the headers returned by the site.

curl --head --fail --silent --show-error 'https://levrai.io/'
Found something?

Let’s examine it.

security@levrai.io

Use “Security report” in your subject line. Start with a description; avoid sending sensitive data in your first message.

Read security.txt

Make it reproducible.

Include the affected page or material, the steps to reproduce the issue, and the impact you observed. A minimal example helps us investigate.

Keep the scope clear.

Research only material we publish or systems you have explicit permission to test. Avoid harm, disruption, other people’s data, and third-party systems.

Coordinate disclosure.

Give us a reasonable opportunity to investigate before public disclosure. We welcome clear, good-faith reports.