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

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

[Eric Biggers]

'ip sr hmac set' takes a newline-terminated "passphrase", but it fails
to stretch it.  The "passphrase" actually gets used directly as the key.
This makes it difficult to use securely.

I recommend deprecating this command and replacing it with a command
that either stretches the passphrase or explicitly takes a key instead
of a passphrase.  But for now, let's at least document this pitfall.

Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---

v2: use better example command for key generation

 man/man8/ip-sr.8 | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/man/man8/ip-sr.8 b/man/man8/ip-sr.8
index 6be1cc54..cd8c5d18 100644
--- a/man/man8/ip-sr.8
+++ b/man/man8/ip-sr.8
@@ -1,6 +1,6 @@
-.TH IP\-SR 8 "14 Apr 2017" "iproute2" "Linux"
+.TH IP\-SR 8 "15 Aug 2025" "iproute2" "Linux"
 .SH "NAME"
 ip-sr \- IPv6 Segment Routing management
 .SH SYNOPSIS
 .sp
 .ad l
@@ -32,13 +32,21 @@ internal parameters.
 .PP
 Those parameters include the mapping between an HMAC key ID and its associated
 hashing algorithm and secret, and the IPv6 address to use as source for encapsulated
 packets.
 .PP
-The \fBip sr hmac set\fR command prompts for a passphrase that will be used as the
-HMAC secret for the corresponding key ID. A blank passphrase removes the mapping.
-The currently supported algorithms for \fIALGO\fR are \fBsha1\fR and \fBsha256\fR.
+The \fBip sr hmac set\fR command prompts for a newline-terminated "passphrase"
+that will be used as the HMAC secret for the corresponding key ID. This
+"passphrase" is \fInot\fR stretched, and it is used directly as the HMAC key.
+Therefore it \fImust\fR have enough entropy to be used as a key. For example, a
+correct use would be to use a passphrase that was generated using
+\fBhead\~-c\~32\~/dev/urandom\~|\~base64\~-w\~0\fR.
+.PP
+A blank "passphrase" removes the mapping.
+.PP
+The currently supported algorithms for \fIALGO\fR are \fBsha1\fR and
+\fBsha256\fR.
 .PP
 If the tunnel source is set to the address :: (which is the default), then an address
 of the egress interface will be selected. As this operation may hinder performances,
 it is recommended to set a non-default address.
 
@@ -52,7 +60,11 @@ it is recommended to set a non-default address.
 .nf
 # ip sr tunsrc set 2001:db8::1
 .SH SEE ALSO
 .br
 .BR ip-route (8)
+
+.SH BUGS
+\fBip sr hmac set\fR does not stretch the passphrase.
+
 .SH AUTHOR
 David Lebrun <david.lebrun@uclouvain.be>

base-commit: 0ad8fef322365b7bafd052f416fc972bea49d362
-- 
2.50.1

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

[Stephen Hemminger]

On Fri, 15 Aug 2025 20:18:46 -0700
Eric Biggers <ebiggers@kernel.org> wrote:

> diff --git a/man/man8/ip-sr.8 b/man/man8/ip-sr.8
> index 6be1cc54..cd8c5d18 100644
> --- a/man/man8/ip-sr.8
> +++ b/man/man8/ip-sr.8
> @@ -1,6 +1,6 @@
> -.TH IP\-SR 8 "14 Apr 2017" "iproute2" "Linux"
> +.TH IP\-SR 8 "15 Aug 2025" "iproute2" "Linux"

NAK - do not change man page date for each change.

>  .SH "NAME"
>  ip-sr \- IPv6 Segment Routing management
>  .SH SYNOPSIS
>  .sp
>  .ad l
> @@ -32,13 +32,21 @@ internal parameters.
>  .PP
>  Those parameters include the mapping between an HMAC key ID and its associated
>  hashing algorithm and secret, and the IPv6 address to use as source for encapsulated
>  packets.
>  .PP
> -The \fBip sr hmac set\fR command prompts for a passphrase that will be used as the
> -HMAC secret for the corresponding key ID. A blank passphrase removes the mapping.
> -The currently supported algorithms for \fIALGO\fR are \fBsha1\fR and \fBsha256\fR.
> +The \fBip sr hmac set\fR command prompts for a newline-terminated "passphrase"

That implies that newline is part of the pass phrase.
The code to read password is using getpass() which is marked as obsolete
in glibc. readpassphrase is preferred.

