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@crisis-force.org
-----Original Message----- From: Baptiste Jonglez [mailto:baptiste@jonglez.org] Sent: Thursday, August 30, 2012 3:12 AM To: byzantium@hacdc.org Subject: Re: [HacDC:Byzantium] Byzantium Discovery PDF
On Thu, Aug 30, 2012 at 02:25:21AM -0700, black_sector@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