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
Home Page:
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 authenticat
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 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 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()
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
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 gc
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 ava
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 loo
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
o
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 implemen
From: Herbert Xu
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 users aren't broken by
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 nobody
13 matches
Mail list logo
