[Cryptography] encryption + authentication - waiting - chaining (was: best practices)

[Jerry Leichter]

> Encryption and authentication have different requirements.  For ordinary
> telephony, the encryption blocks have to be quite small, to keep the
> latency under control.  Stream ciphers, if carefully used, work fine.
> The authentication blocks can be somewhat larger.  Millisecond-by-millisecond
> authentication would be overkill.  Second-by-second authentication should
> suffice.  Waiting until the end of the call is not acceptable.
This brings to mind a design I came up with and implemented in a long-obsolete proprietary system years back.  I've never seen anything quite like it used elsewhere, so I pass it along in the hope someone might find it useful.

The system encrypted a data stream used for an RPC-like protocol.  Many calls simply returned a status, so many data segments were tiny - a byte or two of user data.   Others varied in size, though typically none were huge.  Because the underlying data stream was synchronous in some cases, you couldn't just wait for more data to accumulate; you had to deliver what you had promptly.

I chose to use AES-128 in CBC mode (yes, it was vulnerable to the attack published much later on IV's carried over from message to message), with a separate authentication step.  (The newer modes weren't around yet.)  I used an unusual approach to creating blocks to feed into AES, which allowed for "tuned" authentication.  Consider a 16-byte block of cleartext.  The value of the first byte B0, taken as an unsigned 8-bit value, falls into one of three categories:

- B0 > 15:  A full block.  The block contains 16 bytes of user data, including B0.
- 1 <= B0 <= 15:  A short block.  The next B0 bytes in the block contain user data.  The last 16-B0 bytes are available for other purposes.
- B0 = 0:  This is a metadata block, containing no user data.

As you create blocks, you also create a running MAC.  Whenever you emit a short block, you use as many bytes of it as you can to fill the available 5pace at the end.

There is also a security parameter R.  When sending the next block would cause the fraction M/N of MAC bytes sent to user data bytes sent to be less then R, you emit a metadata block containing MAC data.

The receiver does the same computation of M/N, of course, and reports an error if the sender doesn't send enough MAC data to keep M/N in bounds.

                                                        -- Jerry