Sealed files — precisely what they will and will not guarantee
Coming
Sealing is not available yet. No certificate has ever been issued, so
it has never worked end to end, and it is not something a beta
account can do today. This section is here anyway, in full, because
what it refuses to claim is the point — and that does not change
between a feature being built and a feature shipping.
A sealed .eaqua file will be encrypted to a list of
named accounts, and once it opens for a recipient it will keep
opening — that is the design target, and the reason the feature is
not shipped is that it does not meet it yet.
The construction, which is built: content is AES-256-GCM under a
random content key; that key
is wrapped to each recipient with ECDH-ES on P-256 through
HKDF-SHA-256 and AES-256 key wrap, one stanza per recipient, with a
fresh ephemeral key for each file; the whole container is signed with
ECDSA P-256 over SHA-256, and the author's certificate — signed by
our root key — travels inside it and is verified when the file is
opened. It is the JWE ECDH-ES+A256KW / A256GCM
construction with a detached signature, in a compact binary
container.
What that will genuinely give you
Somebody who is not a named recipient will not be able to read the
file, and reading our source code will not help them, because the
decryption key is not in the application — it is on the recipient's
device. Authorship is real and tamper-evident: a modified file fails
verification, and somebody without a licence cannot produce a file
that other copies of the tool will accept.
What it will not give you, stated plainly
A legitimate recipient will be able to open the file, read it, and
write the contents out again in any form they like. No scheme that runs on the
reader's own computer can prevent that, and we do not claim one does.
And the licence check is a policy gate inside an application you are
running, so a determined local user could patch it out. Doing that
decrypts nothing they were not already addressed on, and mints
nothing other copies would accept — but it is a gate, not a wall, and
calling it a wall to an audience of engineers would be the fastest
way to lose them.
If you need a guarantee stronger than that — revocation that actually
bites, or content a licensed reader cannot extract — the decryption
has to happen somewhere the user does not control, which means a
server. We have not built that, and the container format is already
shaped for it if we ever do.
One practical warning, for when it ships
The private keys will live in the browser profile. Clearing site data
destroys them, and a sealed file addressed only to that device will
become permanently unreadable — by us as well as by you. The habit
worth forming on day one is to seal anything that matters to a second
account as well, so there is more than one way in.