> +that will be used as the HMAC secret for the corresponding key ID. This
> +"passphrase" is \fInot\fR stretched, and it is used directly as the HMAC key.
> +Therefore it \fImust\fR have enough entropy to be used as a key. For example, a
> +correct use would be to use a passphrase that was generated using
> +\fBhead\~-c\~32\~/dev/urandom\~|\~base64\~-w\~0\fR.

Shouldn't /dev/random be used instead of /dev/urandom for keys.
Also, I would prefer original author evaluate this

> +.PP
> +A blank "passphrase" removes the mapping.
> +.PP
> +The currently supported algorithms for \fIALGO\fR are \fBsha1\fR and
> +\fBsha256\fR.

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

[Eric Biggers]

On Wed, Aug 20, 2025 at 09:25:35AM -0700, Stephen Hemminger wrote:
> On Fri, 15 Aug 2025 20:18:46 -0700
> Eric Biggers <ebiggers@kernel.org> wrote:
> 
> > diff --git a/man/man8/ip-sr.8 b/man/man8/ip-sr.8
> > index 6be1cc54..cd8c5d18 100644
> > --- a/man/man8/ip-sr.8
> > +++ b/man/man8/ip-sr.8
> > @@ -1,6 +1,6 @@
> > -.TH IP\-SR 8 "14 Apr 2017" "iproute2" "Linux"
> > +.TH IP\-SR 8 "15 Aug 2025" "iproute2" "Linux"
> 
> NAK - do not change man page date for each change.

Sure, if that's the convention for this project.  Note that this differs
from the convention used by most projects with dated man pages.  The
purpose of the date is normally to indicate how fresh the man page is.

> >  .SH "NAME"
> >  ip-sr \- IPv6 Segment Routing management
> >  .SH SYNOPSIS
> >  .sp
> >  .ad l
> > @@ -32,13 +32,21 @@ internal parameters.
> >  .PP
> >  Those parameters include the mapping between an HMAC key ID and its associated
> >  hashing algorithm and secret, and the IPv6 address to use as source for encapsulated
> >  packets.
> >  .PP
> > -The \fBip sr hmac set\fR command prompts for a passphrase that will be used as the
> > -HMAC secret for the corresponding key ID. A blank passphrase removes the mapping.
> > -The currently supported algorithms for \fIALGO\fR are \fBsha1\fR and \fBsha256\fR.
> > +The \fBip sr hmac set\fR command prompts for a newline-terminated "passphrase"
> 
> That implies that newline is part of the pass phrase.

Not really.  "NUL-terminated" strings don't include the NUL in the
string content.  If you prefer, it could be made explicit as follows:

    The \fBip sr hmac set\fR command prompts for a "passphrase" that
    will be used as the HMAC secret for the corresponding key ID. The
    passphrase is terminated by a newline, but the terminating newline
    is not included in the resulting passphrase.

But I don't think it's very useful, as it's not needed to know how to
use the command correctly.

> The code to read password is using getpass() which is marked as obsolete
> in glibc. readpassphrase is preferred.

Is that relevant to this documentation patch?

> > +that will be used as the HMAC secret for the corresponding key ID. This
> > +"passphrase" is \fInot\fR stretched, and it is used directly as the HMAC key.
> > +Therefore it \fImust\fR have enough entropy to be used as a key. For example, a
> > +correct use would be to use a passphrase that was generated using
> > +\fBhead\~-c\~32\~/dev/urandom\~|\~base64\~-w\~0\fR.
> 
> Shouldn't /dev/random be used instead of /dev/urandom for keys.

If you prefer that as the maintainer of this code, sure.  There are
reasons to use either one, and it's been an endless debate for years.

- Eric

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

[Stephen Hemminger]

On Wed, 20 Aug 2025 11:43:17 -0700
Eric Biggers <ebiggers@kernel.org> wrote:

