The qscg project takes security seriously. As a library implementing post-quantum cryptographic standards, maintaining the integrity and correctness of our implementations is paramount. This document outlines our security policies, supported versions, and vulnerability reporting procedures.
We provide security updates for the following versions of qscg:
| Version | Status | Release Date | Security Support Until |
|---|---|---|---|
| 0.3.x | β Active development | 2025-01 | Current + 6 months |
| 0.2.x | β Supported | 2024-08 | 2025-08 |
| 0.1.x | π End of life | 2024-03 | No longer supported |
| < 0.1.0 | π Unsupported | β | No longer supported |
- Active development: Receives all security patches, bug fixes, and new features.
- Supported: Receives critical security patches only.
- End of life: No longer receives any updates. Please upgrade to a supported version.
Note: We follow Semantic Versioning. Security fixes are released as patch version bumps (e.g.,
0.3.0β0.3.1).
qscg supports Python 3.9+. However, we strongly recommend using the latest stable Python release for security-sensitive applications:
| Python Version | Supported | Recommendation |
|---|---|---|
| 3.13 | β | Recommended |
| 3.12 | β | Recommended |
| 3.11 | β | Supported |
| 3.10 | β | Supported |
| 3.9 | β | Minimum supported |
| < 3.9 | β | Not supported |
If you believe you have discovered a security vulnerability in qscg, please do not open a public issue. Instead, follow the responsible disclosure process below.
-
Report privately: Submit a vulnerability report via GitHub Security Advisories.
- Alternatively, you may email the maintainers directly (see contact below).
-
Provide details: Include the following information in your report:
- Description: Clear description of the vulnerability
- Impact: What security property is violated (confidentiality, integrity, authenticity)?
- Affected versions: Which versions of qscg are affected?
- Affected components: Which modules, functions, or algorithms are involved?
- Reproduction steps: Detailed steps to reproduce the issue
- Proof of concept: If available, provide minimal code demonstrating the vulnerability
- Mitigation: Suggested fix or workaround if known
- References: Any related standards (NIST docs), CVEs, or academic papers
-
Acknowledgment: We will acknowledge receipt of your report within 72 hours.
-
Investigation: We will investigate the vulnerability and may request additional information.
-
Resolution timeline:
Severity Response Time Fix Timeline Critical 24 hours 7 days High 72 hours 14 days Medium 7 days 30 days Low 14 days 60 days -
Disclosure: Once fixed, we will:
- Release a patched version
- Publish a security advisory on GitHub
- Credit the reporter (unless anonymity is requested)
- Request a CVE identifier if appropriate
- We will never take legal action against security researchers who follow this responsible disclosure process.
- We will credit you in the security advisory (unless you prefer anonymity).
- We will keep you informed of our progress toward resolving the issue.
- We will not disclose the vulnerability publicly until a fix is available.
The following are generally not considered security vulnerabilities:
- Vulnerabilities in dependencies (report to the upstream project)
- Issues requiring local system access or physical access
- Social engineering attacks against project maintainers
- DoS via resource exhaustion in non-production configurations
- Issues in deprecated/end-of-life versions
For encrypted communication, you may use the following PGP key to encrypt your reports:
-----BEGIN PGP PUBLIC KEY BLOCK-----
[PLACEHOLDER - This is a placeholder for the project's PGP public key.
Project maintainers should replace this with the actual PGP key.
To generate: gpg --full-generate-key
To export: gpg --armor --export <KEY_ID>]
-----END PGP PUBLIC KEY BLOCK-----
Fingerprint: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
β οΈ This key is optional. The recommended reporting channel is GitHub Security Advisories, which provides encrypted communication automatically.
Stay informed about security updates:
-
Watch the repository: Click "Watch" β "Custom" β "Security alerts" on the GitHub repository page.
-
GitHub Security Advisories: Follow our security advisories page.
-
Release notifications: Enable GitHub release notifications to get notified of new versions.
-
PyPI: Subscribe to the project on PyPI for release notifications.
When using qscg in your applications, follow these security guidelines:
- Never hardcode keys: Use secure key management systems (HSMs, AWS KMS, HashiCorp Vault).
- Rotate keys regularly: Establish a key rotation policy appropriate for your threat model.
- Secure key generation: Always use the library's built-in key generation; never derive keys from weak entropy sources.
- Ensure your system's CSPRNG (
/dev/urandom,CryptGenRandom,getrandom()) is properly seeded. - In virtualized environments, ensure the hypervisor provides adequate entropy to guests.
- ML-KEM (FIPS 203): Use for key encapsulation. Recommended parameter set: ML-KEM-768 (balance of security and performance).
- ML-DSA (FIPS 204): Use for digital signatures. Recommended parameter set: ML-DSA-65.
- SLH-DSA (FIPS 205): Use when stateless signatures with conservative security assumptions are required.
- Keep qscg and all dependencies up to date.
- Monitor our security advisories.
- Use qscg in an isolated security boundary for critical applications.
- Validate all inputs (ciphertexts, signatures, public keys) before processing.
This software is provided "as is", without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose, and noninfringement.
While we strive for correctness and security, this library:
- Has not undergone formal third-party certification or validation.
- Should be used with appropriate security review for your specific use case.
- Does not guarantee protection against all attack vectors, including side-channel attacks not addressed by the implementation.
- Users are responsible for compliance with applicable laws and regulations in their jurisdiction.
For production deployments with high security requirements, we recommend:
- Conducting your own security audit.
- Using certified cryptographic modules where required (e.g., FIPS 140-3 validated HSMs).
- Consulting with a qualified cryptography professional.
| Method | Details |
|---|---|
| GitHub Security Advisories | github.com/mcemkoca/qscg/security/advisories/new |
| Maintainer | @mcemkoca |
| General Issues | Please use GitHub Issues for non-security bugs |
| Discussions | Use GitHub Discussions for general questions |
Last updated: 2025-01-15
This security policy is based on best practices from the OpenSSF and CNCF security guidelines.