# Crypto parameters accepted without bounds

Does the receiver enforce minimum tag length, key size and protocol version from its own policy, not the message?

_Area: Web authentication and account takeover. Seen in 4 disclosed reports; latest 2026-07-22. Updated 2026-10-24._

## How it works
A receiver reads a cryptographic parameter from the message it is verifying (tag length, key size, protocol version) and uses that value as the rule for the check. The assumption that breaks is that the sender's declared parameters are trustworthy and already meet policy. When the receiver takes the attacker's value as the expected value, the check becomes weaker than intended: a 1-byte tag is compared instead of 12-16 bytes, a 512-bit export key is accepted in a normal handshake, or a protocol version the operator meant to disable still completes a handshake.

## Where it shows up
- Ciphertext or ASN.1 fields carrying tag/ICV length, algorithm id, or key id that the parser reads and then uses to size its own comparison [E1](https://bugbountylibrary.com/r/blog%3Ablog-calif-io-p-how-to-format-a-ciphertext.md)
- Handshake messages that offer a downgraded key exchange (EXPORT_RSA ServerKeyExchange) inside a non-export handshake [E2](https://bugbountylibrary.com/r/h1%3A50170.md)
- Configuration that disables individual ciphers but not the protocol version, leaving the version reachable [E3](https://bugbountylibrary.com/r/h1%3A166634.md)
- Schema-declared ranges (ASN.1 constraints) that the parser never enforces at runtime [E1](https://bugbountylibrary.com/r/blog%3Ablog-calif-io-p-how-to-format-a-ciphertext.md)

## How to review
Find every parameter the receiver reads from the message and uses to decide acceptance. For each, ask: is the expected value taken from local policy or from the message? The invariant: tag length, key size and protocol version must be checked against a fixed minimum/policy before any comparison or handshake step, and a message declaring a weaker value must be rejected, not accommodated. For protocol disablement, verify the protocol-level kill switch is set, not just cipher removal [E3](https://bugbountylibrary.com/r/h1%3A166634.md).

## Variants seen
- AEAD tag length taken from ciphertext, no lower bound, forgery at ~1/256 per attempt [E1](https://bugbountylibrary.com/r/blog%3Ablog-calif-io-p-how-to-format-a-ciphertext.md)
- Export-grade key exchange accepted mid-handshake, 512-bit key factored [E2](https://bugbountylibrary.com/r/h1%3A50170.md)
- Cipher-level disable leaves protocol version live [E3](https://bugbountylibrary.com/r/h1%3A166634.md)

## Impact and severity
Forged authenticated messages [E1](https://bugbountylibrary.com/r/blog%3Ablog-calif-io-p-how-to-format-a-ciphertext.md), server impersonation of major sites [E2](https://bugbountylibrary.com/r/h1%3A50170.md), and exposure to DROWN despite apparent hardening [E3](https://bugbountylibrary.com/r/h1%3A166634.md). Severity is high because the weakness is silent: configuration looks correct and the check appears to run. It worsens when the same parser pattern is copied across libraries [E1](https://bugbountylibrary.com/r/blog%3Ablog-calif-io-p-how-to-format-a-ciphertext.md) and when operators believe cipher removal equals protocol removal [E3](https://bugbountylibrary.com/r/h1%3A166634.md).

## Evidence
- E1: https://bugbountylibrary.com/r/blog%3Ablog-calif-io-p-how-to-format-a-ciphertext.md
- E2: https://bugbountylibrary.com/r/h1%3A50170.md
- E3: https://bugbountylibrary.com/r/h1%3A166634.md