> On Wed, Aug 20, 2025 at 09:25:35AM -0700, Stephen Hemminger wrote:
> > On Fri, 15 Aug 2025 20:18:46 -0700
> > Eric Biggers <ebiggers@kernel.org> wrote:
> >   
> > > diff --git a/man/man8/ip-sr.8 b/man/man8/ip-sr.8
> > > index 6be1cc54..cd8c5d18 100644
> > > --- a/man/man8/ip-sr.8
> > > +++ b/man/man8/ip-sr.8
> > > @@ -1,6 +1,6 @@
> > > -.TH IP\-SR 8 "14 Apr 2017" "iproute2" "Linux"
> > > +.TH IP\-SR 8 "15 Aug 2025" "iproute2" "Linux"  
> > 
> > NAK - do not change man page date for each change.  
> 
> Sure, if that's the convention for this project.  Note that this differs
> from the convention used by most projects with dated man pages.  The
> purpose of the date is normally to indicate how fresh the man page is.
> 
> > >  .SH "NAME"
> > >  ip-sr \- IPv6 Segment Routing management
> > >  .SH SYNOPSIS
> > >  .sp
> > >  .ad l
> > > @@ -32,13 +32,21 @@ internal parameters.
> > >  .PP
> > >  Those parameters include the mapping between an HMAC key ID and its associated
> > >  hashing algorithm and secret, and the IPv6 address to use as source for encapsulated
> > >  packets.
> > >  .PP
> > > -The \fBip sr hmac set\fR command prompts for a passphrase that will be used as the
> > > -HMAC secret for the corresponding key ID. A blank passphrase removes the mapping.
> > > -The currently supported algorithms for \fIALGO\fR are \fBsha1\fR and \fBsha256\fR.
> > > +The \fBip sr hmac set\fR command prompts for a newline-terminated "passphrase"  
> > 
> > That implies that newline is part of the pass phrase.  
> 
> Not really.  "NUL-terminated" strings don't include the NUL in the
> string content.  If you prefer, it could be made explicit as follows:
> 
>     The \fBip sr hmac set\fR command prompts for a "passphrase" that
>     will be used as the HMAC secret for the corresponding key ID. The
>     passphrase is terminated by a newline, but the terminating newline
>     is not included in the resulting passphrase.
> 
> But I don't think it's very useful, as it's not needed to know how to
> use the command correctly.
> 
> > The code to read password is using getpass() which is marked as obsolete
> > in glibc. readpassphrase is preferred.  
> 
> Is that relevant to this documentation patch?
> 
> > > +that will be used as the HMAC secret for th

Since this is only part of iproute2 that uses getpass() probably should
be rethought. Having key come from terminal seems hard to script
and awkward.

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

[Andrea Mayer]

On Wed, 20 Aug 2025 12:54:58 -0700
Stephen Hemminger <stephen@networkplumber.org> wrote:

> On Wed, 20 Aug 2025 11:43:17 -0700
> Eric Biggers <ebiggers@kernel.org> wrote:
> 
> > On Wed, Aug 20, 2025 at 09:25:35AM -0700, Stephen Hemminger wrote:
> > > On Fri, 15 Aug 2025 20:18:46 -0700
> > > Eric Biggers <ebiggers@kernel.org> wrote:
> > >   
> > > > diff --git a/man/man8/ip-sr.8 b/man/man8/ip-sr.8
> > > > index 6be1cc54..cd8c5d18 100644
> > > > --- a/man/man8/ip-sr.8
> > > > +++ b/man/man8/ip-sr.8
> > > > @@ -1,6 +1,6 @@
> > > > -.TH IP\-SR 8 "14 Apr 2017" "iproute2" "Linux"
> > > > +.TH IP\-SR 8 "15 Aug 2025" "iproute2" "Linux"  
> > > 
> > > NAK - do not change man page date for each change.  
> > 
> > Sure, if that's the convention for this project.  Note that this differs
> > from the convention used by most projects with dated man pages.  The
> > purpose of the date is normally to indicate how fresh the man page is.
> > 
> > > >  .SH "NAME"
> > > >  ip-sr \- IPv6 Segment Routing management
> > > >  .SH SYNOPSIS
> > > >  .sp
> > > >  .ad l
> > > > @@ -32,13 +32,21 @@ internal parameters.
> > > >  .PP
> > > >  Those parameters include the mapping between an HMAC key ID and its associated
> > > >  hashing algorithm and secret, and the IPv6 address to use as source for encapsulated
> > > >  packets.
> > > >  .PP
> > > > -The \fBip sr hmac set\fR command prompts for a passphrase that will be used as the
> > > > -HMAC secret for the corresponding key ID. A blank passphrase removes the mapping.
> > > > -The currently supported algorithms for \fIALGO\fR are \fBsha1\fR and \fBsha256\fR.
> > > > +The \fBip sr hmac set\fR command prompts for a newline-terminated "passphrase"  
> > > 
> > > That implies that newline is part of the pass phrase.  
> > 
> > Not really.  "NUL-terminated" strings don't include the NUL in the
> > string content.  If you prefer, it could be made explicit as follows:
> > 
> >     The \fBip sr hmac set\fR command prompts for a "passphrase" that
> >     will be used as the HMAC secret for the corresponding key ID. The
> >     passphrase is terminated by a newline, but the terminating newline
> >     is not included in the resulting passphrase.
> > 
> > But I don't think it's very useful, as it's not needed to know how to
> > use the command correctly.
> > 
> > > The code to read password is using getpass() which is marked as obsolete
> > > in glibc. readpassphrase is preferred.  
> > 
> > Is that relevant to this documentation patch?
> > 
> > > > +that will be used as the HMAC secret for th
> 
> Since this is only part of iproute2 that uses getpass() probably should
> be rethought. Having key come from terminal seems hard to script
> and awkward.

