commit 7f347a006926d89ba2acfb0fe811ee236a3b153a
parent d58407eb5f9c5757aae3ecb2217fd4266957deda
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Fri, 25 Jul 2025 12:41:20 +0200
hash update
Diffstat:
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/draft-schanzen-pils.xml b/draft-schanzen-pils.xml
@@ -151,8 +151,13 @@
<name>Address hash</name>
<t>
The address hash is calculated over the concatenation of all
- address strings (URIs) (excluding 0-terminator) using SHA-512.
+ address strings (URIs) using SHA-512.
The addresses <bcp14>MUST</bcp14> be sorted alphanumerically.
+ The byte 0x00 is used as a separator between URIs in the hash input.
+ Consequently the hash may simply be calculated over the full C strings
+ including their 0-terminator.
+ Due to the flexibility of possible URI values this prevents any kind of odd
+ common-prefix case in which hashes may collide.
</t>
</section>
<section anchor="pid_derivation" numbered="true" toc="default">
@@ -178,7 +183,16 @@ sk = HKDF-Expand(prk, "gnunet-pils-contextual-peer-key", 32)
<section>
<name>Security and Privacy Considerations</name>
<t>
- TODO: Crypto considerations. Linkability limitations.
+ TODO: Crypto considerations.
+ </t>
+ <t>
+ While the approach provides some privacy in certain use cases, it is not a general solution
+ to prevent peer identity linkability.
+ For example, if the peer is configured a permanent, static and global address it will be trivially
+ linkable even if PILS derives different peer identities.
+ As such, the peer identity derivation is aimed to protect common use cases for the average user
+ where it is to be expected that no such global and static address is availalble as outlined in the
+ introduction.
</t>
<t>
It may seem odd why GNUnet does not use a dedicated, randomly generated public key per address.
