Re: [p2p-hackers] Distributed identity, chat, publishing, and sharing

----- Forwarded message from ianG ----- Date: Thu, 17 Oct 2013 11:01:15 +0300 From: ianG To: p2p-hackers@lists.zooko.com Subject: Re: [p2p-hackers] Distributed identity, chat, publishing, and sharing Message-ID: <525F994B.1070906@iang.org> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 Reply-To: theory and practice of decentralized computer networks Just some thoughts. I wasn't able to find my original post asking that question... On 16/10/13 22:50 PM, Sean Lynch wrote:

ianG writes:

...

BTW, why the keenness on Ed25519?

Sorry for the delayed response. I managed to lose track of this message migrating between Gmail and my own server.

I like Ed25519 because the public keys are 255 bits long, which makes them potentially usable directly as identifiers. However, more recent events have changed my thinking on this. Schneier speculates that one of the NSA's breakthroughs the Snowden documents talks about may be an advance in the cryptanalysis of ECC systems, and he recommends sticking with better-studied, more conventional systems based on the conventional discrete logarithm problem.

The NSA/Snowden disclosures is a very dynamic area and our understanding is changing as new info comes in. FWIW, I think this is more likely the case: NSA successfully moved the world across to *standards based* ECC. This concentrates the target, and gave them a chance to influence the nature and direction of the production of constants, sizes and so forth. Back in the early 2000s, ECC was hot, as the CEO of RSA has infamously said, and everyone just took the wisdom of NSA without question. But now there has been a lot of work done by a lot of open mathematicians. What they are discovering is that ECC is quite finicky, and the standards-based curves are rapidly starting to look less shiny. Hence, picking an independent effort that utilises all this last-decade work, and generates independent curves, is possibly a better way to go. http://safecurves.cr.yp.to/ (Remember, however, you have to decide how much you care about the NSA as being your threat model. 1. Is it a sole, life threatening threat? 2. Or is it just a great target? 3. Or is it meaningless? They have the data anyway? There are very few systems that are building for the first case. Most of us would be happy with choosing the type 2 threat model, in which case we can just pick the state of the art (curves) implement and move on.)

On top of that, given the dynamic nature of cryptographic technology, it's probably not a good idea to lock oneself into a particular cryptosystem or hash scheme or even to require that identifiers be keys themselves.

I disagree. The history of agility has been poor, IMHO. Instead, I suggest that you lock yourself into the best possible system on today's knowledge -- it's your job, do it! -- and then plan on a complete refit in say 7 years time. Any problems that come up won't be predictable, and you'll not be able to do more than complicate everything anyway. http://iang.org/ssl/h1_the_one_true_cipher_suite.html Good work has sustained far better than we typically give credit for, and bad work has been maintained into a dog's breakfast, without giving damnation due to it.

An identifier scheme could support Ed25519 as one particularly convenient key type, but eventually we'll want to support fingerprints as identifiers and fetching of public keys from a DHT.

That's a separate question -- where the authentication resides. As a thought experiment, I really like the conceptual approach taken by tcpcrypt which (in short) does an ephemeral lower layer, and provides the params up to a higher layer (application) at which the auth questions can be handled. As it states, authentication is an application level concept, not a lower layer concept. iang _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5