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
Nikos Mavrogiannopoulos nmav@gnutls.org 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.
- 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?
- 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
On Sun, 2014-10-26 at 17:20 +0100, Niels Möller wrote:
Nikos Mavrogiannopoulos nmav@gnutls.org 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.
- 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.
- 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
Nikos Mavrogiannopoulos nmav@gnutls.org 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
"NM" == Niels Möller nisse@lysator.liu.se writes:
- 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
On Fri, Oct 31, 2014 at 2:45 PM, James Cloos cloos@jhcloos.com wrote:
"NM" == Niels Möller nisse@lysator.liu.se 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
Nikos Mavrogiannopoulos nmav@gnutls.org 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
"NM" == Nikos Mavrogiannopoulos nmav@gnutls.org 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 cloos@jhcloos.com 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
nettle-bugs@lists.lysator.liu.se
-
James Cloos -
Nikos Mavrogiannopoulos -
nisse＠lysator.liu.se