QNova Client · Transfer

Secure file transfer that does not need another portal

Secure file transfer in the QNova Client moves files between colleagues over the same post-quantum tunnel the device is already connected to. Three transports share one workflow: direct transfer between users, a company drive, and QKD transfer where a key management entity is reachable. The receiver accepts before anything arrives.

What it is

The file leaves by some route. You only pick which one.

Ask five people how they sent last week contract and you will get five answers. A personal cloud link, a zip in an email, a memory stick handed across a desk, a phone. Nobody did it to be difficult. The approved route was somewhere else, behind a login they could not remember, and that was enough. You do not get to decide whether the file moves, because it is already moving. You only get to decide whether the route it took is one you can describe afterwards.

Direct transfer, inside the tunnel

This is the default. The client shows the colleagues currently connected, plus the groups your organisation defined in QS-WAN. A presence channel keeps that list current, so you are choosing from people who are actually reachable rather than from a directory that was accurate in March.

The company drive, through the same tunnel

For the files that need to sit somewhere rather than move once. Same route in, same identity, and no second login to remember on the way.

QKD transfer, where a key manager exists

For sites that already run a quantum key distribution network. It works differently enough to earn its own section further down, and it only appears when your site can actually supply the keys.

The person sending the file picks a colleague. Not a protocol, not a bucket, not a link expiry.

The mechanism

Three transports, one gesture, and a menu that tells the truth

Switch between the transports and watch the middle change while the gesture at either end stays the same. Then tell the diagram your site has no QKD keys and watch that option leave the menu rather than fail later.

The file travels inside the tunnel the device already has up.

Three transports share one workflow. Direct transfer between users runs inside the post-quantum tunnel the device already has up, and the client lists the colleagues currently reachable rather than a directory that was accurate in March. The company drive is for files that need to sit somewhere rather than move once. QKD transfer seals the file with a symmetric key and then hides that key by XOR against a one-time key drawn from the local key management entity, which puts the protection on the key rather than on the whole exchange. In every case the receiver gets a request and the transfer happens after they accept. If the site cannot supply QKD keys, the client checks first and the option is never shown.

Why this exists

Four things that go wrong without it

The approved route is the one nobody uses

A portal behind a login somebody cannot remember loses every time to a personal cloud link, and being in a hurry is the normal condition of the person sending the file.

A destination is one more thing to reset

Most secure file transfer solutions answer this by building somewhere to put the file: a server, an expiring link, another password. It works right up until it is inconvenient.

Scheduled flows are the wrong shape for a person

Secure managed file transfer software is built around batches and a queue somebody watches. That is fair for machines and wrong for one contract before lunch.

The option fails after you have chosen the file

The usual arrangement puts every transport in the menu and tells you it is unavailable once you have already committed to it.

What you get

Secure file transfer solutions usually add a destination. This removes one.

The person who runs the network wants one less service. The person who signs for it wants a route they can describe. Same three transports, read two different ways.

For the network

No second service to stand up

The transfer rides the tunnel the device already has. There is no portal to deploy, no bucket to configure and no link expiry policy to argue about.

The list is people who are actually reachable

A presence channel keeps it current, so a failed send is not the way somebody discovers a colleague is offline.

When it breaks, it says what broke

A named diagnostic in the QNova Client, not the generic red box that sends a person to the helpdesk to describe a rectangle from memory.

For the business

The route is one you can describe afterwards

That is the whole of file security that you actually control, and it is the sentence an auditor is asking you for.

Consent sits in the path of the file

The receiver gets a request and accepts before anything arrives, rather than consent living in a document about files.

It fits the network you already deployed

The QKD transport speaks a standard key manager interface, so it goes alongside a quantum key distribution network you already have rather than asking for a second one.

How it works

Three steps, and the receiver owns the second one

You pick a colleague, not a protocol

The client lists the people currently connected to the tunnel plus the groups your organisation defined. You choose a person and a file. Which transport carries it is a property of your site, not a decision you are asked to make while holding a contract.

They are asked, and nothing lands until they answer

The receiver gets a native notification and a request inside the app. The transfer starts after they accept. Files do not appear on a colleague disk because the sender decided they should, which is the difference between a transfer and a drop.

It travels inside the tunnel that is already up

No new connection is negotiated for the file. The handshake protecting it is the post-quantum one the device came up with. If something fails, the client names the failure rather than colouring a box red.

Before you start

You need the QNova Client on both machines and the tunnel up, which is the normal state. The QKD transport additionally needs a key management entity your site can reach, and if there is not one the option is simply not offered.

