Re: Adding generic cryptographic self-authenticating block on DHT

[thejackimonster]

Hi Martin,

the GNUnet messenger service technically allows receiving messages
afterwards already. Nodes in a groupchat or direct chat can request
missed messages from each other. I agree that it makes more sense to
deliver messages via a mailbox in the DHT in some cases.

Maybe that ability could be integrated into the messenger service
rather than implemented as another separate option?

This might also help with your problem because the messenger service
has its own mechanism in place to exchange EGO public keys with the
contacts in a chat. So these are known inside a chat.

We could even add a new message type to register a specific place in
the DHT as mailbox for messages the contacts could check. That might
also help to prevent attackers from flooding the DHT using the specific
keys.

What do you think?

Best regards,
Jacki

On Sun, 2023-05-28 at 09:17 +0000, marty1885 wrote:
> > 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.
> > 
> > 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.
> > 
> > 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.
> > 
> > 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?
> >