Lorne & Vale

Lorne & Vale security

Confidentiality
deserves a
head start

Your matters remain sensitive long after they close. Our architecture combines classical and post-quantum encryption to prepare your documents for what comes next.

Understand post-quantumDiscuss your security
Lorne & Vale post-quantum hallmark
A hybrid architectureX25519 + ML-KEM-1024The Lorne & Vale hallmark represents this architecture
01

Your documents
encrypted

02

Their keys
protected by two approaches

03

The audit log
verifiable through signatures

Post-quantum, explained

Think beyond
the next upload

Post-quantum describes cryptographic methods designed to resist attacks by sufficiently powerful quantum computers. They run on the devices your team already uses.

What it means for you

Protection is planned for the lifetime of the information

An identity, a negotiation, a legal strategy. The goal is to preserve the confidentiality of information whose value lasts for years.

Why prepare today?

Explore the “harvest now, decrypt later” scenario.

Today

A document sent today

A contract, an identity document, a defence strategy. You share information whose confidentiality matters long after the first exchange.

An encrypted copy could be kept

An attacker could record encrypted exchanges without being able to read them at the time.

The risk starts with the copy

Educational scenario, with no predicted arrival date. Learn more: NIST’s explanation

Hybrid protection

Two approaches
One standard of care

Content is encrypted with AES-256-GCM. To protect its key, we combine X25519, a widely studied classical approach, with ML-KEM-1024, a post-quantum approach.

Understand by changing an assumption

Educational simulation

The classical approach

X25519

A widely studied foundation

Assumed secure

The post-quantum approach

ML-KEM-1024

A different mathematical foundation

Assumed secure

Two secrets combined to protect the document key

AES-256-GCM
What if one approach were compromised?

Two approaches work together

Secrets from X25519 and ML-KEM-1024 are combined to protect the document key. The hybrid principle spreads trust across two mathematical approaches.

The states above are assumptions. They illustrate the intended property, subject to correct composition. No algorithm is attacked here and these states do not describe a live deployment.

Understand what is combined

Each document receives a random content key. AES-256-GCM encrypts the file with this key and detects changes to the ciphertext. Two mechanisms, X25519 and ML-KEM-1024, then produce two secrets. These feed an HKDF-SHA-256 derivation, whose result protects the content key.

The document is not encrypted twice with two passwords. The construction combines two approaches to protect access to its key. The intended property depends on correct composition and well-managed secrets. An independent cryptographic review of this composition remains to be completed.

Read NIST’s explanation of hybrid constructions

From your device to your firm

Follow your document
Protection at each step

Select a step to see where the file is, what happens to it and how it is protected.

Step 01

Protection begins on your device

You choose a document. The browser encrypts it before upload, using a hybrid envelope addressed to the server.

Your document at this stage

Where
Browser → server
What happens
Encryption before transfer
The protection
X25519 + ML-KEM-1024

TLS also protects the connection. The document envelope adds protection for the content being transferred.

The protected document-envelope journey. Active controls and any transition modes are specified for each deployment.

Trust leaves a record

A history
whose integrity
is verifiable

Keeping a document confidential and verifying its history are complementary jobs. Post-quantum signatures serve the second.

  1. 01

    Link the actions

    Sensitive audit events are linked through SHA-256 hashes.

  2. 02

    Sign a checkpoint

    Daily checkpoints combine ML-DSA-87, SLH-DSA and Ed25519.

  3. 03

    Verify integrity

    The iPhone app verifies the ML-DSA-87 signature. A log export and public keys support additional verification.

Verification requires firm access or an export. It concerns the signed log, not the legal accuracy of a matter’s content.

Explore the signatures
Audit verification screen in the Lorne & Vale iPhone app
Lorne & Vale iPhone app
Screenshot with fictional data

Everyday security

Advanced protection
Familiar ways to work

Cryptographic mechanisms work alongside practical controls around your data, access and decisions.

Your firm has its own space

Data is separated by firm, with permissions tied to team roles.

How it works

Access rules apply at the database. A member of one firm does not gain access to another firm’s data through their account.

View the detail

Access stays under control

Two-factor authentication, defined roles and revocable sessions support your team’s work.

How it works

The administrator manages firm access and its two-factor policy. The security pack sets out applicable rules and exceptions.

View the detail

Fewer identifiers sent to AI

Detected names, email addresses and phone numbers are replaced with tokens before a model call.

How it works

Useful context is retained and identifiers are restored from a mapping. This replacement does not guarantee anonymity of free text. Sealing of the mapping depends on deployment.

View the detail

Decisions remain human

Your team checks the prepared information and approves replies to clients.

How it works

Automatic acknowledgements use wording approved in advance. Substantive replies and decisions remain the firm’s responsibility.

View the detail

Try it on this page

Make encryption tangible

Encrypt the example text, recover it with the key, then change one byte of the result. See why altered content is rejected.

