opencrypto: Relax checks for zero-length payloads

[markj]

Summary

In general it is permitted to submit crypto ops with zero-length
payloads. However, our handling of them is inconsistent. In
particular, crypto_op() checks for an input length of zero and returns
EINVAL in that case, but one can bypass this check by passing an inline
IV, resulting in a cryptop with payload_start != 0 && payload_length ==
0. cryptoaead_op() does not check for a length of zero at all.

In the aforementioned case where a crypto op has length zero but an
inline IV, the operation will trigger a KASSERT in crp_sanity() since
crp_payload_start != 0 && crp_payload_len == 0. Relax the assertion to
permit this. Remove the check in crypto_op(), reverting commit
e6d944d7c3eae828d8353abd414f634067ec6f7d.

Reported by: [e-mail]

[jhb]

sys/opencrypto/crypto.c

1299

Hmmm, I do think it's kind of odd to give a payload_start if payload_length is 0 fwiw. See for example the assertion about aad at 1266-1268. My intention was to require start fields to be 0 if the associated length was 0. Of course, that would require a special case in cryptodev for an empty payload to leave the start as 0. Hmmm.

sys/opencrypto/cryptodev.c

756

Hmm, I do think a payload of 0 should be an error if there isn't an associated MAC. Perhaps as a followup to my pending change we could change the == 0 case I moved into the CSP_CIPHER case further below to take into account the implicit IV?

[markj]

sys/opencrypto/cryptodev.c

756

Isn't the problem broader than just the CSP_CIPHER case though?

[jhb]

sys/opencrypto/cryptodev.c

756

An empty payload is permitted for ETA and AEAD modes (you still generate a MAC/tag output even with an empty payload). DIGEST doesn't have a txform, so it's really just CIPHER mode for which this is relevant.

[markj]

Superseded by D32109.