Hi!
Am 28.05.23 um 11:17 schrieb marty1885:
Hi,
I've been working on my own to build a private messaging system on
GNUnet (just for fun, as a hobby project). It's not exactly the same
as libgnunetchat. My goal is to create a system that works like email
and supports message delivery even when the receiving node is offline.
No working code yet, just designing and building my C++ binding. The
binding is available on my GitHuib
(https://github.com/marty1885/gnunetpp).
After iterations of design and failing. I realized a challenge when
Alice sends a message to Bob while Bob is offline. Bob needs to
publish his encryption public key on DHT under the hash of his Ego's
public key `hash(bob_ego_pk)`. However, attackers who know Bob's ego
can flood the DHT with garbage data, making it difficult for Alice to
find the actual record. Since the DHT functions as a plain key-value
store, there's no way to prevent attackers from doing so.
What you actually want is to use GNS, not the DHT directly.
Using GNS, you can create an Ego and publish information under that ego.
The data will also be signed in a way that if you carefully choose the
key, it provides even more security (privacy) guarantees.
You can read the spec here:
https://datatracker.ietf.org/doc/draft-schanzen-gns/
I want to add a few self-authenticating blocks that all nodes validate
and do not propagate or store if the validation fails. This way,
attackers won't be able to spam garbage data in the hopes of hiding
Bob's public key. Even if they try, other nodes around them will see
the invalid messages and stop the attack right there. This validation
process is similar to how CADET validates messages before sending or
receiving. After reading the DHT source code, it seems that it only
validates the HELLO messages. Also, the current DHT block types are
quite specific besides the TEST block. I believe GNUnet could benefit
from having blocks that can store generic messages.
Yes, you want GNS.
Could someone point me in the right direction to get started? I
understand that in order to contribute, I'll need to sign the PDF and
send an email to GANA to add the types. Is there anything else I
should do? I've attached some preliminary details, in case they are
helpful.
You may want to add GNS record types for your purposes via GANA:
https://git.gnunet.org/gana.git/tree/gnu-name-system-record-types/POLICY
The DHT block types are here:
https://git.gnunet.org/gana.git/tree/gnunet-dht-block-types/README
But there is no registration policy (yet) it seems.
But consider GNS first!
BR
Martin
Best regards,
Martin
=================================
I would like to introduce two new block types: SELF_HASH and
ECDSA_SELF_SIGNED. SELF_HASH functions similarly to how the FS block
works. In SELF_HASH, the DHT key must be the hash of the entire block.
This block type is useful for sharing anonymous public messages while
preventing attackers from overwhelming it.
ECDSA_SELF_SIGNED works similarly to GNS's block. The structure of the
message would look like the following:
|----------|------|----------...--------------|------------|
ECDSA-PK TOPIC message SIG
SIG represents the ECDSA signature of all the preceding bytes,
including the PK and the topic. This block type must be published
under HMAC(PK, TOPIC). This block allows Egos to publish information.
For both block types, it's possible to add an extra layer of
indirection and encryption for better privacy and security. I have
omitted them to keep the explanation simple.
Also I understand that this could be achieved by using the GNS as a
key-value store. But that seems excessive and just not right.
Or maybe I should just publish GNS blocks and let GNS do the
filtering?