[Whonix-devel] [Secure Desktops] Hi!

Mon Jan 30 22:22:56 CET 2017

On 2017-01-30 08:29, ng0 wrote:
> 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.

No its ok. I wanted to mirror it to our mailing list and forgot to add 
this one.

> 
> 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.

Makes sense. Though long term when it gains a userbase its better to 
transition the time daemon to do its thing over an anonymous system 
completely - ideally GNUnet.

> 
> 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.

Been following Secushare for some time. Sounds great and I look forward 
to playing around with it.

> 
> 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.
>> 