Nikos Mavrogiannopoulos <n.mavrogiannopou...@gmail.com> writes:
> On Tue, Jan 23, 2018 at 7:34 PM, Niels Möller <ni...@lysator.liu.se> wrote:
>> These are the methods I'd expect "most" AEADs to have, and it's what the
>> nettle_aead struct is intended to capture. But maybe there are too many
>> exceptions. It's good to have several examples to consider.
>
> I think that the nettle_aead is too specific to gcm. chacha20-poly1305
> fitted in there, but it seems that other AEAD ciphers would not fit.
I'm afraid you're right. Then we'll either have to change nettle_aead,
or introduce a new struct, say nettle_message_aead or so.
>> So then we'de have something similar to the ccm_*_message functions.
>> Should the nonce length and tag length be variable per message?
>
> The tag is fixed since it is used as the IV. On the branch I'm working
> on I have the following interface:
>
> struct siv_aes128_cmac_ctx {
> struct aes128_ctx cipher;
> uint8_t s2vk[AES128_KEY_SIZE];
> };
>
> void
> siv_aes128_cmac_set_key(struct siv_aes128_cmac_ctx *ctx, const uint8_t *key);
>
> void
> siv_aes128_cmac_encrypt_message(struct siv_aes128_cmac_ctx *ctx,
> size_t nlength, const uint8_t *nonce,
> size_t alength, const uint8_t *adata,
> size_t tlength,
> size_t clength, uint8_t *dst, const
> uint8_t *src);
>
> int
> siv_aes128_cmac_decrypt_message(struct siv_aes128_cmac_ctx *ctx,
> size_t nlength, const uint8_t *nonce,
> size_t alength, const uint8_t *adata,
> size_t tlength,
> size_t mlength, uint8_t *dst, const
> uint8_t *src);
I think this is the right level for most applications. But I'm a bit
confused with regards to my questions. Are the tlength and nlength
arguments useful (for siv, and and for aead in general)?
Or should at least tag length be considered parameter of the aead
algorithm, not something which can vary from message to message?
For hashes and macs, use of truncated outputs seemed fairly common,
which is why the current interfaces includes a digest length argument.
But aeads are a bit different. For SIV, would a shortened tag just
reduce the strength of authentication, or would it make it impossible to
decrypt the message?
> I think the expectation is to prepend the tag/IV to the message. As
> the message interface above doesn't distinguish between tag and
> ciphertext, I think it quite conveniently fits it.
For authenticated decryption one needs three pieces of data:
1. The nonce.
2. The ciphertext.
3. The tag.
The nonce should most likely be a separate argument, it might not be
attached at all to the data on the wire. E.g., it could be derived from
an implicit message number.
The current ccm_*_ message functions represents ciphertext and tag as a
single blob,
+--------------+-------+
| ciphertext | tag |
+--------------+-------+
It seems you're saying that for siv, you put them together in the
opposite order,
+-------+--------------+
| tag | ciphertext |
+-------+--------------+
Should we treat the encrypted message as a single blob, with any
internal structure being an internal detail of the aead? That seems to
be the RFC 5116 view.
In case there are protocols or applications that specify that ciphertext
and tag are sent/stored as separately byte strings, we would need to
expose that distinction in the api. E.g., say we do in-place
block-by-block encryption on disk, and treat nonce and tag for each
block as metadata, stored elsewhere.
> A possible interface could be:
> void siv_aes128_cmac_set_key(struct siv_aes128_cmac_ctx *ctx, const
> uint8_t *key)
> void siv_aes128_cmac_s2v(struct siv_aes128_cmac_ctx *ctx, size_t
> nlength, const uint8_t *nonce,
> size_t adatalen, size_t *alength, const
> uint8_t **adata,
> size_t plength, size_t pdata);
>
> (notice the pointer to pointer for adata)
I think I'd prefer something like
void
siv_aes128_cmac_extra_adata(struct siv_aes128_cmac_ctx *ctx,
size_t length, const uint8_t *data);
to be called zero or more times between _set_key and the call with the
body of the message. (Probably need a separate set_nonce function too,
if nonce must be known before processing and associated data).
I hope it should be possible to design something reasonable. (And we
don't need to expose it in the general aead interface).
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
_______________________________________________
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
