There are plenty of examples to hash the X-Trace or Injection-Info header
details to provide obfuscation while allowing consistent header data other
users can use to filter if they wish, but I'm looking for functionality like
that of Diablo's X-Trace encryption, where it is reversible to the
administrator. I had started a thread many years ago on the same topic, and
some links were given to Albasani's SVN repo, which is offline, and not
available via archive.org.

I want this if a problematic user is not discovered until logs have rolled
over. Without it I don't have a way to identify the offending user. I like the
way the typical examples work to obfuscate the content in a consistent way,
but it isn't reversible to me if needed.

Does anyone have example code for doing this?

* Jesse Rehmer wrote:
> There are plenty of examples to hash the X-Trace or Injection-Info header
> details to provide obfuscation while allowing consistent header data other
> users can use to filter if they wish, but I'm looking for functionality like
> that of Diablo's X-Trace encryption, where it is reversible to the
> administrator. I had started a thread many years ago on the same topic, and
> some links were given to Albasani's SVN repo, which is offline, and not
> available via archive.org.

If you want to use this in the filter_nnrpd Perl filter, take a look at

https://metacpan.org/pod/Crypt::CBC

--
Пу́тін — хуйло́
http://www.eternal-september.org

Hi Jesse and Wolfgang,

>> There are plenty of examples to hash the X-Trace or Injection-Info header
>> details to provide obfuscation while allowing consistent header data other
>> users can use to filter if they wish, but I'm looking for functionality like
>> that of Diablo's X-Trace encryption, where it is reversible to the
>> administrator.
>
> If you want to use this in the filter_nnrpd Perl filter, take a look at
>
> https://metacpan.org/pod/Crypt::CBC

Would it then be useful if we had a new block in inn-secrets.conf:

encryption {
injection-info: "XXX"
}

and a new encryptinjectioninfo parameter (true/false) in access blocks
of readers.conf to automatically encrypt the posting-host and
posting-account information?

If posting-account is "myuser", nnrpd would then write
"U2FsdGVkX1+AIde8W1/6D7PFN0YrP0pekyWK4Vt4qhM=" instead, using the
suggested CBC algorithm:

% echo "myuser" | openssl enc -aes-256-cbc -pbkdf2 -base64 -pass pass:XXX
U2FsdGVkX1+AIde8W1/6D7PFN0YrP0pekyWK4Vt4qhM=

Decoding could be done with the following command:

% echo "U2FsdGVkX1+AIde8W1/6D7PFN0YrP0pekyWK4Vt4qhM=" | openssl enc
-aes-256-cbc -pbkdf2 -base64 -pass pass:XXX -d
myuser

Any comments about that suggestion?
Would it be useful for news admins?

Any other information that should be obfuscated in header fields?

--
Julien ÉLIE

« Sème du bonheur dans le champ du voisin, tu seras surpris de constater
ce que le vent fera produire au tien. » (Juliette Saint Gelais)

Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> writes:

> If posting-account is "myuser", nnrpd would then write
> "U2FsdGVkX1+AIde8W1/6D7PFN0YrP0pekyWK4Vt4qhM=" instead, using the
> suggested CBC algorithm:

> % echo "myuser" | openssl enc -aes-256-cbc -pbkdf2 -base64 -pass pass:XXX
> U2FsdGVkX1+AIde8W1/6D7PFN0YrP0pekyWK4Vt4qhM=

I would not use AES-CBC for any new application. It's not authenticated,
which opens it to various problems. AES-CBC-HMAC is better, but it's a
complicated algorithm that's very easy to make mistakes with.

AES-GCM-SIV is probably the most foolproof of readily available encryption
algorithms. Unfortunately, it's not supported by openssl enc, and it's a
fairly new addition to the OpenSSL libraries. Other good options would be
AES-GCM or ChaCha20-Poly1305 (which require unique nonces, but given the
volume of a typical INN nnrpd server we can probably get away with random
nonces), which have been supported for longer but similarly aren't
supported by openssl enc.

