docs(cipher): salt misuse resistance calculations inaccurate

[rmlibre]

Is this a new bug in aiootp?

• This affects a supported version of aiootp
• This isn't a security vulnerability or issue
• I've searched the existing issues, & I couldn't find one for this bug

Current Behavior

The salt misuse-reuse resistance descriptions in the ciphers subpackage documentation are wrong. This is the current language:

aiootp/aiootp/ciphers/cipher_interface.py

Lines 128 to 135 in 26e0026

	`salt`: A [pseudo]random salt that may be supplied by the user. By
	default it's sent in the clear attached to the ciphertext.
	Thus it may simplify implementing efficient features, such
	as search or routing, though care must still be taken when
	considering how leaking such metadata may be harmful.
	Keeping this value constant is strongly discouraged, though
	the salt misuse-reuse resistance of the cipher extends up
	to ~256**(len(iv)/2 + len(siv_key)/2) encryptions/second.

Specifically the excerpts:

1. "the salt misuse-reuse resistance of the cipher extends up to"

   The phrase "extends up to" is vague, neglecting to specify the probabilities of repeats associated with iv & siv_key sizes.

2. "extends up to ~256**(len(iv)/2 + len(siv_key)/2) encryptions/second"

   The division by 2 here is wrong, unless the documentation is attempting to express security in terms of a 50% chance per second of a duplicate randomness context. That isn't an adequate security notion.

Expected Behavior

1. The security notion, with associated repeat probabilities, should be formulated in terms of the optimal bound, described here.

2. Instead of division by 2, the division should be by 3 to relate to the optimal bound.

Environment

- OS: Any
- Python: 3.8+
- aiootp: 0.23.x

Additional Context

The table below is quite useful for calculating birthday bound security.

For transparency, Slick256 uses a 64-bit iv combined with a 64-bit siv_key. That puts it in the 2**128-bit row of the table. And, Chunky2048 uses a 64-bit + 128-bit iv & siv_key combination, which falls under the 2**192-bit row of the table. That's if the salt is deliberately kept constant. If the salt is chosen randomly, then Slick256 falls under the 2**192 row, and Chunky2048 falls under the 2**256 row.

[rmlibre]

Resolved by (ea07198, 616967b)