Date: Wed, 29 Jul 2015 12:57:53 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Ermal =?iso-8859-1?Q?Lu=E7i?= <eri@freebsd.org> Cc: George Neville-Neil <gnn@neville-neil.com>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r286000 - head/sys/netipsec Message-ID: <20150729195753.GM78154@funkthat.com> In-Reply-To: <CAPBZQG2d88MKwzd9wG_xUGyLJ0jMhP3aUM2VZhzd4RmA31WMBw@mail.gmail.com> References: <201507290715.t6T7FHGb094456@repo.freebsd.org> <CAPBZQG3GS-wzEohLY8=Jewz_2JiFkAbArxKMFPxMz4JFg34_Hg@mail.gmail.com> <20150729154036.GG78154@funkthat.com> <CAPBZQG2d88MKwzd9wG_xUGyLJ0jMhP3aUM2VZhzd4RmA31WMBw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ermal Lui wrote this message on Wed, Jul 29, 2015 at 19:23 +0200: > On Wed, Jul 29, 2015 at 5:40 PM, John-Mark Gurney <jmg@funkthat.com> wrote: > > > Ermal Lui wrote this message on Wed, Jul 29, 2015 at 14:53 +0200: > > > this was forgotten part on my patches merge from gnn@. > > > Can it be fixed by correcting the patches rather than re-introducing > > this? > > > > > > Most probably the constant definition is wrong on the transforms and also > > > some part of code removal was missed. > > > > No, it cannot be fixed by changing opencrypto/xform.c to truncate the > > hash size... The reason it cannot be is that OCF is not an IPsec only > > framework... > > > > Geli also uses the HMAC constructions, and I have not confirmed if they > > use the full hash size or not... I would be open to adding a field to > > the crypto descriptor that limited how much of the hash is copied out... > > > > It would have been helpful to comment more of these changes... If you > > make a change for a reason (RFC, etc), then throw that in the comments, > > which allows someone following to understand why and prevent their > > removal... At least if they were commented as to why they changed, we > > would have known to rework the change... > > > Yes you are right but according to me this is standard practice being done > allover SSL/IPSec.... > I am not sure which standard GELI follows to comment on that! This also depends upon all future protocols following that standard, and no one needing those extra bits for validation, etc. > Also then it would be better to review the declarations on the transform > since they are apparently not generic, no? The declarations in xform.c need to be what the algorithm specifies, not what gets used by the various protocols... Any deviation from the algorithm specification should be delt with in protocol code, not here... This prevenst a future problem where a prtocol doesn't use that convention, and then it becomes a mess to unwind where these changes were, and fix them all... It's stuff like this which is part of the reason I decided to call GCM, NIST_GCM... OpenBSD has a hacked version that is only good for IPsec, apparently TLS and anything else that does the crazy lets put part of the IV w/ the key... The xform tables are already terribly overloaded, and I wanted to split them out into parameters and implementation, but because IPsec and others reach into those tables, it makes it more difficult... > > > On Wed, Jul 29, 2015 at 9:15 AM, John-Mark Gurney <jmg@freebsd.org> > > wrote: > > > > > > > Author: jmg > > > > Date: Wed Jul 29 07:15:16 2015 > > > > New Revision: 286000 > > > > URL: https://svnweb.freebsd.org/changeset/base/286000 > > > > > > > > Log: > > > > RFC4868 section 2.3 requires that the output be half... This fixes > > > > problems that was introduced in r285336... I have verified that > > > > HMAC-SHA2-256 both ah only and w/ AES-CBC interoperate w/ a NetBSD > > > > 6.1.5 vm... > > > > > > > > Reviewed by: gnn -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150729195753.GM78154>