[Top][All Lists]

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

Re: Encryption of EGO keys

From: TheJackiMonster
Subject: Re: Encryption of EGO keys
Date: Wed, 08 Jul 2020 18:26:18 +0200
User-agent: Evolution 3.36.4


> My first feeling for this overall is that this is likely the wrong
> direction, as we really need to focus on improving usability, not add
> features for power-users that even there are of marginal utility.
> Stuff
> like running with even more UIDs or considering scenarios with
> attacks
> involving virtualization are not going to get us any closer towards a
> system that can be used by more people than its own developers. So at
> least for me, the motivation to design, implement, document and debug
> such features is extremely low, and I fear that doing this "right" so
> that it actually works will take quite a bit of effort that could be
> better spent elsewhere for a much bigger impact.

I think this makes sense to me. Getting a different UID for
configuration and keys should be enough to prevent other third party
applications having access to it.

> Is actually closely related to the "homework" we got from the
> audit of GNU Taler from CodeBlau: separate processes and UIDs to
> minimize exposure of private key material to the rest of the
> system.  It
> wouldn't be necessarily a virtual environment (we were more thinking
> of
> another UID) and 'encrypted' is also questionable (for availability
> reasons -- after power outage system has to boot without human
> intervention). OTOH, we _do_ think about using HSMs for the private
> keys, which is more like the hard-core version of the flash drive you
> are thinking about.

The encryption should of course be optional but I think that's not even
a feature which has to be implemented internally because there is
already the possibility to put all data regarding GNUnet inside of an
explicitly encrypted partition. The HSM sounds even better of course. I
think the usage of a separate UID could be similar to what's Tor using.
So less access from other UIDs as possible and applications could get
access with explicit permission.

> I do intend to soon start design discussions on this (likely at
>, and depending on how those go, it is not unlikely
> we'll push the functionality into libgnunetutil. While *my* objective
> not to use this for GNS, we may be able to make this dual-use with
> right design (and if it works, I would not object to having it as an
> _option_ for GNS). So I would encourage you to participate in the
> discussion and possibly implementation effort.

Sounds good to me.

Happy hacking

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

reply via email to

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