Procurement and security reviewers look for reasons to remove a vendor, not to keep one. This page exists so you can do that quickly and honestly: plain-language facts about data handling, integrity, platform status and disclosure — and an explicit list of the things we do not claim.
What Saar's checks do
Detect corruption, then verify recovery
An SHA-256 envelope digest and an ordered stream transcript check each frame
A candidate is accepted only after it decodes back to the source bytes
Malformed input is rejected, with resource limits as part of the contract
What they are not
Integrity is not security
Not encryption
Not authentication or sender identity
Not a signature, and not a security control
Data handling
Where your data does — and does not — go.
Capacity planner
Uploads nothing
The planner runs locally in your browser. No file leaves your machine and no sample is sent to Saar.
Live comparison
At most 32 KiB, only on request
The portal comparison sends a bounded sample only when you explicitly run it. It is for a quick direction check, not a full evaluation, and no confidential data should be submitted.
Evaluation corpora
Handled under written terms
Representative data for a real evaluation is handled under data-handling and confidentiality terms agreed in writing before anything moves.
Compliance posture
Nothing bought, nothing faked.
We do not publish a certification, badge or guarantee we have not earned. Here is the honest state of the evidence a reviewer can rely on today, and the lines we hold.
Available on request
DPA, security terms and evaluation data-handling
Agreed in writing with HEOSSI before any evaluation or deployment begins.
Published
Vulnerability disclosure
security.txt with security, abuse and incident mailboxes, all monitored.
Not claimed
Certifications, SLAs and uptime guarantees
No SOC 2, ISO 27001 or other certification is claimed, and no SLA is offered on the public site.
Post-quantum cryptography
QNSI-provided, live and independently verified.
Post-quantum cryptography uses classical implementations of algorithms designed to resist quantum attacks. It is not quantum hardware, and it is separate from the optional quantum-assisted compression optimizer. The algorithms below passed the complete production verification record on 15 October 2026.
FIPS 203
ML-KEM-1024
Key encapsulation
FIPS 204
ML-DSA-87
Digital signatures
FIPS 205
SLH-DSA-SHAKE-256f
Digital signatures
Status: live and independently verified
Provisioned, live and independently verified on 15 October 2026. Engineering verification against the live Saar product binding, not a third-party audit or certification.
Verified evidence: ML-DSA-87 signatures independently verified with liboqs; tampering rejected; SLH-DSA-SHAKE-256f signatures independently verified with liboqs; tampering rejected; ML-KEM-1024 wrap/unwrap produced byte-identical output; All four active Saar keys independently confirmed in the private KMS database; Export and deletion denied with HTTP 403; Exposed internal KMS credential rotated; the previous credential was rejected; KMS health HTTP 200; no temporary verification tasks remaining.
Saar uses its dedicated service identity and product binding. No customer QNSI login or tenant credential is required.
Integrity is separate from cryptography
Saar's SHA-256 envelope digest and stream transcript detect corruption. They are not encryption and not authentication. Post-quantum cryptography is a distinct capability provided through QNSI; it does not change the meaning of the integrity checks.
Saar exposes an optional optimizer that proposes compression codebooks and transform schedules — a combinatorial search — which classical entropy coding then applies losslessly. It sits behind a provider interface: until an external quantum gateway is configured, a classical stand-in with the same input/output contract is used, so round-trips remain exact. No hardware-backed quantum compression result is claimed. To be explicit: this optimizer is a compression search aid. It is not post-quantum cryptography.
Reviewer questions
The short answers.
Is Saar encrypted?
No. Saar's SHA-256 checks detect corruption; they are not encryption and do not authenticate the sender. Saar is not currently presented as a security control.
Where does my data go?
The capacity planner uploads nothing. The portal live comparison sends at most 32 KiB and only when you explicitly run it. Evaluation corpora are handled under terms agreed in writing. Do not submit confidential data to public tools.
Do you hold SOC 2 or ISO 27001?
Not yet, and we do not claim to. No certification, SLA or uptime guarantee is published. A data processing agreement and deeper security materials are available on request and agreed in writing.
How do I report a vulnerability?
Email saar-security@heossi.com. The disclosure policy is published at /.well-known/security.txt, with abuse and incident aliases that route to the same mailbox.
Do you support post-quantum cryptography?
Yes. QNSI-provided ML-KEM-1024 (FIPS 203), ML-DSA-87 (FIPS 204) and SLH-DSA-SHAKE-256f (FIPS 205) are provisioned, live and independently verified. These are classical implementations of algorithms designed to resist quantum attacks — not quantum hardware or third-party certification.
Which platforms are supported?
macOS and Linux for the native C SDK and CLI. Windows has a serial code path that has not completed the runtime acceptance matrix and is qualified per evaluation. No signed public artifact is published yet.
Talk to us
Request the materials a reviewer needs.
Ask for the data processing agreement, security terms or evaluation data-handling notes. Report a vulnerability at any time.