#38 Hardening: reconcile README and security policy with simulator implementation

[Anonymous]

Originally created by: knoksen

Problem

The repository currently presents several simulated or placeholder behaviors as if they were verified production security properties.

Examples requiring reconciliation:

• the README describes a high-security I2P browser/network console and reports fixed uptime, latency, LeaseSet, and tunnel statistics;
• it labels AES-GCM/SHA-256 as “quantum-safe” and uses terms such as “military escrow” without an evidence basis;
• I2PRepository.sendMessage() logs ElGamal/AES encryption but stores a Base64 encoding of plaintext as the payload;
• generated .i2p addresses and destination hashes are local placeholder strings rather than I2P destinations;
• identity generation defaults to 1024-bit RSA and stores private key material in application data;
• key verification currently changes state after simulated log messages rather than a cryptographically verified challenge;
• SECURITY.md is the unedited template and lists unrelated supported versions.

This is primarily an accuracy, user-safety, and OpSec issue. Users must not mistake a visualization/simulator for an anonymity system or production I2P client.

Required changes

• [ ] Label the current application consistently as a simulation/prototype unless and until it integrates a real I2P router through a defined interface such as SAM or I2CP.
• [ ] Remove unsupported anonymity, uptime, latency, quantum-resistance, and production-security claims.
• [ ] Mark generated telemetry as illustrative/simulated in both UI and documentation.
• [ ] Never describe Base64 encoding as encryption.
• [ ] Replace placeholder cryptographic flows with real, reviewed protocols or label them explicitly as non-security demonstrations.
• [ ] Define secure key storage boundaries; do not persist unprotected private keys in ordinary Room/database records.
• [ ] Replace the placeholder SECURITY.md with an actual vulnerability-reporting policy and accurate supported-version table.
• [ ] Add a threat model covering IP leakage, router-console exposure, SAM/I2CP binding, WebView/browser boundaries, local logs, backups, clipboard use, and destination-key handling.
• [ ] Add tests or documentation checks that prevent simulated properties from being presented as verified operational facts.

Acceptance criteria

1. A new user can determine from the first screen and README that the current build is a simulator/prototype.
2. No UI or documentation statement implies that enabling a toggle provides I2P routing, VPN protection, anonymity, or end-to-end encryption unless the underlying behavior is implemented and tested.
3. Security claims map to primary evidence: code, tests, workflows, threat model, or release artifacts.
4. Router management interfaces and secrets are documented as loopback-only/least-privilege by default.
5. The repository security policy contains a real reporting channel, response expectations, scope, and safe-harbor language.

Relationship to portfolio work

This issue is the next hardening stage after PR [#37]. The portfolio evidence model should become the publication standard for the repository itself.