48 lines
3.8 KiB
Markdown
48 lines
3.8 KiB
Markdown
# Security policy
|
||
|
||
## Reporting a vulnerability
|
||
|
||
Report privately to **security@aere.network**. Do not open a public issue for a security problem.
|
||
|
||
- We aim to acknowledge within **72 hours**.
|
||
- We will tell you whether we consider the report in scope, and why, within **7 days**.
|
||
- We will not pursue legal action against good-faith research conducted under this policy.
|
||
- Public credit on [AUDITS.md](https://aere.network/AUDITS.md) unless you ask to stay anonymous.
|
||
|
||
The canonical, always-current policy is <https://aere.network/security>, and the machine-readable
|
||
pointer is <https://aere.network/.well-known/security.txt>.
|
||
|
||
## In scope
|
||
|
||
- Consensus for AERE chain **2800**: the QBFT implementation, the post-quantum anchor certificate,
|
||
and the post-quantum layers on consensus messages.
|
||
- The post-quantum precompiles (`0x0AE1`–`0x0AE5`) and the code that dispatches to them.
|
||
- Node RPC surfaces exposed publicly.
|
||
- Solidity contracts deployed by the Foundation.
|
||
|
||
## Out of scope
|
||
|
||
- Denial of service by traffic volume against public endpoints.
|
||
- Findings that require physical access to Foundation hardware or a Foundation private key.
|
||
- Reports generated by automated scanners with no demonstrated impact on this chain.
|
||
|
||
## What we will tell you honestly
|
||
|
||
- **There has been no third-party security audit of this project.** See
|
||
[AUDITS.md](https://aere.network/AUDITS.md). Everything verified so far is us checking ourselves,
|
||
which is weaker, and we do not describe it as an audit.
|
||
- **All validators are operated by the Foundation.** The number of independent parties who would
|
||
have to agree to halt this chain is one. No amount of cryptography changes that number, and a
|
||
report pointing at the consequences of that fact is in scope and welcome.
|
||
- **The post-quantum guarantee is at anchor heights**, not on every block: from block 13,014,000,
|
||
every 32nd block (every 128th from block 17,225,968 to block 20,746,736) carries a post-quantum
|
||
certificate under the block hash (Falcon-512, and from block 17,047,600 also SLH-DSA-SHA2-128s, at
|
||
every 128th block since block 20,746,736), requiring at least seven valid seals of each scheme
|
||
since block 20,715,632, as many as the quorum of the ten validators (six from block 14,961,456, six of nine validators then); below block 24,148,752 the seals proved those validators signed the block, not that it was decided (AIP-22 erratum, 2026-10-01), and from that block a certificate that carries the quorum of one round proves the decision. Blocks between anchors carry no certificate of their own and are decided by QBFT (this sentence corrected on 2026-10-28: it said that blocks between anchors rest on ECDSA): since block 24,300,000 (AIP-22 stage 4) every vote counts only with the verified post-quantum seal of its author, and a commit still carries the ECDSA commit seal of its validator as an additional check; their headers were admitted on their ECDSA commit seals until block 25,080,000 (AIP-22 stage 5), and from it a node that does not take part in consensus admits a header between anchors on the Falcon-512 seal of its proposer alone, so the post-quantum key of one validator can serve such a node a branch up to the block before the next anchor (below block 25,080,000 that took the ECDSA keys of a quorum), and the next anchor ends it for a node that requires the seals of a quorum in its certificate (the published follower, with its seal ceiling at 1, is not such a node: for it one leaked or misused post-quantum key of a validator makes the rewrite depth unbounded, section 6.4 of the aere-node SPEC). We correct
|
||
over-claims publicly when we find them, and we have done so before.
|
||
|
||
## Fixes
|
||
|
||
When a report leads to a fix, we publish the finding, the fix, and the window during which the
|
||
issue was live, including anything we chose not to fix, and why.
|