PulseProof Sentinel Protocol, abbreviated PPS, is an experimental protocol.

It has not been independently audited.

Do not use PPS in production systems without proper cryptographic review, security audit, and operational risk assessment.

Only the latest published draft and repository materials are considered for security review.

Please do not open public GitHub issues for security vulnerabilities.

If you discover a security issue in the specification, documentation, examples, or reference implementations, please report it privately.

1. Use GitHub Private Vulnerability Reporting if enabled.
2. Or send an email to:

hossein.hezami@gmail.com

Please include as much of the following as possible:

• description of the vulnerability
• affected specification section, file, or implementation
• protocol version and draft revision
• proof of concept, if available
• impact analysis
• suggested mitigation, if known
• whether the issue affects:
  • specification
  • CBOR encoding rules
  • cryptographic derivation
  • duress model
  • threshold mode
  • ratchet model
  • example code
  • documentation

The maintainers will make a best-effort attempt to follow these timelines:

Because PPS is experimental, response times may vary.

Security reports may cover:

• protocol design flaws
• cryptographic misuse
• ambiguity leading to insecure implementations
• replay or downgrade issues
• duress leakage
• threshold bypass
• CBOR canonicalization issues
• Trust Code derivation issues
• example implementation vulnerabilities
• documentation security gaps

The following are generally out of scope unless they reveal a protocol-level issue:

• social engineering
• physical coercion beyond the documented duress model
• compromised operating systems with full control
• denial-of-service attacks without protocol impact
• missing rate limiting in third-party deployments
• production misconfiguration
• unsupported or obsolete draft revisions

Good-faith security research conducted in accordance with this policy is welcome.

Researchers should:

• avoid privacy violations
• avoid data destruction
• avoid service disruption
• avoid accessing other users’ data
• report issues privately before public disclosure

PPS is submitted as an IETF Internet-Draft.

Intellectual property disclosures related to IETF work should follow the IETF IPR policy.

See:

https://datatracker.ietf.org/ipr/

Because PPS includes an optional silent duress mechanism, special care is required for vulnerabilities that could reveal duress state.

Examples of serious duress-related issues:

• server response differs for duress authentication
• timing side-channel reveals duress detection
• error messages reveal duress public key matching
• client UI leaks duress mode
• logs exposed to attackers reveal duress events

Such issues should be treated as high severity.

Please do not publicly disclose a security issue before coordinating with maintainers.

If no response is received within a reasonable time, or if the issue is clearly low risk, responsible disclosure may proceed.

Before reporting an implementation-specific issue, check whether the issue is caused by:

• non-canonical CBOR parsing
• standard base64 instead of base64url
• missing nonce validation
• counter update before signature verification
• missing rate limiting
• weak private key storage
• non-constant-time Trust Code comparison
• incorrect policy hash comparison
• incorrect AmountMark handling
• returning different responses for duress mode

These are common implementation mistakes and may not be protocol vulnerabilities.