netdev - Re: [PATCH iproute2-next v2] man8: ip-sr: Document that passphrase must be high-entropy

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] [day] [month] [year] [list]

Message-ID: <20250823000826.GA1336@quark>
Date: Fri, 22 Aug 2025 20:08:26 -0400
From: Eric Biggers <ebiggers@...nel.org>
To: Paolo Lungaroni <paolo.lungaroni@...roma2.it>
Cc: Andrea Mayer <andrea.mayer@...roma2.it>,
	Stephen Hemminger <stephen@...workplumber.org>,
	netdev@...r.kernel.org, David Ahern <dsahern@...il.com>,
	David Lebrun <dlebrun@...gle.com>, stefano.salsano@...roma2.it
Subject: Re: [PATCH iproute2-next v2] man8: ip-sr: Document that passphrase
 must be high-entropy

On Sat, Aug 23, 2025 at 01:39:22AM +0200, Paolo Lungaroni wrote:
> > 
> > Passwords and keys don't belong on the command line, since command lines
> > are often visible to all users.  Standard input is the correct way to do
> > it.  The issue you seem to referring to is that the command currently
> > works only when standard input is a tty.  It should of course be fixed
> > to work for any file, which would allow automation via something like
> > 'ip sr hmac set 17 sha256 < passphrase.txt'.  (And to be clear, that's a
> > separate issue from the lack of passphrase stretching.)
> > 
> > When giving example commands, please also use sha256 instead of sha1.
> > 
> > - Eric
> 
> Ciao Eric,
> 
> The scheme I followed to develop my patch proposal is inspired by the one
> already present in ip xfrm and ip macsec.
> These two features require the configuration of key entered inline in the
> command prompt.

Well, then those are wrong too.

> Regarding your statement: 'And to be clear, that's a separate issue from the
> lack of passphrase stretching,' yes, you're right: they are indeed separate.
> 
> According to RFC8754, 'The pre-shared key identified by HMAC Key ID' is used
> as
> is in the HMAC computation.
> 
> I'm trying to understand how 'stretching the passphrase' could work with other
> network appliances that are not Linux. Stretching the passphrase only in the
> Linux implementation seems to make it incompatible with RFC8754 and,
> consequently, with other software and hardware that implement Segment Routing
> over IPv6 HMAC.

The RFC just says there is a pre-shared HMAC key.  How it is generated
and shared is outside the scope of the RFC.

> As an example, at the computation level, I need to use the same key when
> communicating with hardware routers and when calculating an HMAC that the
> hardware device can verify. If we implement passphrase stretching in Linux,
> what would be the input string I should provide in iproute2 to ensure that the
> same key used in the hardware device (which does not perform passphrase
> stretching) is used?

The key stretching should of course be in userspace, not the kernel.

> Could you please clarify what you intend to do

Nothing.  I don't care about this feature myself.  I'm just letting the
people who do care about this feature know about this security bug that
I happened to notice.  If they don't care either, then oh well.

- Eric