[HacDC:Byzantium] Byzantium Discovery PDF

Thu Aug 30 11:44:29 PDT 2012

Here is the core of the authentication issue: It's necessary to one of
our scenarios, but a non-starter for the other.

The Doctor and many of the more paranoid members of this list they
envision Byzantium as the solution to a technologically sophisticated
adversary who as taken control of their Internet access. They look to
examples like Syria and think that anything less that perfect anonymity
is just going to get people killed. They are concerned with hiding and
staying hidden while still communicating with the outside world.

On the other hand, if we're talking about a natural disaster such as
Haiti or Katrina or DC-when-the-wind-blows, then having some
authentication (even if it is weak) could be vital to organizing an
effective response and recovery effort. Users would be communicating
with their friends and neighbors or emergency responders, not random
strangers. Far from hiding, they want to be found and identified and
helped.

This all hinges on whether or not we anticipate that a technologically
sophisticated adversary is out to get us. In my opinion Syria is a
special case. On the other hand, natural disasters (big and small) are a
fact of life in every part of the world.

We're revisiting the issue of solving for Katrina versus solving for
Egypt. I think we need to keep focusing on solving for Katrina first.
However, as a concession to the Egypt use case, any
authentication/identity solutions we come up with should be strictly
optional.

That said, implementing distributed authentication/identity is a hard
problem, so it behooves us to start thinking about it early and
investigating the possibilities.

Ben the Pyrate.

