netdev - Re: [PATCH net-next 0/2] Removal of struct esp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131022130822.GA26207@secunet.com>
Date:	Tue, 22 Oct 2013 15:08:22 +0200
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	David Miller <davem@...emloft.net>
Cc:	mathias.krause@...unet.com, netdev@...r.kernel.org,
	herbert@...dor.apana.org.au
Subject: Re: [PATCH net-next 0/2] Removal of struct esp_data

On Fri, Oct 18, 2013 at 01:55:36PM -0400, David Miller wrote:
> From: Mathias Krause <mathias.krause@...unet.com>
> Date: Fri, 18 Oct 2013 12:09:03 +0200
> 
> > This series removes one level of indirection when accessing the aead
> > crypto algorithm in ESP transforms by simply removing struct esp_data.
> > This results in smaller code and less memory usage per xfrm state.
> > 
> > Please apply!
> 
> No objections from me, I'll let Steffen pick this up.

I'm a bit hesitating with removing the padlen field. We resisted
several attempts to remove it in the past. It is currenly unused,
but it provides the infrastructure for ESP padding as defined
in RFC 4303. However, RFC 4303 recommends the use of TFC padding
instead to conceal the actual length of the packet. So I'm not
sure what's the actual usecase for ESP padding. I'll reconsider
this next week when I'm back at office.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html