Re: Adding generic cryptographic self-authenticating block on DHT

More info:
The registry is in the docs: 
https://docs.gnunet.org/gana/gnu_name_system_record_types.html
and you probably want to use this for GNS:
https://docs.gnunet.org/developers/subsystems/gnsstack.html

Am 28.05.23 um 17:11 schrieb Schanzenbach, Martin:
> 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?
>>
>