See encryption at work Real AES-256-GCM, in your browser
The encrypted result of this example Waiting

This bench runs the symmetric layer, AES-256-GCM, the one that seals every document on the platform. In the product, the key itself is established by the hybrid X25519 + ML-KEM-1024 exchange described above.

This demonstration runs real AES-256-GCM in your browser. The text stays on this page. It illustrates content encryption, not post-quantum key exchange.

The standards behind the words

Complex names
Clear roles

Three NIST post-quantum standards, published in August 2024, define the mechanisms used in this architecture.

NIST FIPS 203

ML-KEM

Protect key exchange

A mechanism designed to establish a shared secret against classical and quantum threats. Lorne & Vale uses the ML-KEM-1024 parameter set for new envelopes.

Read the standard

NIST FIPS 204

ML-DSA

Verify a signature

A post-quantum digital signature helps verify a message’s authenticity and integrity. ML-DSA-87 signs new audit checkpoints.

Read the standard

NIST FIPS 205

SLH-DSA

Diversify the foundations

A different signature family, based on hash functions. It complements ML-DSA in checkpoints to diversify the mathematical approaches.

Read the standard

These standards describe algorithms. Lorne & Vale does not hold FIPS certification, ISO 27001 certification or a SOC 2 report. Using a standardised algorithm does not certify the application.

Your questions, clearly answered

Understand it
Choose with confidence

Ask a founder a question
Do I need a quantum computer?

No. Post-quantum cryptography uses algorithms running on today’s computers and browsers. It is designed to resist certain future attack capabilities without quantum hardware for your team.

Why prepare now?

Information in a matter may remain sensitive after it closes. The “harvest now, decrypt later” scenario concerns copies collected before a new attack capability arrives. Preparing ahead addresses exchanges at the time they happen.

Is this the same as content encryption?

The roles complement one another. AES-256-GCM encrypts the file content. Hybrid X25519 + ML-KEM-1024 protects the key needed to read it. Audit signatures verify checkpoint authenticity and help detect changes.

Is the entire platform post-quantum?

The scope described covers hybrid document envelopes and audit checkpoint signatures. Sessions, other data, infrastructure connections and third-party services use their own mechanisms. Active controls and any exceptions should be reviewed for the chosen deployment.

Does the service access documents?

The server temporarily decrypts documents in memory for necessary operations, including inspection and some processing. Encryption protects transfers and storage within the stated scope. It does not remove the technical access required for these operations.

What does “category 5” mean for ML-KEM-1024?

It is a resistance category used by NIST to compare cryptographic parameters, using exhaustive search for an AES-256 key as a reference. It does not rate the application or guarantee any period of invulnerability. ML-KEM-1024 is the highest parameter set in FIPS 203.

A transparent scope

Good questions
deserve precise answers

Controls to confirm

The security pack sets out active controls, key management and any deployment transition modes. Independent cryptographic review and external penetration testing remain to be completed.

Where processing happens

Data and files are hosted with Supabase in Ireland. The application is hosted with Vercel. OpenAI processing may take place in the United States. Applicable regions and safeguards are set out in the contractual subprocessor list.

The end of retention

Destroying a key makes the affected active storage unreadable. Earlier backups follow their retention window, including when they contain wrapped keys. Deletion arrangements are documented for your firm.

The detail for your security lead

Architecture, controls and responsibilities, available point by point.

Data separation
The architecture, plainly

Six parts of the architecture to review

Every statement below can be shown in the product. Where a control is partial, the limit is written beside it.

Data separation

One firm never sees another firm’s rows

Database access rules provide the declared separation between firms. Their coverage should be checked alongside other access paths.

  • One rule per table. Every table holding client data is readable only by the members of the firm the row belongs to.
  • Tested on every release. Automated tests try to read another firm’s data on every change to the code. The release is blocked if they succeed.
  • One key per firm. The key that seals your documents and your token map opens nothing that belongs to another firm.
Authentication and access
Authentication and access

Add a second check at sign-in

Every member of the firm has two-step verification, and the firm can turn it into a rule.

  • Two steps, through an authenticator app. A one-time code from the phone, required alongside the password.
  • Required across the firm. Owners can require it of every member from the settings, without needing us.
  • Revocable sessions. Unsure about a device? Every other session is signed out in one gesture.
  • Roles, not exceptions. Owner, member: each sees what their role allows. On iPhone, Face ID locks the app as soon as it goes to the background.
Encryption and document processing
Documents

Sealed before it leaves your machine. Resealed at every step

Four stages, each with its protection stated. Open each stage to see what an attacker walks away with if that is the one that gives.

1. In your browser

The document is sealed on your own machine, before a single byte crosses the network, under two key exchanges at once: X25519, classical, and ML-KEM-1024, post-quantum.

