mirror of
https://github.com/kharonsec/SecurityArc
synced 2026-04-25 14:44:57 +02:00
94 lines
3.5 KiB
Markdown
94 lines
3.5 KiB
Markdown
# SecureArc Security Model
|
|
|
|
This document describes the security model, threat analysis, and security guarantees of SecureArc. For user documentation, see [User Guide](USER_GUIDE.md).
|
|
|
|
## Threat Model
|
|
|
|
SecureArc is designed to protect against:
|
|
|
|
1. **Brute-Force Attacks**: Automated password guessing attempts
|
|
2. **Casual Attackers**: Unauthorized users attempting to access archives
|
|
3. **Key Recovery**: Attempts to extract encryption keys from archives
|
|
|
|
## Security Guarantees
|
|
|
|
### Encryption
|
|
|
|
- **AES-256-GCM**: Provides authenticated encryption with 256-bit keys
|
|
- **ChaCha20-Poly1305**: Provides authenticated encryption with 256-bit keys
|
|
- Both algorithms provide confidentiality, integrity, and authenticity
|
|
|
|
### Key Derivation
|
|
|
|
- **Argon2id**: Memory-hard function resistant to GPU and ASIC attacks
|
|
- Recommended: 64 MB memory, 3 iterations, 4 threads
|
|
- Makes brute-force attacks computationally expensive
|
|
- **PBKDF2-SHA256**: Legacy support with high iteration counts (≥10,000)
|
|
|
|
### Self-Destruct Mechanism
|
|
|
|
The self-destruct mechanism provides protection by:
|
|
|
|
1. **Attempt Tracking**: HMAC-protected counter prevents tampering
|
|
2. **Automatic Destruction**: After N failed attempts, key material is destroyed
|
|
3. **Rollback Prevention**: Counter is cryptographically bound to header
|
|
|
|
## Limitations
|
|
|
|
### Known Limitations
|
|
|
|
1. **File Copying**: Sophisticated attackers may create backup copies before attempting decryption
|
|
- **Mitigation**: Strong encryption ensures brute-force remains infeasible even with unlimited attempts
|
|
|
|
2. **Custom Tools**: Attackers may use custom tools that bypass the reference implementation
|
|
- **Mitigation**: Format specification is open, but encryption remains strong
|
|
|
|
3. **Side-Channel Attacks**: Timing or power analysis attacks are not explicitly mitigated
|
|
- **Mitigation**: Use of well-audited cryptographic libraries (ring, RustCrypto)
|
|
|
|
4. **Header Backup**: Users may export header backups, allowing recovery
|
|
- **Mitigation**: This is a feature, not a bug - allows recovery mechanisms
|
|
|
|
### Threat Scenarios
|
|
|
|
#### Scenario 1: Lost Password
|
|
- **Risk**: User forgets password after multiple failed attempts
|
|
- **Mitigation**: Recovery key slots can be configured with separate passwords
|
|
|
|
#### Scenario 2: Accidental Destruction
|
|
- **Risk**: User or automated system triggers self-destruct accidentally
|
|
- **Mitigation**: Header backups can be exported before distribution
|
|
|
|
#### Scenario 3: Malicious Destruction
|
|
- **Risk**: Attacker intentionally triggers destruction
|
|
- **Mitigation**: This is the intended behavior - prevents unauthorized access
|
|
|
|
## Security Recommendations
|
|
|
|
1. **Strong Passwords**: Use passwords with high entropy (≥128 bits)
|
|
2. **Appropriate Max Attempts**: Balance security (lower) vs usability (higher)
|
|
3. **Header Backups**: Export security headers before distribution
|
|
4. **Recovery Keys**: Configure recovery key slots for critical archives
|
|
5. **Regular Updates**: Keep cryptographic libraries up-to-date
|
|
|
|
## Cryptographic Analysis
|
|
|
|
### Key Strength
|
|
|
|
- Master keys: 256 bits (2^256 possible keys)
|
|
- Derived keys: 256 bits (from password via KDF)
|
|
- Brute-force resistance: Computationally infeasible with strong passwords
|
|
|
|
### Integrity Protection
|
|
|
|
- HMAC-SHA256: 256-bit security level
|
|
- Prevents tampering with attempt counter
|
|
- Binds counter to header cryptographically
|
|
|
|
### Compression Security
|
|
|
|
- Compression algorithms are applied before encryption
|
|
- No known plaintext attacks on compressed+encrypted data
|
|
- Standard compression algorithms (LZMA2, Zstd, Brotli) are well-studied
|
|
|