Re: Adding generic cryptographic self-authenticating block on DHT

[TheJackiMonster]

Hi Martin,

I think people shouldn't use GNUnet when looking for privacy critical
information exchange. GNUnet is mostly designed for utilizing
decentralized network structure to build services and applications on
top. The core aspect is not focused on privacy but on availability.

There are still some aspects in terms of privacy you can get out of
GNUnet. But I think whistle blowers and others should stick to
solutions like Tor instead.

The messenger service utilizes CADET a lot but it's not required to
have direct connections to any partner in a group chat. Technically you
could probably get identities resolved for their peer's key over time
but it's not designed to prevent that necessarily. It's mostly designed
to establish group communication without the need of setting up server
infrastructure upfront.

There's also no reliance on server/client architecture by design. Any
node can loose connection at any point without preventing the other
nodes in a chat to communicate because it uses redundant connections
between different nodes.

About your idea: I think having something equivalent to mail via GNUnet
makes a lot of sense because you could easily add signatures and
encryption via the identiy service and its egos (as equivalent of
GPG/PGP).

However I wouldn't recommend relying to heavily on the FS service at
the moment since a re-implementation was already discussed. There are
currently some issues with the FS service when running GNUnet as multi-
user setup.

I would think looking into GNS as Martin suggested should be a better
option. Also GNS is quite reliable already as well.

I definitely support a mechanism for properly delivering a message via
mailbox, even if the latency is higher than with CADET. Because I would
like to optionally use that to deliver messages in the messenger
service as well, if possible since requesting messages after a
reconnection to a chat likely works good enough for groups, it does not
work good enough in direct (1-to-1) chats. ^^'

Best regards,
Jacki

On Mon, 2023-05-29 at 04:18 +0000, marty1885 wrote:
> Hi Jacki,
> 
> Thanks for your quick response. I wanted to
> clarify the goals and scope of my project to help 
> discussion. My goal is to have a fully decentralized
> and private email system, while also aiming to
> introduce non-technical users to GNUnet. Eventually,
> I want to build a system that can operate without the
> Internet and withstand hostile environments.
> 
> There are two key properties I want to achieve
> with this project. First, I want to ensure strong
> privacy guarantees for both the sender and
> receiver of messages. Second, I want to enable
> communication between parties who may not be
> online simultaneously.
> 
> After reading the messenger service API and
> briefly the service source code,  From my
> understanding, the messenger service is a
> server/client architecture and uses CADET for
> message transport. It functions similarly to IRC
> but on GNUnet.
> 
> My concerns with CADET is that it doesn't offer
> the desired privacy level. Mainly from the lack
> of onion routing. Once a CADET connection is
> established, both the server and client are aware
> of each other's peer (node) identity. It's
> relatively easy to obtain the counterpart's IP
> address via gnunet-peerinfo. Even if the
> counterpart is not a direct peer but connected
> through a series of GNUnet nodes. I think it's
> still not overly hard to extract the physical
> location from CADET's channel path. This poses
> threats for situations like the user is a
> journalist operating in a hostile environment. If
> the node hosting the room is hacked or if someone
> discovers the peer ID, the user's location could
> be exposed. In such cases, users would be better
> off hiding their IP connected to GNUnet using Tor,
> which defeats the purpose of utilizing GNUnet in
> the first place.
> 
> Instead, I planned for my system to send messages
> by first publishing a short-lived, encrypted
> version to the FS. Then, using the DHT
> as a mailbox to notify the recipient that new
> messages are available. This approach ensures 
> that neither the sender nor the receiver is aware
> of each other's peer identity, yet they can
> retrieve messages using their respective egos.
> While this method introduce higher latency compared
> to CADET, I believe it's an acceptable tradeoff for
> the enhanced privacy. There are additional
> complexities involved in scenarios where the receiver
> remains offline for extended periods and the sender
> goes offline after sending, but I won't delve into
> those details now.
> 
> Any flaws you can think of in this design?
> 
> Additionally, I'm curious to know if you think my
> validate-block-by-dht-service approach is viable.
> I believe it has the potential to prevent attacks
> more effectively, rather than relying solely on
> DHT neighbors behaving and not leaking the mailbox
> key. It could also help securing GNS its ground.
> 
> Best regards,
> Martin
> 
> ------- Original Message -------
> On Sunday, May 28th, 2023 at 9:15 PM,
> thejackimonster@gmail.com <thejackimonster@gmail.com> wrote:
> 
> 
> > 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?

signature.asc
Description: This is a digitally signed message part