[email protected] (Niels Möller) writes:
> Owen Kirby <[email protected]> writes:
>> --- /dev/null
>> +++ b/ccm.h
>> +/* Obnoxiously, CCM mode requires the adata and message lengths when
>> + * building the IV. This prevents any sort of streaming type API to
>> + * the cipher mode. We chose to put all of that cruft in the set_nonce()
>> + * function, so that the update/encrypt/decrypt and digest functions will
>> + * remain compatible with the nettle AEAD API.
>> + */
>> +void
>> +ccm_set_nonce(struct ccm_ctx *ctx, size_t noncelen, const uint8_t *nonce,
>> + size_t authlen, size_t msglen, size_t taglen);
>
> Are there any alternative ways to design this interface? E.g., one could
> specify that for ccm, the update and encrypt/decrypt functions may be
> called at most once for each message, with no possibility for streaming
> or incremental processing. But that won't help if one needs *both*
> lengths before processing either the message data or the associated
> data.
It looks like that isn't possible. Reading the code (I haven't read the
spec yet), it seems like the message length must be known before
processing of the associated data.
However we decide to do the incremental interface for CCM, I think it
would be good to also provide an all-in-one function, something like
void
ccm_encrypt_message (void *cipher_ctx, nettle_crypt_func *f,
size_t nonce_length, const uint8_t *nonce,
size_t adata_length, const uint8_t *adata,
size_t tag_length,
size_t msg_length, uint8_t *dst, const uint8_t *src);
/* Return 1 on success, 0 on authentication failure */
int
ccm_decrypt_message (void *cipher_ctx, nettle_crypt_func *f,
size_t nonce_length, const uint8_t *nonce,
size_t adata_length, const uint8_t *adata,
size_t tag_length,
size_t msg_length, uint8_t *dst, const uint8_t *src);
(since CCM doesn't quite fit in Nettle's aead framework, it can't easily
use any general construction on top of that framework). But there are
usecases where incremental processing is desired. E.g, processing a
large file (size limited to 16 MB - 1 byte with RFC 5116 parameters for
CCM, so maybe not *extremely* large), where you could know the size in
advance, e.g., from stat(2), but still might want to do the processing
with an i/o buffer in memory limited to, say, 64 KB.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