Hi Stephen,

Recently, I started working on implementing some self-tests for SRv6 on HMAC.
The command:

  ip sr hmac set <keyid> <algo>

uses getpass() internally, as you mentioned earlier, which can be inconvenient
for automation.

To address this, Paolo Lungaroni has extended the command to support an
additional parameter called "secret" (this is within our internal fork of
iproute2):

  ip sr hmac set 17 sha1 secret <your-secret>

This enhancement allows the secret to be specified directly on the command
line, making it much more convenient for scripting and automated testing
environments.
If the "secret" parameter is not provided, the command will continue to behave
as before, prompting for the passphrase interactively (i.e., the legacy
behavior; we haven't modified the getpass() function, but we can consider to
update it).

If you're interested, I can reach out to Paolo Lungaroni, the author of this
patchset, tomorrow morning (CEST) and ask him to prepare everything for
submission, including updates to the man page.

Andrea

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

[Eric Biggers]

On Thu, Aug 21, 2025 at 12:07:43AM +0200, Andrea Mayer wrote:
> On Wed, 20 Aug 2025 12:54:58 -0700
> Stephen Hemminger <stephen@networkplumber.org> wrote:
> 
> > On Wed, 20 Aug 2025 11:43:17 -0700
> > Eric Biggers <ebiggers@kernel.org> wrote:
> > 
> > > On Wed, Aug 20, 2025 at 09:25:35AM -0700, Stephen Hemminger wrote:
> > > > On Fri, 15 Aug 2025 20:18:46 -0700
> > > > Eric Biggers <ebiggers@kernel.org> wrote:
> > > >   
> > > > > diff --git a/man/man8/ip-sr.8 b/man/man8/ip-sr.8
> > > > > index 6be1cc54..cd8c5d18 100644
> > > > > --- a/man/man8/ip-sr.8
> > > > > +++ b/man/man8/ip-sr.8
> > > > > @@ -1,6 +1,6 @@
> > > > > -.TH IP\-SR 8 "14 Apr 2017" "iproute2" "Linux"
> > > > > +.TH IP\-SR 8 "15 Aug 2025" "iproute2" "Linux"  
> > > > 
> > > > NAK - do not change man page date for each change.  
> > > 
> > > Sure, if that's the convention for this project.  Note that this differs
> > > from the convention used by most projects with dated man pages.  The
> > > purpose of the date is normally to indicate how fresh the man page is.
> > > 
> > > > >  .SH "NAME"
> > > > >  ip-sr \- IPv6 Segment Routing management
> > > > >  .SH SYNOPSIS
> > > > >  .sp
> > > > >  .ad l
> > > > > @@ -32,13 +32,21 @@ internal parameters.
> > > > >  .PP
> > > > >  Those parameters include the mapping between an HMAC key ID and its associated
> > > > >  hashing algorithm and secret, and the IPv6 address to use as source for encapsulated
> > > > >  packets.
> > > > >  .PP
> > > > > -The \fBip sr hmac set\fR command prompts for a passphrase that will be used as the
> > > > > -HMAC secret for the corresponding key ID. A blank passphrase removes the mapping.
> > > > > -The currently supported algorithms for \fIALGO\fR are \fBsha1\fR and \fBsha256\fR.
> > > > > +The \fBip sr hmac set\fR command prompts for a newline-terminated "passphrase"  
> > > > 
> > > > That implies that newline is part of the pass phrase.  
> > > 
> > > Not really.  "NUL-terminated" strings don't include the NUL in the
> > > string content.  If you prefer, it could be made explicit as follows:
> > > 
> > >     The \fBip sr hmac set\fR command prompts for a "passphrase" that
> > >     will be used as the HMAC secret for the corresponding key ID. The
> > >     passphrase is terminated by a newline, but the terminating newline
> > >     is not included in the resulting passphrase.
> > > 
> > > But I don't think it's very useful, as it's not needed to know how to
> > > use the command correctly.
> > > 
> > > > The code to read password is using getpass() which is marked as obsolete
> > > > in glibc. readpassphrase is preferred.  
> > > 
> > > Is that relevant to this documentation patch?
> > > 
> > > > > +that will be used as the HMAC secret for th
> > 
> > Since this is only part of iproute2 that uses getpass() probably should
> > be rethought. Having key come from terminal seems hard to script
> > and awkward.
> 
> Hi Stephen,
> 
> Recently, I started working on implementing some self-tests for SRv6 on HMAC.
> The command:
> 
>   ip sr hmac set <keyid> <algo>
> 
> uses getpass() internally, as you mentioned earlier, which can be inconvenient
> for automation.
> 
> To address this, Paolo Lungaroni has extended the command to support an
> additional parameter called "secret" (this is within our internal fork of
> iproute2):
> 
>   ip sr hmac set 17 sha1 secret <your-secret>
> 
> This enhancement allows the secret to be specified directly on the command
> line, making it much more convenient for scripting and automated testing
> environments.
> If the "secret" parameter is not provided, the command will continue to behave
> as before, prompting for the passphrase interactively (i.e., the legacy
> behavior; we haven't modified the getpass() function, but we can consider to
> update it).
> 
> If you're interested, I can reach out to Paolo Lungaroni, the author of this
> patchset, tomorrow morning (CEST) and ask him to prepare everything for
> submission, including updates to the man page.

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

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

