[Whonix-devel] [Secure Desktops] Hi!

Mon Jan 30 08:29:45 CET 2017

In case you don't want this cross-posted, let me know. I just
find if confusing to reply to one list and get replies on/to two
different lists.

bancfc at openmailbox.org writes:

> On 2017-01-29 03:03, ng0 wrote:
>> Hi,
>> 
>> bancfc discovered my work and thought it would be a good idea if
>> I sign up for this list, to share and minimize duplication of
>> work.
>
> Awesome stuff. More below. Thanks for posting.
>
>> 
>> I'm working on a live-system which initially, in its first
>> version, will be used as a live-system for secushare[0] (which
>> also implies GNUnet to some degree) with the system being a blend
>> of GuixSD[1]. The choice was between Gentoo, NixOS and GuixSD
>> (more about that in the potential, as of right now unwritten,
>> explanation post about the system).
>> There's no name so far for this version, but I have my ideas
>> about later versions which will be based on the experience with
>> this system.
>> 
>> There's no public documentation so far: the internal onion-only
>> server I share the issue tracker with is currently being moved to
>> a new server which will be exposed to both onion-space and some
>> .org domain.
>>
>> The very short TL;DR before I manage to write a text on this
>> system is:
>> Describing it as "similar to TAILS" is only to make a shortcut in
>> explanations, for the first version will 'optionally' come with
>> a secure_delete use similar to TAILS. For secushare this is too
>> much over the top, but for me it's a nice test of
>> reimplementation (GuixSD uses shepherd as its init system).
>> The rest is nothing groundbreaking: time-service will be
>> tlsdated, software will include some useful tools in addition to
>> gnunet + secushare.
>
> With the controversy surrounding the tlsdate author the package is 
> unfortunately no longer maintained.

It has seen no updates in some time, but even before this someone
else took over. So at some point torproject decide to drop
development on it I assume.

> Also because it relies on CA SSL 
> certs we could never trust that it won't MITM'd by capable adversaries.

Indeed, which is why I see tlsdated only as an intermediate solution.

> We opted for writing our own time sync daemon "sdwdate" [1] instead. 
> Some advantages is that all servers it connects to are Onion sites and 
> are likely not hosted on cloud-sites like cloudflare - to decrease 
> chance of collusion. Limiting leaks of system time to the network is 
> also one area we really focused on because of deanonymiation and risk. 
> [2]

I know of sdwdate, and while for myself it is an option, for the
general pupose usage in all regions I aim for this particular
version of the system, it is not. If the issue tracker were
public already, I could point to the short discussion we had
about this, the short summary is:
the system should not use tor at all (or at least by
default). There's more to be lost than to be gained for people
who live in regions where the use of tor is too dangerous.

Now I said two systems. The system designed to work for
secushare+gnunet (the one I talk about here) will have
differences to others I'm working on. I see I should really put
the issue tracker content and "what's beyond the system" into a
text, including threat models etc.. though it would reproduce
some of the public documentation on http://secushare.org to some
degree.

Writing a system-service for sdwdate is not disregarded on my
side, in general I just ran into porting problems and put it
aside for a while.

> We plan to spin off the time synchronization daemon as its own project 
> at some point as a secure replacement for NTP in general. With its 
> current design it cannot scale to millions of systems because there 
> simply is not that many trusted Onion servers to handle the
> load.

That's interesting news.

> I am 
> really interested to see the ways GNUnet can do away with trusting 
> server endpoints and scaling the time protocol.
>
> [1] https://github.com/Whonix/sdwdate
> [2] https://www.whonix.org/wiki/Time_Attacks
>
>> The long-term goal I have and which I want to push for is to
>> implement what has been discussed for much to long in the Guix
>> project: binary software distribution via gnunet-fs. Previously
>> development on this subject stalled[2] because of several,
>> non-technical, issues. I have some additions of my own,
>> non-technical ones, to the distribution via gnunet-fs solution.
>> In the end, I'd like to replace the time-service through a gnunet
>> based solution, updates via gnunet, and in general make "legacy"
>> net use optional.
>
> Nice! We'd love to have decentralized alternatives to our project repos 
> (and project news and notifications) that can't be censored.

Software repositories are another problem (I seem to recall
discussing this idea at one meeting last year), but once you
figure out the basic problem of how to do it, it shouldn't be
that difficult to solve.
It's definitely something we (secushare) would like to see too
(while the other issue, news and notifications, is what the work
on secushare implies).

>> 
>> That's the system for secushare. I take it one step further
>> afterwards and will try to craft different blends of this, some
>> resulting from off-list conversations I had.
>> 
>> And because someone recently asked this: I hope to be done with
>> the core system (which doesn't include the gnunet-fs and
>> time-service changes) by the end of the year, even much more
>> optimistic: before/around august.
>> But you know how deadlines in packaging are. So to say, the core
>> system is about ~80% done now, the 20% rest depends on:
>> - minor gnunet testsuite debugging
>> - secushare prototype work
>> - getting around 100 rust packages to a functional state
>> - writing and debugging a handfull of system-services
>> - packaging more optional software
>> 
>> Architecture: I plan to target i686 and x86_64 first, and arm as
>> soon as GuixSD has been ported for arm.
>> 
>> 
>> I hope this message wasn't too much text and no real content,
>> it's easier to read issue trackers when they are public or to
>> read focused texts which weren't written at around 01:46 UTC.
>> 
>> [0]: http://secushare.org | http://secushare.cheettyiapsyciew.onion/
>> [1]: https://gnu.org/s/guix
>> [2]: This is not entirely true, some parts were developed, while
>>      others were just discussed with Google Summer of Code
>>      students or doctoral students and when the GSoC ended they
>>      simply no longer worked on it (or they had the exact right
>>      ideas but execution happened only on some parts or they just
>>      moved on (I don't want to speculate or judge about the
>>      actions of people I do not know). It became
>>      so not very obvious that work has happened before that I had
>>      only discovered that some of the theoretical technical solutions
>>      I came up with have been discussed prior to my first contact
>>      with Guix when I started reading the mailing lists archives.
>

-- 
ng0 -- https://www.inventati.org/patternsinthechaos/