-
Notifications
You must be signed in to change notification settings - Fork 0
PQC Algorithm Detection and Selection
- Introduction
- System Architecture
- PQC Algorithm Detection
- Integration with fido2.features
- Algorithm Negotiation Process
- Configuration Options
- Fallback Mechanisms
- Testing and Validation
- Troubleshooting Guide
- Best Practices
The Post-Quantum Cryptography (PQC) algorithm detection and selection mechanism in this WebAuthn platform provides a robust framework for identifying, validating, and utilizing quantum-resistant cryptographic algorithms alongside traditional classical algorithms. The system centers around the ML-DSA family of algorithms (ML-DSA-44, ML-DSA-65, ML-DSA-87) backed by the liboqs (Open Quantum Safe) library, enabling seamless integration of post-quantum cryptography into WebAuthn authentication flows.
The implementation follows a sophisticated detection and fallback strategy that maintains backward compatibility while progressively adopting quantum-resistant algorithms. The system intelligently negotiates algorithm availability between client and server, ensuring optimal security posture regardless of the underlying hardware capabilities.
The PQC mechanism operates through a multi-layered architecture that separates concerns between algorithm detection, validation, negotiation, and fallback management:
graph TB
subgraph "Client Layer"
Client[WebAuthn Client]
Browser[Browser Environment]
end
subgraph "Server Application Layer"
Server[Flask Server]
Routes[Route Handlers]
Config[Configuration Manager]
end
subgraph "PQC Detection Layer"
PQCDetector[PQC Detector]
LibOQS[liboqs Backend]
AlgorithmRegistry[Algorithm Registry]
end
subgraph "WebAuthn Integration Layer"
Fido2Server[Fido2Server]
AlgorithmNegotiator[Algorithm Negotiator]
FeatureFlags[Feature Flags]
end
subgraph "Fallback Management Layer"
ClassicalFallback[Classical Fallback]
WarningLogger[Warning Logger]
StateManager[State Manager]
end
Client --> Browser
Browser --> Server
Server --> Routes
Routes --> Config
Config --> PQCDetector
PQCDetector --> LibOQS
LibOQS --> AlgorithmRegistry
Server --> Fido2Server
Fido2Server --> AlgorithmNegotiator
AlgorithmNegotiator --> FeatureFlags
AlgorithmNegotiator --> ClassicalFallback
ClassicalFallback --> WarningLogger
WarningLogger --> StateManager
Diagram sources
- server/pqc.py
- server/server/routes/advanced.py
- fido2/features.py
Section sources
- server/pqc.py
- server/server/routes/advanced.py
The PQC detection system centers around several key functions that query the liboqs backend and determine algorithm availability:
flowchart TD
Start([Algorithm Detection Start]) --> LoadMechanisms["_load_enabled_mechanisms()"]
LoadMechanisms --> ImportCheck{Import Available?}
ImportCheck --> |No| ImportError[ImportError: oqs unavailable]
ImportCheck --> |Yes| GetMechanisms[Query Enabled Mechanisms]
GetMechanisms --> DetectAvailable["detect_available_pqc_algorithms()"]
DetectAvailable --> FilterMechanisms[Filter ML-DSA Algorithms]
FilterMechanisms --> CheckAvailability{All Algorithms Available?}
CheckAvailability --> |Yes| Success[Return Available IDs + None]
CheckAvailability --> |No| Missing[Return Missing Algorithms + Error Message]
ImportError --> ErrorHandling[Error Handling & Logging]
Missing --> ErrorHandling
ErrorHandling --> End([Detection Complete])
Success --> End
Diagram sources
- server/pqc.py
The system maintains a comprehensive mapping between COSE algorithm identifiers and their corresponding liboqs mechanism names:
| COSE Algorithm ID | ML-DSA Variant | Description |
|---|---|---|
| -50 | ML-DSA-87 | Highest security level, larger key sizes |
| -49 | ML-DSA-65 | Medium security level, balanced performance |
| -48 | ML-DSA-44 | Lowest security level, smallest key sizes |
The detection process follows a hierarchical approach to ensure compatibility across different liboqs versions:
-
Primary Detection Method: Uses
oqs.get_enabled_sig_mechanisms()for modern liboqs installations -
Compatibility Fallback: Falls back to
oqs.Signature.algorithmsfor older liboqs versions - Error Handling: Comprehensive error reporting for missing dependencies or unsupported algorithms
Section sources
- server/pqc.py
The system integrates with the fido2.features module to manage PQC functionality at runtime. While the primary PQC detection occurs independently, the feature system provides additional control mechanisms:
classDiagram
class FeatureFlag {
+enabled : bool
+name : str
+description : str
+require(state : bool)
+warn()
}
class PQCFeature {
+detect_available_pqc_algorithms()
+is_pqc_algorithm(alg_id : int)
+log_algorithm_selection(stage : str, alg_id : int)
}
class AlgorithmRegistry {
+PQC_ALGORITHM_ID_TO_NAME : Dict[int, str]
+is_pqc_algorithm(alg_id : int)
+describe_algorithm(alg_id : int)
}
FeatureFlag <|-- PQCFeature
PQCFeature --> AlgorithmRegistry
Diagram sources
- fido2/features.py
- server/pqc.py
The integration provides several runtime control mechanisms:
- Automatic Detection: Algorithms are automatically detected during server startup
- Graceful Degradation: Systems gracefully fall back to classical algorithms when PQC is unavailable
- Logging Integration: All PQC operations are logged through the Flask application logger
- Error Reporting: Comprehensive error messages guide administrators toward resolution
Section sources
- fido2/features.py
- server/pqc.py
The algorithm negotiation process during WebAuthn registration involves several sophisticated steps:
sequenceDiagram
participant Client as WebAuthn Client
participant Server as Flask Server
participant PQCDetector as PQC Detector
participant LibOQS as liboqs Backend
participant Fido2Server as Fido2 Server
Client->>Server : Registration Request
Server->>Server : Parse publicKeyCredentialParameters
Server->>PQCDetector : detect_available_pqc_algorithms()
PQCDetector->>LibOQS : Query Enabled Mechanisms
LibOQS-->>PQCDetector : Available Algorithm Names
PQCDetector-->>Server : Available PQC IDs + Error Message
Server->>Server : Filter Allowed Algorithms
alt PQC Algorithms Available
Server->>Fido2Server : Configure PQC Algorithms
Fido2Server-->>Server : Registration Options
else No PQC Algorithms Available
Server->>Server : Apply Classical Fallback
Server->>Fido2Server : Configure Classical Algorithms
Fido2Server-->>Server : Registration Options
end
Server-->>Client : Registration Challenge with Algorithm List
Diagram sources
- server/server/routes/advanced.py
- server/pqc.py
The algorithm selection process follows a priority-based approach:
- Client Preference: Client-provided algorithm preferences are honored when possible
- Server Configuration: Server-side algorithm preferences override client choices
- Availability Check: Only algorithms supported by the liboqs backend are considered
- Fallback Resolution: Automatic fallback to classical algorithms when PQC is unavailable
- Security Priority: Higher-security PQC variants are preferred when available
The system integrates seamlessly with WebAuthn's publicKeyCredentialParameters structure:
// Example algorithm parameter configuration
{
"pubKeyCredParams": [
{"type": "public-key", "alg": -50}, // ML-DSA-87 (PQC)
{"type": "public-key", "alg": -49}, // ML-DSA-65 (PQC)
{"type": "public-key", "alg": -48}, // ML-DSA-44 (PQC)
{"type": "public-key", "alg": -8}, // EdDSA (Classical)
{"type": "public-key", "alg": -7} // ES256 (ECDSA)
]
}Section sources
- server/server/routes/advanced.py
- server/server/routes/simple.py
The system supports several configuration approaches to control PQC behavior:
| Configuration Option | Purpose | Default Behavior |
|---|---|---|
python-fido2-webauthn-test[pqc] |
Install PQC dependencies | Disabled |
| liboqs presence | Runtime detection | Auto-detected |
| Algorithm availability | Per-algorithm support | Dynamic |
For development and testing scenarios, administrators can control PQC behavior:
- Force PQC Mode: Enforce PQC-only operation for testing
- Disable PQC: Temporarily disable PQC for compatibility testing
- Selective Enable: Enable specific PQC algorithms while disabling others
The system manages PQC dependencies through Poetry's extra system:
[tool.poetry.extras]
pqc = ["oqs", "pqcrypto"]This allows administrators to install only the dependencies they need, reducing the attack surface and simplifying deployment.
Section sources
- pyproject.toml
- requirements.txt
The system implements a sophisticated fallback mechanism that ensures authentication continuity:
flowchart TD
Start([Algorithm Negotiation]) --> CheckPQC{PQC Available?}
CheckPQC --> |Yes| CheckSpecific{Specific Algorithm Available?}
CheckSpecific --> |Yes| UsePQC[Use PQC Algorithm]
CheckSpecific --> |No| LogWarning[Log Warning Message]
LogWarning --> CheckFallback{Fallback Available?}
CheckFallback --> |Yes| UseFallback[Use Classical Fallback]
CheckFallback --> |No| RejectRegistration[Reject Registration]
CheckPQC --> |No| LogError[Log Error Message]
LogError --> UseFallback
UsePQC --> Success([Authentication Success])
UseFallback --> Success
RejectRegistration --> Failure([Authentication Failure])
Diagram sources
- server/server/routes/advanced.py
When PQC algorithms are unavailable, the system automatically falls back to classical algorithms:
- Primary Fallback: ES256 (ECDSA) with P-256 curve
- Secondary Fallback: EdDSA (Ed25519)
- Tertiary Fallback: RS256 (RSA) with 2048-bit keys
The fallback mechanism provides comprehensive logging:
- Warning Messages: Informative messages about algorithm unavailability
- Error Details: Specific information about missing dependencies
- Resolution Guidance: Clear instructions for administrators
Section sources
- server/server/routes/advanced.py
- server/pqc.py
The system includes comprehensive testing for ML-DSA algorithms:
classDiagram
class MLDSATestSuite {
+ML_DSA_VARIANTS : List[Tuple]
+test_mldsa_registration_and_authentication()
+setup_test_environment()
+validate_attestation_flow()
+test_authentication_flow()
}
class TestVariant {
+label : str
+cose_cls : Type[CoseKey]
+alg_id : int
+key_length : int
}
class TestEnvironment {
+mock_server : Fido2Server
+mock_attestation : AttestationObject
+test_user : Dict
+client_data : CollectedClientData
}
MLDSATestSuite --> TestVariant
MLDSATestSuite --> TestEnvironment
Diagram sources
- tests/test_mldsa_registration_authentication.py
The testing framework covers:
- Registration Flows: End-to-end registration with ML-DSA algorithms
- Authentication Flows: Authentication using ML-DSA credentials
- Error Scenarios: Edge cases and failure modes
- Algorithm Variants: Testing all three ML-DSA parameter sets
Each test validates:
- Algorithm Identification: Proper identification of ML-DSA algorithms
- Key Generation: Correct key pair generation and validation
- Signature Verification: Successful signature verification
- Attestation Chain: Proper attestation chain validation
- Fallback Behavior: Graceful degradation when PQC is unavailable
Section sources
- tests/test_mldsa_registration_authentication.py
Symptoms: ML-DSA algorithms not appearing in registration options Causes: Missing liboqs installation or unsupported algorithms Solutions:
- Install PQC dependencies:
pip install python-fido2-webauthn-test[pqc] - Verify liboqs installation: Check for
oqsmodule availability - Rebuild liboqs with ML-DSA support
Symptoms: Warning messages about missing PQC algorithms Causes: Partial liboqs installation or outdated bindings Solutions:
- Update liboqs to latest version
- Reinstall python-fido2-webauthn-test package
- Verify algorithm availability in liboqs
Symptoms: Slow registration/authentication with PQC algorithms Causes: Hardware limitations or inefficient implementations Solutions:
- Use smaller ML-DSA variant (-48) for better performance
- Ensure adequate CPU resources
- Monitor system performance metrics
The system provides several diagnostic capabilities:
- Algorithm Detection Logs: Detailed logs of algorithm availability
- Error Messages: Specific error messages guiding resolution
- Fallback Warnings: Information about fallback algorithm usage
- Performance Metrics: Timing information for algorithm operations
Section sources
- server/pqc.py
- server/server/routes/advanced.py
- Dependency Management: Always install PQC dependencies explicitly
- Monitoring: Monitor algorithm availability and fallback usage
- Testing: Regular testing of PQC functionality in staging environments
- Documentation: Maintain clear documentation of PQC configuration
- Algorithm Selection: Prefer higher-security PQC variants when available
- Fallback Security: Ensure fallback algorithms meet minimum security requirements
- Monitoring: Monitor for unusual fallback patterns that may indicate issues
- Updates: Keep liboqs and PQC dependencies updated
- Algorithm Choice: Select appropriate ML-DSA variant based on performance requirements
- Hardware: Ensure adequate computational resources for PQC operations
- Caching: Implement caching for algorithm detection results
- Monitoring: Monitor performance impact of PQC operations
- Regular Updates: Keep PQC dependencies updated
- Testing: Regular testing of fallback mechanisms
- Documentation: Maintain up-to-date documentation
- Monitoring: Implement comprehensive monitoring and alerting