[Paolo Lungaroni]

Eric Biggers <ebiggers@kernel.org> ha scritto:

> On Thu, Aug 21, 2025 at 12:07:43AM +0200, Andrea Mayer wrote:
>> On Wed, 20 Aug 2025 12:54:58 -0700
>> Stephen Hemminger <stephen@networkplumber.org> wrote:
>>
>> > On Wed, 20 Aug 2025 11:43:17 -0700
>> > Eric Biggers <ebiggers@kernel.org> wrote:
>> >
>> > > On Wed, Aug 20, 2025 at 09:25:35AM -0700, Stephen Hemminger wrote:
>> > > > On Fri, 15 Aug 2025 20:18:46 -0700
>> > > > Eric Biggers <ebiggers@kernel.org> wrote:
>> > > >
>> > > > > diff --git a/man/man8/ip-sr.8 b/man/man8/ip-sr.8
>> > > > > index 6be1cc54..cd8c5d18 100644
>> > > > > --- a/man/man8/ip-sr.8
>> > > > > +++ b/man/man8/ip-sr.8
>> > > > > @@ -1,6 +1,6 @@
>> > > > > -.TH IP\-SR 8 "14 Apr 2017" "iproute2" "Linux"
>> > > > > +.TH IP\-SR 8 "15 Aug 2025" "iproute2" "Linux"
>> > > >
>> > > > NAK - do not change man page date for each change.
>> > >
>> > > Sure, if that's the convention for this project.  Note that this differs
>> > > from the convention used by most projects with dated man pages.  The
>> > > purpose of the date is normally to indicate how fresh the man page is.
>> > >
>> > > > >  .SH "NAME"
>> > > > >  ip-sr \- IPv6 Segment Routing management
>> > > > >  .SH SYNOPSIS
>> > > > >  .sp
>> > > > >  .ad l
>> > > > > @@ -32,13 +32,21 @@ internal parameters.
>> > > > >  .PP
>> > > > >  Those parameters include the mapping between an HMAC key  
>> ID and its associated
>> > > > >  hashing algorithm and secret, and the IPv6 address to use  
>> as source for encapsulated
>> > > > >  packets.
>> > > > >  .PP
>> > > > > -The \fBip sr hmac set\fR command prompts for a passphrase  
>> that will be used as the
>> > > > > -HMAC secret for the corresponding key ID. A blank  
>> passphrase removes the mapping.
>> > > > > -The currently supported algorithms for \fIALGO\fR are  
>> \fBsha1\fR and \fBsha256\fR.
>> > > > > +The \fBip sr hmac set\fR command prompts for a  
>> newline-terminated "passphrase"
>> > > >
>> > > > That implies that newline is part of the pass phrase.
>> > >
>> > > Not really.  "NUL-terminated" strings don't include the NUL in the
>> > > string content.  If you prefer, it could be made explicit as follows:
>> > >
>> > >     The \fBip sr hmac set\fR command prompts for a "passphrase" that
>> > >     will be used as the HMAC secret for the corresponding key ID. The
>> > >     passphrase is terminated by a newline, but the terminating newline
>> > >     is not included in the resulting passphrase.
>> > >
>> > > But I don't think it's very useful, as it's not needed to know how to
>> > > use the command correctly.
>> > >
>> > > > The code to read password is using getpass() which is marked  
>> as obsolete
>> > > > in glibc. readpassphrase is preferred.
>> > >
>> > > Is that relevant to this documentation patch?
>> > >
>> > > > > +that will be used as the HMAC secret for th
>> >
>> > Since this is only part of iproute2 that uses getpass() probably should
>> > be rethought. Having key come from terminal seems hard to script
>> > and awkward.
>>
>> Hi Stephen,
>>
>> Recently, I started working on implementing some self-tests for  
>> SRv6 on HMAC.
>> The command:
>>
>>   ip sr hmac set <keyid> <algo>
>>
>> uses getpass() internally, as you mentioned earlier, which can be  
>> inconvenient
>> for automation.
>>
>> To address this, Paolo Lungaroni has extended the command to support an
>> additional parameter called "secret" (this is within our internal fork of
>> iproute2):
>>
>>   ip sr hmac set 17 sha1 secret <your-secret>
>>
>> This enhancement allows the secret to be specified directly on the command
>> line, making it much more convenient for scripting and automated testing
>> environments.
>> If the "secret" parameter is not provided, the command will  
>> continue to behave
>> as before, prompting for the passphrase interactively (i.e., the legacy
>> behavior; we haven't modified the getpass() function, but we can consider to
>> update it).
>>
>> If you're interested, I can reach out to Paolo Lungaroni, the author of this
>> patchset, tomorrow morning (CEST) and ask him to prepare everything for
>> submission, including updates to the man page.
>
> 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.
The keys are also shown in plain text in the show. It should be noted,  
however,
that there are mechanisms (in some cases optional, see more later) to mask the
printing of keys.