On 08/30/2012 11:15 AM, Dave Duchesneau wrote:
> I have a few comments to Project Byzantium (where I mostly just lurk for
> now), prefaced by some excerpts from recent dialog.
>
>>> Conclusion: Sometimes authentication is necessary and [desirable]...
>>> Sometimes it really is needed, and sometimes it is not.
>> I agree with your conclusion (but not with all of your reasoning).
>> ...[Authentication] in a decentralized network...is very hard to manage.
>> ...Byzantium is...designed to let people communicate...
>> ...in a time of emergency...
>> ... the lack of [authentication] isn't *necessarily* detrimental...
>>> I have heard horror stories of people who thought using GPG... 
>>> was good security culture, until they realized that their 
>>> professional profile had been automatically connected to their 
>>> 'activist' profile...to the users detriment.  Rather than 
>>> providing security, it incriminated them post-hoc...
>>> These are things to consider... 
>> GPG itself doesn't do anything.  If you use multiple identities 
>> (i.e. mail addresses) with the same key, then you're responsible 
>> for the resulting connection.  If you want to keep multiple 
>> distinct "profiles", then use distinct keys...
> The problems associated with a project like Byzantium are both deep and
> wide.  Taken together, the problems are hard to solve because the *best*
> solution to one problem may increase the difficulty of solving another, or
> even create a brand-new problem altogether.  The difficulty of solving the
> inherent problems is further compounded by the lack of visibility into the
> future importance of one problem relative to another.  Thus, before one
> focuses on solving a particular problem, it may be prudent to ensure that
> the problem itself merits so much attention.  However, the attention should
> be focused first on accurately defining the actual problem rather than
> engineering a solution.
>
> For example, in the case of authentication, I think it merits a lot of
> attention, in order to identify exactly what is needed, and in what
> circumstances.  This necessitates understanding what is to be gained and
> what must be given up, and under what circumstances such trade-offs may be
> appropriate or inappropriate.  Put another way, ask yourself under what
> circumstances would you be willing to trade breathable air for drinkable
> water, or vice-versa?  All of a sudden we find ourselves asking more
> questions and questioning our assumptions, which is as it should be.  As
> usual, once we've asked the right questions and understand their relative
> importance in a given context, getting good answers may be relatively
> straightforward.  
>
> Personally, I'm delighted to see the discussion that is taking place here,
> because it increases the odds of getting the truly relevant issues out in
> the open, where the implications (e.g., cause-and-effect relationships) may
> be better understood by a wider audience (or even, at all).  We may be
> smarter collectively, but only if we can harness what we know individually.
>
> Dave Duchesneau
> ddd at crisis-force.org
>
>
>
> -----Original Message-----
> From: Baptiste Jonglez [mailto:baptiste at jonglez.org] 
> Sent: Thursday, August 30, 2012 3:12 AM
> To: byzantium at hacdc.org
> Subject: Re: [HacDC:Byzantium] Byzantium Discovery PDF
>
> On Thu, Aug 30, 2012 at 02:25:21AM -0700, black_sector at riseup.net wrote:
>> Signed authentication destroys anonymity in most cases. There are times
>> when you want to know who everyone is that you are dealing with. There are
>> other times when leaving a 'crypto-trail' right back to your door is
>> actually a bad thing, and not something you would want for your comrades.
> While I also disagree with Nicholas when it comes to require some sort
> of log-in to use the services, I don't think he was thinking of
> involving any crypto.
>
>> I think that MD5 and similar is often a good alternative for signed
>> authentication. Perhaps it is not sufficient for a repository handler, but
>> it is generally sufficient for end users. After all, an authenticated
>> package only means you have verified the source but not that the package
>> is untampered with necessarily. Checking the MD5 or Sha* actually tells
>> you about the condition of the package, client side. If the file checks
>> out and passes MD5, then making sure you authenticated the sender is not
>> that relevant. If however the package is corrupted or tampered with,
>> knowing who provided it warns you that the source is unreliable.
> Wait, there is something wrong here. Do you really think MD5 (or sha*,
> for that matters) is an algorithm that provides *authentification*?
>
> It just doesn't make sense. If an attacker is tampering with a file,
> he can *also* modify the md5sum written to a file just next to it.
>
> Signing a file with a GPG key, for instance, is way more
> robust. Assuming the algorithm isn't flawed, in order to tamper with the
> file without being noticed, you must either take control of the
> private key (which is supposed to be well protected), or use your own
> key and make it look like it's the right one, which is also quite
> hard.
>
>> It is worth noting that even major repository maintainers often make no
>> promises that their software is free of malware. They do not audit every
>> package. You can get a rootkit from a major linux distro (potentially) by
>> adding an app that got by somebody, without adding anything third party.
>> Linux is more secure than Windows and more people are watching for these
>> things, but it took a good minute before somebody actuaolly audited Google
>> Chrome and found data-mining software in it. An authenticated open-source
>> application is not automatic protection against various threats. Being
>> able to audit something only counts if somebody actually does, and then we
>> have to trust that they will bring it to public attention.
> Your example is flawed, since Google Chrome is *not* Free Software
> (unless you're referring to Chromium, which is).
>
> As for Free Software projects, it's all a matter of trust. The project
> leader(s) often keep a close eye on code contribution. If the source
> code is compiled by a project member and then immediately signed with
> a PGP key, it's pretty robust against tampering (again, you can never
> be 100% sure).
>
> As for source code alteration, you might remember the attack on
> kernel.org: thanks to git, we were sure (as far as sha256 collision
> are hard to produce) that the attackers didn't modify the repository,
> or else the developers' trees would no longer match the ones on
> kernel.org.
>
>> Conclusion: Sometimes authentication is necessary and desireable, but I
>> would not advocate its use only because it is common or standard in Linux
>> and the server world. I like to keep it simple and only add what is
>> actually needed. Sometimes it really is needed, and sometimes it is not.
> I agree with your conclusion (but not with all of your reasoning).
>
> As haxwithaxe pointed out, authentification in a decentralized network
> like this is very hard to manage.
>
> Besides, I doubt the goal of Byzantium is to build some kind of
> Facebook over mesh networking (again, I might be wrong). It's designed
> to let people communicate with each others, potentially in a time of
> emergency.
>
> And more fundamentally, the lack of authentification isn't
> *necessarily* detrimental. Have you ever used IRC? :)
>
>> I have heard horror stories of people who thought using GPG for their
>> emails was good security culture, until they realized that their
>> professional profile had been automatically connected to their 'activist'
>> profile. Now they are linked and government and corporate search engines
>> can connect the dots to the users detriment. Rather than providing
>> security, it incriminated them post-hoc.
>>
>>
>> These are things to consider. I strongly dislike how GPG automatically
>> connects profiles together. That is why I do not use it myself.
> GPG itself doesn't do anything. If you use multiple identities
> (i.e. mail addresses) with the same key, then you're responsible for
> the resulting connection. If you want to keep multiple distinct
> "profiles", then use distinct keys.
>
> Baptiste
>

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE