The multi-trait crate gives foundational traits for encoding and decoding multiformats types. It uses unsigned varint encoding. This document describes the security properties and the threat model of the crate.

• No unsafe code. #![deny(unsafe_code)] is set at the crate root. The crate uses only safe Rust abstractions.
• No buffer overflows. All buffer operations use safe indexing and slicing.
• No use-after-free. Lifetimes keep references valid.
• No data races. All types are Send + Sync with no shared mutable state.

• Malformed data rejection. Invalid varint encodings are detected and rejected with an error.
• Truncated data detection. Incomplete varints are rejected before processing.
• Boundary checking. All operations check buffer boundaries before access.
• Type-level validation. EncodedBytes gives data validity at the type level.

• Excessive memory allocation for integer encoding. Integer encoding uses at most 19 bytes (for u128).
• Stack overflow. No recursive operations. All encoding and decoding is iterative.
• Infinite loops. All loops have deterministic bounds set by the input size.
• Panic-based DoS. Tests check that no panic occurs on malicious input.

• No arithmetic overflow. All operations delegate to the unsigned-varint crate. It handles overflow.
• Type-safe conversions. Decoding checks that values fit in the target type.
• Maximum value testing. Tests cover TYPE::MAX values for all types.

The crate handles:

1. Untrusted input data from network sources, files, or user input.
2. Maliciously crafted varint sequences.
3. Extreme values at type boundaries (0 and MAX).
4. Truncated or incomplete data from interrupted transmissions.
5. Concurrent access from multiple threads.

The crate does not protect against:

1. Side-channel attacks. No constant-time guarantees. Timing may leak information.
2. Cryptographic security. This is an encoding library, not a crypto library.
3. Resource exhaustion. Callers must set rate limits and quotas.
4. Semantic validation. Callers must check that decoded values are semantically correct.
5. Physical attacks. No protection against hardware-level attacks.

• No panics on invalid input. All error conditions return Result.
• No buffer overflows. All indexing is bounds-checked.
• No undefined behavior. #![deny(unsafe_code)] forbids unsafe code.
• Deterministic behavior. The same input always gives the same output.
• Error transparency. All errors give source chains for debugging.
• Type safety. Invalid states are not representable.

• Constant-time operations. Encoding and decoding time may vary with the input.
• Resource limits. Callers must set quotas.
• Side-channel resistance. The crate is not for cryptographic use.
• Backward compatibility with bugs. Security fixes may break buggy code.

The crate depends on:

• unsigned-varint (v0.8). Gives the varint encoding and decoding.
• thiserror (v2.0). Error type derivation.

Dev dependencies:

• proptest (v1.4). Property-based testing.
• criterion (v0.5). Benchmarking.

• The unsigned-varint crate is used in the IPFS and libp2p ecosystem.
• This crate relies on its security properties for varint parsing.
• Any security issue in unsigned-varint affects this crate.

If you find a security vulnerability in this crate, report it as follows:

1. Do not open a public GitHub issue.
2. Email the maintainers at the address in Cargo.toml.
3. Include a description of the vulnerability.
4. Include steps to reproduce it.
5. Include the potential impact.
6. Include a suggested fix if you have one.

• Initial response: within 48 hours.
• Vulnerability assessment: within 1 week.
• Fix development: depends on severity.
• Public disclosure: after the fix is released. Coordinated disclosure.

The crate has these security tests:

• 13 malicious input tests for attack vectors.
• 6 property tests with random inputs.
• Edge case tests for boundary conditions, max values, and empty inputs.
• Regression tests for all discovered bugs.

# Run all tests
cargo test

# Run only security tests
cargo test security_

# Run property tests with more cases
cargo test -- --ignored --test-threads=1

All pull requests must pass:

• All unit tests.
• All integration tests.
• All property-based tests.
• Clippy with no warnings.
• Format check.

The crate assumes that callers will:

1. Validate decoded values. Check that decoded values make sense.
2. Set resource limits. Enforce quotas on input size and decode operations.
3. Handle errors. Do not ignore or unwrap Result in production code.
4. Use the right types. Pick the smallest type that can hold the data.

1. The Rust standard library is correct.
2. The dependencies are secure.
3. The compiler is correct.
4. The platform is not compromised.

1. Always handle errors. Do not unwrap in production code.

// Bad
let (value, _) = u32::try_decode_from(untrusted).unwrap();

// Good
let (value, _) = u32::try_decode_from(untrusted)?;

2. Validate semantic correctness. Type checking is not enough.

let (port, _) = u16::try_decode_from(data)?;
if port == 0 {
    return Err("port cannot be zero");
}

3. Limit input size. Prevent resource exhaustion.

if input.len() > MAX_MESSAGE_SIZE {
    return Err("input too large");
}

4. Use validated types. Use EncodedBytes for pre-validated data.

fn process(data: EncodedBytes) {
    // The data is valid. No re-validation needed.
}

1. Do not use unsafe. The crate enforces #![deny(unsafe_code)].
2. Add tests for new features. Include security test cases.
3. Document security implications. Explain potential misuse.
4. Consider DoS vectors. Analyze every new feature for DoS potential.

• Rewrote documentation in ASD-STE100 strict mode.
• Fixed inaccuracies in README.md and SECURITY.md.
• No known vulnerabilities.

• Removed the unmaintained serde_cbor dev-dependency.
• Removed the redundant unsafe impl Send/Sync for EncodedBytes.
• No known vulnerabilities.

• Added #![deny(unsafe_code)] and clippy lint configuration.
• Added MSRV declaration and CI jobs for audit, fmt, and clippy.
• No known vulnerabilities.

• Initial production release.
• Validation in EncodedBytes.
• No known vulnerabilities.

This crate has not had a professional security audit. Review the code before you use it in security-critical applications.

Security issues are handled under the same Apache-2.0 license as the crate.