Here are a few examples:

MACsec:

# ip link add macsec0 link eth0 type macsec encrypt on
# ip macsec add macsec0 tx sa 0 pn 1 on key 00  
12345678901234567890123456789012
# ip macsec add macsec0 rx port 1 address 00:00:12:34:56:78
# ip macsec add macsec0 rx port 1 address 00:00:12:34:56:78 sa 0 pn 1  
on key 01 09876543210987654321098765432109
# ip macsec show
4: macsec0: protect on validate strict sc off sa off encrypt on  
send_sci on end_station off scb off replay off
     cipher suite: GCM-AES-128, using ICV length 16
     TXSC: 525400d4ad0f0001 on SA 0
         0: PN 1, state on, key 00000000000000000000000000000000
     RXSC: 325341bd7c270001, state on
         0: PN 1, state on, key 01000000000000000000000000000000
     offload: off

IPsec (xfrm)

# ip xfrm state add src fc00::1 dst fc00::2 \
           proto esp spi 0x00123456 reqid 0x12345678 mode transport \
           auth sha256  
0x1234567890123456789012345678901234567890123456789012345678901234 \
           enc aes  
0x0987654321098765432109876543210987654321098765432109876543210987
# ip xfrm state list
src fc00::1 dst fc00::2
   proto esp spi 0x00123456 reqid 305419896 mode transport
   replay-window 0
   auth-trunc hmac(sha256)  
0x1234567890123456789012345678901234567890123456789012345678901234 96
   enc cbc(aes)  
0x0987654321098765432109876543210987654321098765432109876543210987
   anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
   sel src ::/0 dst ::/0

In these cases, other methods of insertion via file, pipe or stdin are not
supported.

In ip sr hmac set, I simply took inspiration from the examples shown above and
replicated something similar while maintaining backward compatibility with the
previous interactive mode.

One more note: on ip xfrm state list, you can shadow the keys if you enter a
specific keyword (nokeys).

# ip xfrm state list nokeys
src fc00::1 dst fc00::2
   proto esp spi 0x00123456 reqid 305419896 mode transport
   replay-window 0
   auth-trunc hmac(sha256) <<Keys hidden>> 96
   enc cbc(aes) <<Keys hidden>>
   anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
   sel src ::/0 dst ::/0

I can update my patch to also support ip sr hmac show, which uses an identical
secret masking mechanism.

===

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.

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?

Could you please clarify what you intend to do and how to remain compatible
with RFC8754, which defines HMAC for SRv6?

Best regards,
Paolo.

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

[Eric Biggers]

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