[PATCH v2 3/3] doc: match ChaCha-Poly1305 documentation to the implementation
From: Daiki Ueno
While the documentation said the nonce size is 8 octets, the
implementation actually assumed 12 octets following RFC 7539.
Signed-off-by: Daiki Ueno
---
nettle.texinfo | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/nettle.texinfo b/nettle.texinfo
index fe44f6af..418f46d8 100644
--- a/nettle.texinfo
+++ b/nettle.texinfo
@@ -3323,17 +3323,12 @@ except that @var{cipher} and @var{f} are replaced with
a context structure.
ChaCha-Poly1305 is a combination of the ChaCha stream cipher and the
poly1305 message authentication code (@pxref{Poly1305}). It originates
from the NaCl cryptographic library by D. J. Bernstein et al, which
-defines a similar construction but with Salsa20 instead of ChaCha.
-
-Nettle's implementation ChaCha-Poly1305 should be considered
-@strong{experimental}. At the time of this writing, there is no
-authoritative specification for ChaCha-Poly1305, and a couple of
-different incompatible variants. Nettle implements it using the original
-definition of ChaCha, with 64 bits (8 octets) each for the nonce and the
-block counter. Some protocols prefer to use nonces of 12 bytes, and it's
-a small change to ChaCha to use the upper 32 bits of the block counter
-as a nonce, instead limiting message size to @math{2^32} blocks or 256
-GBytes, but that variant is currently not supported.
+defines a similar construction but with Salsa20 instead of ChaCha.
+
+Nettle's implementation of ChaCha-Poly1305 follows @cite{RFC 8439},
+where the ChaCha cipher is initialized with a 12-byte nonce and a 4-byte
+block counter. This allows up to 256 gigabytes of data to be encrypted
+using the same key.
For ChaCha-Poly1305, the ChaCha cipher is initialized with a key, of 256
bits, and a per-message nonce. The first block of the key stream
@@ -3362,7 +3357,7 @@ ChaCha-Poly1305 key size, 32.
@end defvr
@defvr Constant CHACHA_POLY1305_NONCE_SIZE
-Same as the ChaCha nonce size, 16.
+ChaCha-Poly1305 nonce size, 12.
@end defvr
@defvr Constant CHACHA_POLY1305_DIGEST_SIZE
--
2.24.1
___
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 2/2] doc: match ChaCha-Poly1305 documentation to the implementation
Daiki Ueno writes:
> From: Daiki Ueno
>
> While the documentation said the nonce size is 16 octets, the
And 16 was never correct, the older variant used 8 octests (CHACHA_NONCE_SIZE).
> implementation actually assumed 12 octets following RFC 7539.
>
> Signed-off-by: Daiki Ueno
> ---
> nettle.texinfo | 17 +
> 1 file changed, 5 insertions(+), 12 deletions(-)
>
> diff --git a/nettle.texinfo b/nettle.texinfo
> index 0b339f51..7d5e1780 100644
> --- a/nettle.texinfo
> +++ b/nettle.texinfo
> @@ -3292,17 +3292,10 @@ except that @var{cipher} and @var{f} are
> replaced with a context structure.
> ChaCha-Poly1305 is a combination of the ChaCha stream cipher and the
> poly1305 message authentication code (@pxref{Poly1305}). It originates
> from the NaCl cryptographic library by D. J. Bernstein et al, which
> -defines a similar construction but with Salsa20 instead of ChaCha.
> -
> -Nettle's implementation ChaCha-Poly1305 should be considered
> -@strong{experimental}. At the time of this writing, there is no
> -authoritative specification for ChaCha-Poly1305, and a couple of
> -different incompatible variants. Nettle implements it using the original
> -definition of ChaCha, with 64 bits (8 octets) each for the nonce and the
> -block counter. Some protocols prefer to use nonces of 12 bytes, and it's
> -a small change to ChaCha to use the upper 32 bits of the block counter
> -as a nonce, instead limiting message size to @math{2^32} blocks or 256
> -GBytes, but that variant is currently not supported.
> +defines a similar construction but with Salsa20 instead of ChaCha.
> +
> +Nettle's implementation of ChaCha-Poly1305 follows @cite{RFC 7539}.
> +Unlike the original definition of ChaCha, the nonces are of 12 bytes.
Maybe worth mentioning the 32-bit block count and corresponding limit on
message size?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH 2/2] doc: match ChaCha-Poly1305 documentation to the implementation
From: Daiki Ueno
While the documentation said the nonce size is 16 octets, the
implementation actually assumed 12 octets following RFC 7539.
Signed-off-by: Daiki Ueno
---
nettle.texinfo | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/nettle.texinfo b/nettle.texinfo
index 0b339f51..7d5e1780 100644
--- a/nettle.texinfo
+++ b/nettle.texinfo
@@ -3292,17 +3292,10 @@ except that @var{cipher} and @var{f} are replaced with
a context structure.
ChaCha-Poly1305 is a combination of the ChaCha stream cipher and the
poly1305 message authentication code (@pxref{Poly1305}). It originates
from the NaCl cryptographic library by D. J. Bernstein et al, which
-defines a similar construction but with Salsa20 instead of ChaCha.
-
-Nettle's implementation ChaCha-Poly1305 should be considered
-@strong{experimental}. At the time of this writing, there is no
-authoritative specification for ChaCha-Poly1305, and a couple of
-different incompatible variants. Nettle implements it using the original
-definition of ChaCha, with 64 bits (8 octets) each for the nonce and the
-block counter. Some protocols prefer to use nonces of 12 bytes, and it's
-a small change to ChaCha to use the upper 32 bits of the block counter
-as a nonce, instead limiting message size to @math{2^32} blocks or 256
-GBytes, but that variant is currently not supported.
+defines a similar construction but with Salsa20 instead of ChaCha.
+
+Nettle's implementation of ChaCha-Poly1305 follows @cite{RFC 7539}.
+Unlike the original definition of ChaCha, the nonces are of 12 bytes.
For ChaCha-Poly1305, the ChaCha cipher is initialized with a key, of 256
bits, and a per-message nonce. The first block of the key stream
@@ -3331,7 +3324,7 @@ ChaCha-Poly1305 key size, 32.
@end defvr
@defvr Constant CHACHA_POLY1305_NONCE_SIZE
-Same as the ChaCha nonce size, 16.
+ChaCha-Poly1305 nonce size, 12.
@end defvr
@defvr Constant CHACHA_POLY1305_DIGEST_SIZE
--
2.24.1
___
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: chacha-poly1305
James Cloos writes: > I expect additional users to ignore that draft and use chacha as it was > intended. For plain chacha, I totally agree. Question is about the chacha-poly1305 construction. But it shouldn't be too painful to support two nonce-sizes, as long as that's the only difference. 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
Re: chacha-poly1305
> "NM" == Nikos Mavrogiannopoulos writes: NM> Are you sure that these will not be updated to follow the final NM> document? It would be sad to have protocols following an early draft NM> and others the final. AFAIK the ssh usage has nothing to do with the cfrg drafts. It came directly from Dan's paper(s). I expect additional users to ignore that draft and use chacha as it was intended. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 ___ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: chacha-poly1305
Nikos Mavrogiannopoulos writes: > Are you sure that these will not be updated to follow the final > document? It would be sad to have protocols following an early draft > and others the final. These days, I'm not following ssh as closely as I'd like to. But I think current use of chacha-poly1305 is specified by openssh, not really standardized. I'm considering raising this on the ietf-ssh list (if no one else is quicker). Compared to the openssh implementation I'd like to 1. Make the AEAD processing compatible with the upcoming RFC. 2. Use leftover bits from the first chacha block to encrypt the packet size, instead of using a separate chacha context for that. I think (2) may seem a bit odd, and it means that the chacha-poly1305 implementation needs to expose those bits. But I think it makes sense in the ssh context. In nettle, it could be supported with a variant of chacha_poly1305_set_nonce with some additional argument. And then there's some general issues on how to deal with aead algorithms in the ssh algorithm negotiation, which was designed for separate encryption and mac; those have been discussed on the ietf-ssh list but I don't remember the conclusion, if any. 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
Re: chacha-poly1305
On Fri, Oct 31, 2014 at 2:45 PM, James Cloos wrote: >> "NM" == Niels Möller writes: > NM> Right. Do we need to keep a 64-bit nonce AEAD option? > You do i you want it to be usable for secsh. And probably other > non-(ipsec|tls) protocols. Are you sure that these will not be updated to follow the final document? It would be sad to have protocols following an early draft and others the final. regards, Nikos ___ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: chacha-poly1305
> "NM" == Niels Möller writes: >> 1. Is missing support for 96-bit nonce Chacha (could be solved by adding >> a chacha_set_nonce96 function) NM> Right. Do we need to keep a 64-bit nonce AEAD option? You do i you want it to be usable for secsh. And probably other non-(ipsec|tls) protocols. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 ___ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: chacha-poly1305
Nikos Mavrogiannopoulos writes: > That makes sense. I was trying to figure that out without putting a > conditional into encrypt. I don't think a conditional on entry to chacha_poly1305_encrypt is a big deal (for high performance, one ought to pass several blocks per call anyway). And you can most likely take out the current check "if (!ctx->data_size)", so it shouldn't really add a conditional. About alignment, after a quick look, I think chacha_poly1305_*crypt can call _poly1305_block directly, by-passing the buffering logic in poly1305_update / MD_UPDATE. Except that I'm not sure how to handle a final, partial, block. The poly1305 buffer is then needed only for chacha_poly1305_update, assuming we're going to stick to the convention that _update functions don't impose any block size on the caller. 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
Re: chacha-poly1305
On Sun, 2014-10-26 at 17:20 +0100, Niels Möller wrote: > Nikos Mavrogiannopoulos writes: > > > I was checking what is required for the chacha-poly1305 implementation > > to be kept up to date with the current draft [0], on Last-Call. My > > understanding is that the current implementation: > Thanks for keeping track of this. > > 1. Is missing support for 96-bit nonce Chacha (could be solved by adding > > a chacha_set_nonce96 function) > Right. Do we need to keep a 64-bit nonce AEAD option? No such cipher is defined in the current draft which was published after the last call, so I doubt there will be other than editorial changes to that draft. > > 2. Misses the optimization which you proposed to CFRG (and was > > incorporated). > Should be easy to fix. Ideally, we should also take advantage of the > improved alignment between chacha and poly1305. > > > It seems however, that if nettle is changed for the latter (i.e., to pad > > AAD), then using chacha_poly1305_update() becomes tricky. > What difficulties do you see? As far as I understand, > chacha_poly1305_update can just call poly1305_update, and update the > auth_size field. > Then the first call to chacha_poly1305_*crypt (or chacha_poly1305_digest > if cleartext is empty) can add the needed padding. That makes sense. I was trying to figure that out without putting a conditional into encrypt. regards, Nikos ___ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: chacha-poly1305
Nikos Mavrogiannopoulos writes: > I was checking what is required for the chacha-poly1305 implementation > to be kept up to date with the current draft [0], on Last-Call. My > understanding is that the current implementation: Thanks for keeping track of this. > 1. Is missing support for 96-bit nonce Chacha (could be solved by adding > a chacha_set_nonce96 function) Right. Do we need to keep a 64-bit nonce AEAD option? > 2. Misses the optimization which you proposed to CFRG (and was > incorporated). Should be easy to fix. Ideally, we should also take advantage of the improved alignment between chacha and poly1305. > It seems however, that if nettle is changed for the latter (i.e., to pad > AAD), then using chacha_poly1305_update() becomes tricky. What difficulties do you see? As far as I understand, chacha_poly1305_update can just call poly1305_update, and update the auth_size field. Then the first call to chacha_poly1305_*crypt (or chacha_poly1305_digest if cleartext is empty) can add the needed padding. If this is hard to do, for some reason I'm missing, it ought to be brought up before the spec is done. 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
chacha-poly1305
Hello, I was checking what is required for the chacha-poly1305 implementation to be kept up to date with the current draft [0], on Last-Call. My understanding is that the current implementation: 1. Is missing support for 96-bit nonce Chacha (could be solved by adding a chacha_set_nonce96 function) 2. Misses the optimization which you proposed to CFRG (and was incorporated). It seems however, that if nettle is changed for the latter (i.e., to pad AAD), then using chacha_poly1305_update() becomes tricky. It could only be called once. Would in that case make sense to rename it to chacha_poly1305_set_aad() rather than update? regards, Nikos [0]. https://tools.ietf.org/html/draft-irtf-cfrg-chacha20-poly1305-02 ___ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