X25519 + ML-KEM-1024Sealed before upload
2. On our servers

The envelope is opened in memory, for as long as a content inspection takes: bounded size, checked type, scripts, macros and embedded programs refused. The document is then resealed under your firm’s key.

Content inspectionResealed under the firm’s key
3. At rest

The document rests sealed under the key that belongs to your firm. One firm’s key opens nothing that belongs to another.

One key per firmStored sealed
4. Back to your team

Every download is resealed to a single-use key that your browser generates for that one transfer, then discards.

Single-use keyResealed on delivery

About the content inspection. It refuses scripts, macros and embedded programs, with one exception, on the record: the field-formatting scripts of a fillable PDF form. It does not replace your firm’s own endpoint protection.

Audit log, signatures and verification
Traceability

A log designed to reveal changes

Sensitive actions are recorded in an append-only log. Every entry carries the SHA-256 fingerprint of the one before it.

  • Chained. Altering a past entry breaks every fingerprint that follows. The rewrite becomes visible from the exact entry onwards.
  • Signed every day. The head of each firm’s chain is signed by three schemes at once: ML-DSA-87 and SLH-DSA, post-quantum, and Ed25519, classical.
  • Verified on the iPhone. The app’s Hallmark screen rebuilds the signed message and verifies the ML-DSA-87 signature on the device, rather than taking our word for it.
  • The limit. Verifying a checkpoint today needs a firm account or an export of the log. It is not yet a verification open to anyone.
Try to rewrite history Real SHA-256, computed in your browser
Document uploaded: engagement-letter.pdf
Opened by a fee earner, 09:41
Shared with the counterparty firm
Deadline recorded: limitation, 14 May
Erasure request logged
Daily checkpoint, signed ML-DSA-87 + SLH-DSA + Ed25519

Your browser calculates SHA-256 hashes for these fictional entries. The example illustrates hash chaining. It does not verify a post-quantum signature from the platform.

AI processing and identifiers
Sensitive information and the model

The model reads the situation, not the identity

Before any call to the model, the identifiers in the enquiry are replaced by tokens. Names are restored only inside your firm’s database.

  • Tokens. Names, emails, phone numbers and other identifiers are replaced before the call. The map that ties each token to its value is sealed under the firm’s key.
  • A server-side proxy. The model, at OpenAI, is reachable only from our servers. Under OpenAI’s default policy, data sent through the API is not used to train its models.
  • The conflict check stays human. The parties to check are extracted by the model and presented as such: they require verification by a person at the firm.
  • The limit. The text of the enquiry has to be read in the clear by the model for it to be triaged. Tokens are the real control at that step, and that is a different mechanism from encryption.
What your firm receives

Hello, my name is Charlotte Bennett. I am separating from my husband, Daniel Bennett, and we have two children. You can reach me on 07700 900123 or at charlotte.bennett@example.invalid.

What the model reads

Hello, my name is PERSON_1. I am separating from my husband, PERSON_2, and we have two children. You can reach me on PHONE_1 or at EMAIL_1.

Simplified representation of a fictional enquiry. The real tokens are neutral identifiers; the map is sealed under the firm’s key and is restored only inside your database.

Deletion and backups
Erasure

Two erasures, two scopes

Erasing one person and destroying a firm’s key are not the same operation. We do not present them as though they were.

One person

For an individual erasure request, the active records in scope are deleted. Backups follow the retention schedule agreed with your firm, then expire. The request is recorded in the log.

A whole firm

When a firm withdraws its workspace, the firm’s key is destroyed. Everything sealed under it becomes unreadable in active storage, immediately. Backups taken before the destruction are kept until the end of their window, then expire: erasure is complete at that point, and we do not say “erased” before.

Firm and service responsibilities
Shared responsibilities

Three parties, clear roles

Infrastructure providers

Secure the platform underneath

Supabase for the database and the files, Vercel for the application, OpenAI for the model. Physical and infrastructure security, and the certifications they publish themselves.

Lorne & Vale

Secures the application

Separation between firms, document sealing and key handling, tokens before the model, a signed log, access control, management of sub-processors and notification in the event of an incident.

Your firm

Keeps the decisions

Legal advice, the conflict check on the restored names, accepting clients, telling your clients how their data is handled, and two-step verification for your members.

Under the EU GDPR, your firm is the controller and Lorne & Vale the processor, acting on your documented instructions. The model provider acts as a sub-processor.

Security pack

Trust starts with a conversation

Let’s discuss your requirements. A founder will walk you through the architecture, the protection scope and the documents available for your firm.

What the pack contains

  • Data processing agreement (GDPR art. 28)
  • Sub-processor list, with locations
  • Retention periods
  • Data map of an inbound enquiry
  • Sample privacy wording for your clients
  • Sample enquiry brief

Sent by a founder, usually the same day. Your details are used only to send and follow up the pack. See the privacy notice.