[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: Encryption of EGO keys

From: TheJackiMonster
Subject: Fwd: Encryption of EGO keys
Date: Sun, 05 Jul 2020 21:49:20 +0200
User-agent: Evolution 3.36.4

Hello again,

today I released the next version of the Cadet-GTK application which is
0.6.0 already. It allows file-sharing with the FS-module embedded to
the chat and uses symmetric encryption to ensure to file can be read
only by your contacts of the chat (works for groupchat as well as long
as the implementation supports it).

So the next step would be to improve the groupchat as considered from
the bigger meetings using a ring topology. I would like to improve
security of groups as well in parallel but I still have a question
about EGO keys which should be attached. Maybe someone here can answer
this... I'm not sure if my question was forgotten or something on the
developers mailing list. ^^'

Happy hacking,
--- Begin Message --- Subject: Encryption of EGO keys Date: Wed, 01 Jul 2020 16:29:29 +0200 User-agent: Evolution 3.36.3
Hello there,

I have a question about using the EGO keys. I was thinking about using
them for authentication in the CADET chat but I have a problem with the
current handling of these keys.

The files are basically unencrypted on the local drive which is
definitely convenient but could potentially be a problem depending on
applications running on the system.

For example if I wanted to develop a remote control application with
GNUNET for supporting assistance and some other tasks. I would like to
have at least the possibility to encrypt those EGO keys with a password
using symmetric keys.

I guess I could do that manually on the files but my question is: Why
isn't there an automatic way using the GNUNET API to do so? I mean it
could be optional because I also see the benefits of raw access and
many (if not most) people use encryption for their drive anyway.

But without this feature I would still prefer using GpGMe for handling
identities instead of EGO because GpG allows it optionally even though
I would like to reduce dependencies as well.


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

--- End Message ---

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]