PBKDF2 is also a pretty bad key derivation function. It probably doesn't
matter that much, but scrypt or bcrypt would be much better.
Unfortuantely, openssl enc is not a very good tool. :(

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

On Jul 6, 2023 at 12:48:03 PM CDT, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

> Hi Jesse and Wolfgang,
>
>>> There are plenty of examples to hash the X-Trace or Injection-Info header
>>> details to provide obfuscation while allowing consistent header data other
>>> users can use to filter if they wish, but I'm looking for functionality like
>>> that of Diablo's X-Trace encryption, where it is reversible to the
>>> administrator.
>>
>> If you want to use this in the filter_nnrpd Perl filter, take a look at
>>
>> https://metacpan.org/pod/Crypt::CBC
>
> Would it then be useful if we had a new block in inn-secrets.conf:
>
> encryption {
> injection-info: "XXX"
> }
>
> and a new encryptinjectioninfo parameter (true/false) in access blocks
> of readers.conf to automatically encrypt the posting-host and
> posting-account information?
>
> If posting-account is "myuser", nnrpd would then write
> "U2FsdGVkX1+AIde8W1/6D7PFN0YrP0pekyWK4Vt4qhM=" instead, using the
> suggested CBC algorithm:
>
> % echo "myuser" | openssl enc -aes-256-cbc -pbkdf2 -base64 -pass pass:XXX
> U2FsdGVkX1+AIde8W1/6D7PFN0YrP0pekyWK4Vt4qhM=
>
>
> Decoding could be done with the following command:
>
> % echo "U2FsdGVkX1+AIde8W1/6D7PFN0YrP0pekyWK4Vt4qhM=" | openssl enc
> -aes-256-cbc -pbkdf2 -base64 -pass pass:XXX -d
> myuser
>
>
>
> Any comments about that suggestion?
> Would it be useful for news admins?
>
> Any other information that should be obfuscated in header fields?

This sounds like a good idea. The other thing I noticed related to injection
information is that if addinjectionpostinghost is true, the host is included
in the Path header as well. I am primarily concerned about identifying the
authenticated user, so I am fine leaving it set to false, but obfuscating the
posting-host in the Injection-Info header alone may not be enough for some
admins.

Hi Jesse,

>> Any other information that should be obfuscated in header fields?
>
> This sounds like a good idea. The other thing I noticed related to injection
> information is that if addinjectionpostinghost is true, the host is included
> in the Path header as well. I am primarily concerned about identifying the
> authenticated user, so I am fine leaving it set to false, but obfuscating the
> posting-host in the Injection-Info header alone may not be enough for some
> admins.

Yes, the posting-host information recorded in both Injection-Info and
Path header fields should be encrypted. We cannot leave one alone.

--
Julien ÉLIE

« J'ai un copain, il est pilote d'essai… Enfin, il ne l'est pas encore ;
pour l'instant, il essaie d'être pilote ! » (Raymond Devos)

Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> writes:

>> This sounds like a good idea. The other thing I noticed related to
>> injection information is that if addinjectionpostinghost is true, the
>> host is included in the Path header as well. I am primarily concerned
>> about identifying the authenticated user, so I am fine leaving it set
>> to false, but obfuscating the posting-host in the Injection-Info header
>> alone may not be enough for some admins.

> Yes, the posting-host information recorded in both Injection-Info and Path
> header fields should be encrypted. We cannot leave one alone.

I'm not sure I'm a big fan of encrypted blobs in the Path header. Is that
serving any protocol purpose over simply omitting that information
entirely? I think you'd have to consistently encrypt a hostname to the
same value for it to have any function in the Path header, but at that
point you're allowing people to correlate it across postings and you're
probably not achieving your privacy goals anyway. (Also, no good
encryption algorithm would encrypt the same cleartext to the same
ciphertext, so you would have to use some semi-broken encryption algorithm
to do that.)

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Hi Russ,

> I would not use AES-CBC for any new application. It's not authenticated,
> which opens it to various problems.

Noted.

> AES-CBC-HMAC is better, but it's a
> complicated algorithm that's very easy to make mistakes with.

.... and OpenSSL documentation explicitly warns that
EVP_aes_256_cbc_hmac_sha256() "is not intended for usage outside of TLS
and requires calling of some undocumented ctrl functions"...
Glad to hear that warning ^^

> AES-GCM-SIV is probably the most foolproof of readily available encryption
> algorithms. Unfortunately, it's not supported by openssl enc, and it's a
> fairly new addition to the OpenSSL libraries. Other good options would be
> AES-GCM or ChaCha20-Poly1305 (which require unique nonces, but given the
> volume of a typical INN nnrpd server we can probably get away with random
> nonces), which have been supported for longer but similarly aren't
> supported by openssl enc.
>
> PBKDF2 is also a pretty bad key derivation function. It probably doesn't
> matter that much, but scrypt or bcrypt would be much better.
> Unfortuantely, openssl enc is not a very good tool. :(

Thanks for all these suggestions.

After all, I'm wondering whether it should not be more useful to news
admins and less time-consuming for developers to just enhance our
filter_innd.pl and filter_nnrpd.pl samples, as well as the documentation
for Perl (and Python) filters with ready-to-use examples.
-> how to obfuscate Injection-Info and just use "!.POSTED" (without the
posting-host)
-> how to reject articles containing something in one of their header fields
-> how to reject articles crossposted to x and y
-> how to...

--
Julien ÉLIE

« J'ai un copain, il est pilote d'essai… Enfin, il ne l'est pas encore ;
pour l'instant, il essaie d'être pilote ! » (Raymond Devos)

Hi Russ,

>> Yes, the posting-host information recorded in both Injection-Info and Path
>> header fields should be encrypted. We cannot leave one alone.
>
> I'm not sure I'm a big fan of encrypted blobs in the Path header. Is that
> serving any protocol purpose over simply omitting that information
> entirely?

You're totally right, just removing it from the Path header field is the
best thing to do ("!.POSTED" alone).

--
Julien ÉLIE

« – Quel a été votre plus beau jour ?
– Une nuit. » (Brigitte Bardot)

On Jul 6, 2023 at 1:53:11 PM CDT, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

> Hi Russ,
>
>>> Yes, the posting-host information recorded in both Injection-Info and Path
>>> header fields should be encrypted. We cannot leave one alone.
>>
>> I'm not sure I'm a big fan of encrypted blobs in the Path header. Is that
>> serving any protocol purpose over simply omitting that information
>> entirely?
>
> You're totally right, just removing it from the Path header field is the
> best thing to do ("!.POSTED" alone).

Agreed, I would prefer to see just "!.POSTED" over an encrypted value.

Jesse Rehmer schrieb:

> some links were given to Albasani's SVN repo, which is offline, and not
> available via archive.org.

The repos seem to be lost in the hardware failure of news.albasani.net. I
have a checkout of those repos available, without history, and plan to
bring them online again some day ... as time permits.

On 07.07.23 00:25, Thomas Hochstein wrote:
> Jesse Rehmer schrieb:
>
>> some links were given to Albasani's SVN repo, which is offline, and not
>> available via archive.org.
>
> The repos seem to be lost in the hardware failure of news.albasani.net. I
> have a checkout of those repos available, without history, and plan to
> bring them online again some day ... as time permits.

you may be the only one still holding it...
would be great if you could provide a zip/tar anywhere to download
for a few hours, so we have more copies and
i'll serv it with a static link on my mirror and
do upload to archive.org.
thanks!