In detail

The QKD transport, bounded to what it actually covers

QKD

The transport, and exactly what it protects

Here is the mechanism, in order. The file is encrypted with a random symmetric key. That key is then hidden by XOR against a QKD key drawn from the local key management entity, and the key material is one-time and never reused.

What that buys is worth stating precisely, because the scope is the whole story. The protection on the key is information-theoretic. It does not rest on a computational assumption, so there is no hard maths problem underneath it that a future machine could turn out to solve. That is a claim about the key, and we would rather bound it honestly than let it spread quietly across the rest of the page.

Interface

How it reaches the key manager, and what is not finished

The client reaches the key management entity through a standard key manager interface over mutually authenticated TLS, so both ends prove who they are instead of just the server. That interface is the point of the design: it fits a QKD network you already deployed rather than asking you to stand up a second one beside it.

⛔ The key manager integration is at the integration stage, not a finished piece. It is better you read that here than discover it halfway through a pilot. And if your site cannot supply the keys, the client checks readiness first and the transport never appears in the menu.

Where this earns its place

Four mornings this changes

One contract to one colleague before lunch

They pick the person, the person accepts, the file goes inside the tunnel. Nobody opened a portal and nobody reset a password to do it.

The memory stick stops being the fallback

When the sanctioned route is the fastest one on the screen in front of them, the drawer of memory sticks stops being the path of least resistance.

A site with a quantum key network already installed

The transport speaks the standard key manager interface, so it uses what is there instead of asking for a parallel deployment.

Somebody asks how last quarter files actually moved

The answer is the transport and the acceptance, both of which happened inside the product rather than around it.

Works better with

What the transfer sits on, and what closes the other routes

Post-quantum cryptography

The handshake the file rides on. The transfer inherits it rather than negotiating anything of its own.

Data loss prevention

Which files are allowed to move at all. Transfer decides the route, this decides the permission.

USB device control

Closes the drawer of memory sticks, which is the route this one is competing with.

Secure remote access

The tunnel itself, and the presence that makes the list of reachable colleagues current.

What this does not do

The limits, because they are what make the rest believable

The key manager integration is not finished

It is at the integration stage rather than a shipped, settled piece. If the QKD transport is the reason you are reading this page, treat it as a pilot conversation and not as a checkbox, and say so early.

The information-theoretic claim covers the key, not everything

The key is hidden by XOR against one-time QKD material, and that part rests on no computational assumption. The rest of the exchange is ordinary strong cryptography. We draw the line here rather than letting the phrase drift across the page.

Observed by the gateway is not confirmed delivery

The gateway sees the transfer happen. That is not the same claim as the file having arrived complete and been written to disk at the other end, and we will not dress one up as the other.

It is not managed file transfer for machines

No scheduled batch flows, no operator queue, no retry policy for a nightly job. This is built for a person handing a file to a person. Machine-to-machine batch movement is a different product category.

Questions people ask

The ones that come up first

What is secure file transfer in the QNova Client?

It is moving a file to a colleague over the same post-quantum tunnel the device already has up. Three transports share one workflow: direct transfer between users, a company drive, and QKD transfer where a key management entity is reachable. You pick a person, they accept, and the file travels.

How is this different from other secure file transfer solutions?

Most of them build a destination: a portal, a server, an expiring link, another password. This removes the destination instead. The route is the connection the device already holds, so there is no second service to stand up and nothing extra for the sender to remember.

Is this secure managed file transfer software?

No, and it is worth being clear about it. Managed file transfer is built around scheduled flows, batches and an operator watching a queue, which is the right shape for machines. This is built for a person handing one file to one colleague.

Can somebody send me a file without my agreement?

No. The receiver gets a native notification and a request inside the app, and the transfer only happens after they accept. Consent sits in the path of the file rather than in a policy document about files.

What does the QKD transport actually protect?

The file is encrypted with a random symmetric key, and that key is hidden by XOR against a one-time key from the local key management entity. The protection on the key is information-theoretic, meaning it rests on no computational assumption. That is a claim about the key specifically, not about the whole exchange.

What if my site has no quantum key distribution network?

Then you never see the option. The client checks readiness first, and a transport your site cannot provide does not appear in the menu. That is the reverse of the usual arrangement, where the option is there and the failure arrives after you have chosen the file.

Send us a file. Then watch us refuse to deliver it until you accept.

An engineer, two machines, and as long as you need. If you run a quantum key network we will talk about where the key manager integration actually stands. It is free and there is nothing to sign.