* AEAD question @ 2019-07-22 12:55 Pascal Van Leeuwen 2019-07-22 16:22 ` Eric Biggers 0 siblings, 1 reply; 8+ messages in thread From: Pascal Van Leeuwen @ 2019-07-22 12:55 UTC (permalink / raw) To: linux-crypto; +Cc: Eric Biggers, Herbert Xu, davem Eric & Herbert, I noticed the testmgr fuzz tester generating (occasionally, see previous mail) tests cases with authsize=0 for the AEAD ciphers. I'm wondering if that is intentional. Or actually, I'm wondering whether that should be considered a legal case. To me, it doesn't seem to make a whole lot of sense to do *authenticated* encryption and then effectively throw away the authentication result ... (it's just a waste of power and/or cycles) The reason for this question is that supporting this requires some specific workaround in my driver (yet again). And yes, I'm aware of the fact that I can advertise I don't support zero length authentication tags, but then probably/likely testmgr will punish me for that instead. Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: AEAD question 2019-07-22 12:55 AEAD question Pascal Van Leeuwen @ 2019-07-22 16:22 ` Eric Biggers 2019-07-22 22:26 ` Pascal Van Leeuwen 0 siblings, 1 reply; 8+ messages in thread From: Eric Biggers @ 2019-07-22 16:22 UTC (permalink / raw) To: Pascal Van Leeuwen; +Cc: linux-crypto, Herbert Xu, davem On Mon, Jul 22, 2019 at 12:55:39PM +0000, Pascal Van Leeuwen wrote: > Eric & Herbert, > > I noticed the testmgr fuzz tester generating (occasionally, see previous mail) tests cases with > authsize=0 for the AEAD ciphers. I'm wondering if that is intentional. Or actually, I'm wondering > whether that should be considered a legal case. > To me, it doesn't seem to make a whole lot of sense to do *authenticated* encryption and then > effectively throw away the authentication result ... (it's just a waste of power and/or cycles) > > The reason for this question is that supporting this requires some specific workaround in my > driver (yet again). And yes, I'm aware of the fact that I can advertise I don't support zero length > authentication tags, but then probably/likely testmgr will punish me for that instead. > As before you're actually talking about the "authenc" template for IPSec and not about AEADs in general, right? I'm not familiar with that algorithm, so you'll have to research what the specification says, and what's actually using it. Using an AEAD with authsize=0 is indeed silly, but perhaps someone using that in some badly designed protocol where authentication is optional. Also AFAICS from the code, any authsize fits naturally into the algorithm; i.e., excluding 0 would be a special case. But again, someone actually has to research this. Maybe crypto_aead_setauthsize() should simply reject authsize=0 for all AEADs. What we should *not* do, IMO, is remove it from the tests and allow implementations to do whatever they want. If it's wrong we should fix it everywhere, so that the behavior is consistent. - Eric ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: AEAD question 2019-07-22 16:22 ` Eric Biggers @ 2019-07-22 22:26 ` Pascal Van Leeuwen 2019-08-06 9:20 ` Pascal Van Leeuwen 0 siblings, 1 reply; 8+ messages in thread From: Pascal Van Leeuwen @ 2019-07-22 22:26 UTC (permalink / raw) To: Eric Biggers; +Cc: linux-crypto, Herbert Xu, davem > -----Original Message----- > From: Eric Biggers <ebiggers@kernel.org> > Sent: Monday, July 22, 2019 6:23 PM > To: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com> > Cc: linux-crypto@vger.kernel.org; Herbert Xu <herbert@gondor.apana.org.au>; davem@davemloft.net > Subject: Re: AEAD question > > On Mon, Jul 22, 2019 at 12:55:39PM +0000, Pascal Van Leeuwen wrote: > > Eric & Herbert, > > > > I noticed the testmgr fuzz tester generating (occasionally, see previous mail) tests cases with > > authsize=0 for the AEAD ciphers. I'm wondering if that is intentional. Or actually, I'm wondering > > whether that should be considered a legal case. > > To me, it doesn't seem to make a whole lot of sense to do *authenticated* encryption and then > > effectively throw away the authentication result ... (it's just a waste of power and/or cycles) > > > > The reason for this question is that supporting this requires some specific workaround in my > > driver (yet again). And yes, I'm aware of the fact that I can advertise I don't support zero length > > authentication tags, but then probably/likely testmgr will punish me for that instead. > > > > As before you're actually talking about the "authenc" template for IPSec and not > about AEADs in general, right? > Hmmm .... for the time being yes. At the time I wrote that, I was still expecting all AEAD's to be somewhat consistent in this respect (as our hardware is), but actually I've just been trying to reverse engineer the GCM template and IIRC it indeed does not allow an authsize of 0. Or anything below 4 bytes, actually. > I'm not familiar with that algorithm, so you'll > have to research what the specification says, and what's actually using it. > To the best of my knowledge, there is no formal specification of any such thing. There are protocols that use it (e.g. IPsec) which have restrictions but other protocols beyond my knowledge may have other restrictions ... 0 seems very unlikely though ... > Using an AEAD with authsize=0 is indeed silly, but perhaps someone using that in > some badly designed protocol where authentication is optional. Also AFAICS from > the code, any authsize fits naturally into the algorithm; i.e., excluding 0 > would be a special case. > Again, looking at the GCM template, excluding certain authsizes is certainly not something out of the ordinary. > But again, someone actually has to research this. Maybe > crypto_aead_setauthsize() should simply reject authsize=0 for all AEADs. > IMHO that would make sense. Without authentication, it's not an AEAD. And actually executing the MAC and then throwing away the *full* result is really silly. More likely to be some programming mistake than actually intended use. (but if someone knows of an actual use case for that, please do correct me) > What we should *not* do, IMO, is remove it from the tests and allow > implementations to do whatever they want. If it's wrong we should fix it > everywhere, so that the behavior is consistent. > Oh, I fully agree there. All implementations should still respond the same. > - Eric Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: AEAD question 2019-07-22 22:26 ` Pascal Van Leeuwen @ 2019-08-06 9:20 ` Pascal Van Leeuwen 2019-08-09 2:57 ` Herbert Xu 0 siblings, 1 reply; 8+ messages in thread From: Pascal Van Leeuwen @ 2019-08-06 9:20 UTC (permalink / raw) To: linux-crypto, Herbert Xu; +Cc: davem, Eric Biggers Herbert, The discussion below still lacks some resolution ... What is boils down to is: what should an authenc AEAD driver do when it gets a setauthsize request of zero? It could either return -EINVAL on the setauthsize request as AEAD with an authsize of zero makes no sense at all and only allowing a limited subset of authsizes seems to be commonplace. Or it could process the request without appending or verifying the authenticator (basically throwing away the authentication result!). I have a strong preference for the former, as the latter would require workarounds in the inside-secure driver for a corner case that does not make any practicle sense (without the authenticator, it is not an AEAD in the first place, why authenticate and throw away the result?), but the current generic implementation does seem to process this. Consistent behavior here is important for the fuzz testing by testmgr. Regards, Pascal > -----Original Message----- > From: linux-crypto-owner@vger.kernel.org <linux-crypto-owner@vger.kernel.org> On Behalf Of > Pascal Van Leeuwen > Sent: Tuesday, July 23, 2019 12:27 AM > To: Eric Biggers <ebiggers@kernel.org> > Cc: linux-crypto@vger.kernel.org; Herbert Xu <herbert@gondor.apana.org.au>; > davem@davemloft.net > Subject: RE: AEAD question > > > -----Original Message----- > > From: Eric Biggers <ebiggers@kernel.org> > > Sent: Monday, July 22, 2019 6:23 PM > > To: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com> > > Cc: linux-crypto@vger.kernel.org; Herbert Xu <herbert@gondor.apana.org.au>; > davem@davemloft.net > > Subject: Re: AEAD question > > > > On Mon, Jul 22, 2019 at 12:55:39PM +0000, Pascal Van Leeuwen wrote: > > > Eric & Herbert, > > > > > > I noticed the testmgr fuzz tester generating (occasionally, see previous mail) tests > cases with > > > authsize=0 for the AEAD ciphers. I'm wondering if that is intentional. Or actually, > I'm wondering > > > whether that should be considered a legal case. > > > To me, it doesn't seem to make a whole lot of sense to do *authenticated* encryption > and then > > > effectively throw away the authentication result ... (it's just a waste of power > and/or cycles) > > > > > > The reason for this question is that supporting this requires some specific workaround > in my > > > driver (yet again). And yes, I'm aware of the fact that I can advertise I don't > support zero length > > > authentication tags, but then probably/likely testmgr will punish me for that instead. > > > > > > > As before you're actually talking about the "authenc" template for IPSec and not > > about AEADs in general, right? > > > Hmmm .... for the time being yes. At the time I wrote that, I was still expecting all > AEAD's to be > somewhat consistent in this respect (as our hardware is), but actually I've just been > trying to > reverse engineer the GCM template and IIRC it indeed does not allow an authsize of 0. > Or anything below 4 bytes, actually. > > > I'm not familiar with that algorithm, so you'll > > have to research what the specification says, and what's actually using it. > > > To the best of my knowledge, there is no formal specification of any such thing. There are > protocols that use it (e.g. IPsec) which have restrictions but other protocols beyond my > knowledge may have other restrictions ... 0 seems very unlikely though ... > > > Using an AEAD with authsize=0 is indeed silly, but perhaps someone using that in > > some badly designed protocol where authentication is optional. Also AFAICS from > > the code, any authsize fits naturally into the algorithm; i.e., excluding 0 > > would be a special case. > > > Again, looking at the GCM template, excluding certain authsizes is certainly not > something out of the ordinary. > > > But again, someone actually has to research this. Maybe > > crypto_aead_setauthsize() should simply reject authsize=0 for all AEADs. > > > IMHO that would make sense. Without authentication, it's not an AEAD. > And actually executing the MAC and then throwing away the *full* result is really > silly. More likely to be some programming mistake than actually intended use. > (but if someone knows of an actual use case for that, please do correct me) > > > What we should *not* do, IMO, is remove it from the tests and allow > > implementations to do whatever they want. If it's wrong we should fix it > > everywhere, so that the behavior is consistent. > > > Oh, I fully agree there. All implementations should still respond the same. > > > - Eric > > Regards, > Pascal van Leeuwen > Silicon IP Architect, Multi-Protocol Engines @ Verimatrix > www.insidesecure.com Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: AEAD question 2019-08-06 9:20 ` Pascal Van Leeuwen @ 2019-08-09 2:57 ` Herbert Xu 0 siblings, 0 replies; 8+ messages in thread From: Herbert Xu @ 2019-08-09 2:57 UTC (permalink / raw) To: Pascal Van Leeuwen; +Cc: linux-crypto, davem, Eric Biggers On Tue, Aug 06, 2019 at 09:20:52AM +0000, Pascal Van Leeuwen wrote: > > The discussion below still lacks some resolution ... > > What is boils down to is: what should an authenc AEAD driver do when it > gets a setauthsize request of zero? It must support zero for the special case of digest_null, which is used to test the IPsec stack. In other cases I'm OK with forbidding the use of zero as the IPsec code won't allow a zero to get through anyway (IOW you can only access this code path via af_alg). Cheers, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ^ permalink raw reply [flat|nested] 8+ messages in thread
* AEAD Question @ 2016-10-26 16:17 Juan Pablo Nariño Mendoza 2016-10-26 16:32 ` Stephan Mueller 0 siblings, 1 reply; 8+ messages in thread From: Juan Pablo Nariño Mendoza @ 2016-10-26 16:17 UTC (permalink / raw) To: linux-crypto Sorry in advance for making what shall be a basic question for this list, but I have really ran out of ideas. Can someone explain me please, how does the memory layout and sg lists work for the IPSec case, with generated IV case? As I understand, it is like this (ascii art) AD | IV Space | Plain Text | Auth Tag ^ ^ | | asg sg But I am having the AD overwritten, and the AUTH tag and encryption is not correct? Could someone please point me in the right direction? Thank you again Regards Juan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: AEAD Question 2016-10-26 16:17 AEAD Question Juan Pablo Nariño Mendoza @ 2016-10-26 16:32 ` Stephan Mueller 2016-10-27 8:05 ` Juan Pablo Nariño Mendoza 0 siblings, 1 reply; 8+ messages in thread From: Stephan Mueller @ 2016-10-26 16:32 UTC (permalink / raw) To: Juan Pablo Nariño Mendoza; +Cc: linux-crypto Am Mittwoch, 26. Oktober 2016, 18:17:14 CEST schrieb Juan Pablo Nariño Mendoza: Hi Juan, > Sorry in advance for making what shall be a basic question for this > list, but I have really ran out of ideas. > > Can someone explain me please, how does the memory layout and sg lists > work for the IPSec case, with generated IV case? > > As I understand, it is like this (ascii art) > > AD | IV Space | Plain Text | Auth Tag > ^ ^ > > asg sg The memory layout is correct when using the RFC4106 cipher. How you partition your physical memory with the SGL is your choice as long as your data in the SGL is lined up as you mentioned above. > > But I am having the AD overwritten, and the AUTH tag and encryption is > not correct? Could someone please point me in the right direction? > Thank you again Maybe the src and dst SGL somehow partially overlap? > > Regards > > Juan > -- > To unsubscribe from this list: send the line "unsubscribe linux-crypto" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Ciao Stephan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: AEAD Question 2016-10-26 16:32 ` Stephan Mueller @ 2016-10-27 8:05 ` Juan Pablo Nariño Mendoza 0 siblings, 0 replies; 8+ messages in thread From: Juan Pablo Nariño Mendoza @ 2016-10-27 8:05 UTC (permalink / raw) To: Stephan Mueller; +Cc: linux-crypto Hello Stephan Thank you for your fast answer My idea is to do zero copy encryption and the cipher I am using is authenc(hmac(sha1),cbc(aes). The layout of my buffer is espHeader(AD) || IV || plaintext || Integrity (TAG) As I see it, the SGs do point to the same buffer, but they do not overlap Below, some parts of my code // Prepare data sg_init_table(sg,ARRAY_SIZE(sg)); sg_set_buf(&sg[1],cipherText_p,espHdrLen); sg_set_buf(&sg[0],cipherText_p+espHdrLen+ivLen,plen+intLen); // Put plaintext in cipherText + espHdr + ivLen // put esp header info in ciphertext req_p = aead_givcrypt_alloc(aead_p,GFP_KERNEL); aead_givcrypt_set_callback(req_p,0,hwencpoc_testCipher_cb,cipherText_p); aead_givcrypt_set_crypt(req_p,&sg[0],&sg[0],plen,iv_p); aead_givcrypt_set_assoc(req_p,&sg[1],espHdrLen); aead_givcrypt_set_giv(req_p,cipherText_p+espHdrLen,0); ret=crypto_aead_givencrypt(req_p); However, when I get the callback, the associated data has been overwritten (first 8 bytes of the cipherText buffer), and the integrity is wrong. The IV and the encryption are correct. What I am doing wrong? Thank you again Juan 2016-10-26 18:32 GMT+02:00 Stephan Mueller <smueller@chronox.de>: > Am Mittwoch, 26. Oktober 2016, 18:17:14 CEST schrieb Juan Pablo Nariño > Mendoza: > > Hi Juan, > >> Sorry in advance for making what shall be a basic question for this >> list, but I have really ran out of ideas. >> >> Can someone explain me please, how does the memory layout and sg lists >> work for the IPSec case, with generated IV case? >> >> As I understand, it is like this (ascii art) >> >> AD | IV Space | Plain Text | Auth Tag >> ^ ^ >> >> asg sg > > The memory layout is correct when using the RFC4106 cipher. > > How you partition your physical memory with the SGL is your choice as long as > your data in the SGL is lined up as you mentioned above. >> >> But I am having the AD overwritten, and the AUTH tag and encryption is >> not correct? Could someone please point me in the right direction? >> Thank you again > > Maybe the src and dst SGL somehow partially overlap? >> >> Regards >> >> Juan >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Ciao > Stephan ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-08-09 2:57 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-07-22 12:55 AEAD question Pascal Van Leeuwen 2019-07-22 16:22 ` Eric Biggers 2019-07-22 22:26 ` Pascal Van Leeuwen 2019-08-06 9:20 ` Pascal Van Leeuwen 2019-08-09 2:57 ` Herbert Xu -- strict thread matches above, loose matches on Subject: below -- 2016-10-26 16:17 AEAD Question Juan Pablo Nariño Mendoza 2016-10-26 16:32 ` Stephan Mueller 2016-10-27 8:05 ` Juan Pablo Nariño Mendoza
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).