On 04/23/2015 07:45 AM, Steffen Klassert wrote:
On Thu, Apr 23, 2015 at 11:26:20AM +0800, Herbert Xu wrote:
Hi:
It looks like our IPsec implementations of CCM and GCM are buggy
in that they don't include the IV in the authentication calculation.
Seems like crypto_rfc4106_crypt() passes the
On Thu, Apr 23, 2015 at 03:24:59PM +0200, Martin Willi wrote:
Do you have any pointer for me where this is defined? Why is it needed,
given that GCM implicitly authenticates the IV by using it in Y0?
The IV if present must be covered by the ICV. This is required
by RFC4303 (section 2). But
On Thu, Apr 23, 2015 at 01:45:34PM +0200, Steffen Klassert wrote:
Adding a second template for the correct implementation is
probaply the only thing that we can do if we don't want to
break backwards compatibility. But maybe we can add a warning
to the old implementation, such that users
On Thu, Apr 23, 2015 at 12:03:38PM +0300, Horia Geantă wrote:
This applies also to GMAC (rfc4543), right?
No RFC4543 appears to be correctly implemented.
Does this mean that even the test vectors (crypto/testmgr.h) are broken?
Indeed. The test vectors appear to be generated either through
On 4/23/2015 6:26 AM, Herbert Xu wrote:
Hi:
It looks like our IPsec implementations of CCM and GCM are buggy
This applies also to GMAC (rfc4543), right?
in that they don't include the IV in the authentication calculation.
This definitely breaks interoperability with anyone who implements
Hi Herbert,
Does this mean that even the test vectors (crypto/testmgr.h) are broken?
Indeed. The test vectors appear to be generated either through
our implementation or by one that is identical to us.
I'm not sure about that. RFC4106 refers to [1] for test vectors, which
is still
On Thu, Apr 23, 2015 at 11:58:52AM +0200, Martin Willi wrote:
I'm not sure about that. RFC4106 refers to [1] for test vectors, which
is still available at web.archive.org [2].
When looking for example at Test Case 3, this is the same as in a newer
revision of the document [3]. That looks
Hi Steffen,
It looks like our IPsec implementations of CCM and GCM are buggy
in that they don't include the IV in the authentication calculation.
Seems like crypto_rfc4106_crypt() passes the associated data it
got from ESP directly to gcm, without chaining with the IV.
Do you have any
On Thu, Apr 23, 2015 at 11:26:20AM +0800, Herbert Xu wrote:
Hi:
It looks like our IPsec implementations of CCM and GCM are buggy
in that they don't include the IV in the authentication calculation.
Seems like crypto_rfc4106_crypt() passes the associated data it
got from ESP directly to gcm,
On Thu, Apr 23, 2015 at 03:24:59PM +0200, Martin Willi wrote:
Do you have any pointer for me where this is defined? Why is it needed,
given that GCM implicitly authenticates the IV by using it in Y0?
Actually you're quite right. Both GCM and CCM implicitly includes
the IV in the
On Fri, Apr 24, 2015 at 01:30:00PM +0800, Herbert Xu wrote:
Now we just need to figre out whether we're still OK with RFC4543.
Looks like we're OK here too as the diagram in section 3.5 says
that the IV should be included in the AAD.
So we're all good!
Thanks,
--
Email: Herbert Xu
Hi:
It looks like our IPsec implementations of CCM and GCM are buggy
in that they don't include the IV in the authentication calculation.
This definitely breaks interoperability with anyone who implements
them correctly. The fact that there have been no reports on this
probably means that
From: Herbert Xu herb...@gondor.apana.org.au
Date: Thu, 23 Apr 2015 11:26:20 +0800
In order to fix this without breaking backwards compatibility,
my plan is to introduce new templates such as rfc4106v2 which
implement the RFC correctly. The existing templates will be
retained so that current
13 matches
Mail list logo
