Re: [Cryptography] Petnames & Zooko's triangle -- theory v. practice (was Email and IM are...)
On 2013-08-28 7:33 PM, ianG wrote: On 28/08/13 02:44 AM, radi...@gmail.com wrote: Zooko's triangle, pet names...we have cracked the THEORY of secure naming, just not the big obstacle of key exchange. Perhaps in a sense of that, I can confirm that we may have an elegant theory but practice still eludes us. I'm working with a design that was based on pure petnames & ZT, and it does not deliver as yet. One part of the problem is that there are too many things demanding names, which leads to addressbook explosion. I have many payment vehicles, many instruments, and in a fuller system, many identities. Each demanding at least one petname. And so do my many counterparties. A second part of the problem is that petnames are those I give myself to some thing, but in some definitional sense, I never export my petnames (which is from which they derive their security). Meanwhile, the owner of another thing also has a name for it which she prefers to communicate about, so it transpires that there is a clash between her petname and my petname. To resolve this I am exploring the use of nicknames, which are owner-distributed names, in contrast to petnames which are private names. Which of course challenges the user even more as she now has two namespaces of subtle distinction to manage. Kerckhoffs rolls six times in his grave. Then rises the notion of secured nicknames, as, if Alice can label her favourite payment receptacle "Alice's shop" then so can Mallory. Doh! Introduction can resolve that in theory, but in practice we're right back to the world of identity trickery and phishing. So we need a way to securely accept nicknames, deal with clashes, and then preserve that security context for the time when someone wishes to pay the real Alice. Otherwise we're back to that pre-security world known as secure browsing. Then, map the privacy question over the above mesh, and we're in a traffic analyst's wetdream. One minor advantage here is that, presswise, we only need to do a little better than Bitcoin, which is no high barrier ;) In sum, I think ZT has inspired us. It asks wonderfully elegant questions, and provides a model to think about the issues. Petnames and related things like capabilities answer a portion of those questions, but many remain. Implementation challenges! Because email addresses and urls are already for the most part non human memorable, we already have implementations of Zooko's triangle which seem to work fine for the ordinary end user. The old petname tool, (which has now probably succumbed to bitrot) used the browser's bookmark list to store public key data, thus was an implementation of Zooko's triangle, that piggy backed on the browser's implementation of Zooko's triangle for non human memorable urls. It worked fine for me. My petnames are still on the browser bar, providing easy access to my bank and stuff, though no longer providing security. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] IPv6 and IPSEC
On Wed, Aug 28, 2013 at 01:47:01PM -0400, Phill wrote: > (This is the last week before school goes back which is stopping me getting > to the big iron and my coding platform if folk are wondering where the code > is). > > > I had a discussion with some IETF types. Should I suggest a BOF in Vancouver? > Maybe this is an IRTF effort rather than IETF. One thing that we maybe should > face is IPR considerations and move what is becoming a design discussion to a > list with an established IPR rubric like Note Well. In the past I have had > whole standards efforts collapse because Microsoft or whoever objected to the > IPR being possibly contaminated by being discussed in a forum without an IPR > regime (though I suspect that was a pretext rather than a reason). > > One question is whether we could make use of IPSEC and/or IPv6. Now I do not > for an instant accept that we should make any proposal dependent on > deployment of either. However IPv6 does have some very convenient > characteristics for traffic analysis hardening. > > My view has always been that the proper approach to security is to have > multiple layers so I would see IPSEC as being an addition to TLS and message > layer security. As of about 10 days ago, Gmail began rejecting incoming IPv6 SMTP traffic from IPv6 address for which the forward and reverse DNS do not match. Since forward and reverse DNS will rarely match for IP addresses used by individuals rather than service providers, this change precludes home users of IPv6 from sending email to Gmail acccount. So unless you never send email to Gmail users or control both forward and reverse DNS, IPv6 is (no longer) suitable for sending email. Note that this new restriction imposed by Gmail only applies to IPv6 addresses, not IPv4 addresses. I had to disable IPv6 in postfix to continue to be able to send to Gmail. Here is the error message: : host gmail-smtp-in.l.google.com[2a00:1450:400c:c05::1b] said: 550-5.7.1 [2001:888:2133:0:82:94:251:205 16] Our system has detected that 550-5.7.1 this message does not meet IPv6 sending guidelines regarding PTR 550-5.7.1 records and authentication. Please review 550 5.7.1 https://support.google.com/mail/answer/81126 for more information. x13si636989wij.49 - gsmtp (in reply to end of DATA command) Google's support URL in the 550 error contains this gem: "Additional guidelines for IPv6 The sending IP must have a PTR record (i.e., a reverse DNS of the sending IP) and it should match the IP obtained via the forward DNS resolution of the hostname specified in the PTR record. Otherwise, mail will be marked as spam or possibly rejected." [The support URL then also talks about recommending SPF or DKIM, but enabling SPF does not stop the 550 errors] --Lucky, who long ago IPv6-enabled every single system under his control. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Source for protocol compiler
The source is up on sourceforge now. It does need some spring cleaning and documenting which I hope to get to next week. The documentation is in the following directory https://sourceforge.net/p/jsonschema/code/ci/master/tree/Web/ The origins of this work is that about 70% of the effort in working groups goes into debating 'bikeshed' type issues (as in what color to paint it) that really don't matter. Things like choice of encoding (just use JSON) or binding (Any reason to not use HTTP + SSL) and so on. And 70% of the effort of the editor would go into making changes to the spec which would need to be reflected accurately in six different parts of the document and the reference code and then conformant examples generated and inserted at the right place and then other folk would have to check it was all done right. So JSONSchema converts an abstract schema definition (in a programming language syntax, not JSON encoding!) and produces a stub client API and a stub server with the appropriate holes to plug in your semantics. You can then write documentation and insert examples from running code (provided you like documentation in either HTML or Internet Draft format at the moment). It is all written in C# and has been run on OSX and Linux under Mono (binary distributions to follow). The synth currently only generates code in C# but I plan to add C and probably Objective C down the line. The meta-synthesiser is also on sourceforge and open source: https://sourceforge.net/projects/goedel/ The compiler only supports RPC like interactions at the moment, i.e. query/response. But I am planning to expand the generator to support an additional interaction pattern in which the client opens a transaction and receives a series of async callbacks. That would be suited to supporting chat like protocols. One of the things I realized as I was doing all this is that all Web Services really consist of are glorified RPC calls in a different syntax. The code generated right now is targeted at being reference code but there is no reason why the synth should not generate production code. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Separating concerns
On Wed, Aug 28, 2013 at 4:15 PM, Phill wrote: > My target audience, like Perry's is people who simply can't cope with > anything more complex than an email address. For me secure mail has to look > feel and smell exactly the same as current mail. The only difference being > that sometime the secure mailer will say 'I can't contact that person > securely right now because…' > I agree with Perry and Phill that email experience should be essentially undisturbed in the normal case, though it's OK to add an additional authorization step. One thing that irks me, though, is the problem of the robust, secure terminal: if everything is encrypted, how does one survive the loss/theft/destruction of a computer or harddrive? I'm no ignoramus, yet I have, several times, lost data I cared about due to hardware failure or theft combined with improper backup. How is a total newbie to do? Most newbies rely on things surviving despite their lack of explicit caution. Currently, they do it by basically trusting Google or some other company with their mail. Whichever way you do things to make them responsible for keys will lead to either (1) failure because it's technically too hard, and/or (2) automated attacks on the weak point that handles things for them. For instance, you have a program that automatically recovers keys from the escrow modulo a few questions. Then, either few questions are too hard and he actually looses the keys, or they are easy enough that the attacker can find answers and recover the key. Or, you have standardized key management and backup policies. Then the attacker can look at the standardized location for the precious keys, and modulo extraction of some master key, can automatically steal everyone's wallet. And then, to prevent automatic extraction of security data, you find that you need not just an appropriate distributed infrastructure (which is more painful to fund if you can't sell the data and require an explicit transaction from the user), but also secure terminals — which implies a secure OS, and hardware that you actually control, rather than big corporations that bend over for big governments. That's a lot of yak to shave to provide end-users (or even average geeks) with seemless secure email. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Being generous is inborn; being altruistic is a learned perversity. No resemblance — — Robert Heinlein, "Time Enough For Love" ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Separating concerns
On Aug 28, 2013, at 2:04 PM, Faré wrote: > On Wed, Aug 28, 2013 at 4:15 PM, Phill wrote: >> My target audience, like Perry's is people who simply can't cope with >> anything more complex than an email address. For me secure mail has to look >> feel and smell exactly the same as current mail. The only difference being >> that sometime the secure mailer will say 'I can't contact that person >> securely right now because…' >> > I agree with Perry and Phill that email experience should be > essentially undisturbed in the normal case, though it's OK to add an > additional authorization step. > > One thing that irks me, though, is the problem of the robust, secure > terminal: if everything is encrypted, how does one survive the > loss/theft/destruction of a computer or harddrive? I'm no ignoramus, > yet I have, several times, lost data I cared about due to hardware > failure or theft combined with improper backup. How is a total newbie > to do? You have to have key backup to address that security goal. And that will necessarily mean that you increase your coercion risk. And which security goal you choose to satisfy is likely to depend on your situation. One solution would be to back up your private key and put the shares in one or more bank safes. But then you are vulnerable to a coercion attack on your bank. Which you can address by putting the shares in a tamper evident bag but only if you go to the bank regularly to audit it. One of the features of this problem is that if you make absolute security a requirement you are going to go absolutely potty trying to solve every element. Fortunately we can still do a lot of good by providing a system that prevents wholesale abuses. I am not a crypto-absolutist. I don't particularly want to be giving crypto to terrorists. When I was 18 I woke up to hear that the IRA had attempted to murder my cousin. However I don't want to be giving intercept power to Putin who murders people with poisoned teapots on the streets of London either. And I certainly don't trust the NSA and GCHQ with the wholesale intercept capability revealed by Snowden. > Most newbies rely on things surviving despite their lack of explicit > caution. Currently, they do it by basically trusting Google or some > other company with their mail. Whichever way you do things to make > them responsible for keys will lead to either (1) failure because it's > technically too hard, and/or (2) automated attacks on the weak point > that handles things for them. And for a company it is almost certain that 'secure against intercept by any government other than the US' is an acceptable solution. > That's a lot of yak to shave to provide end-users (or even average > geeks) with seemless secure email. I am currently working on a podcast history of the web to publicize my expert witness practice. Which had me looking at the reason Tim Berners Lee succeeded where Ted failed. The thing that distinguished their efforts was not the problems they solved. Ted had 120% of the Web ten years before Tim started. The difference was that Tim realized that some of the problems were very hard and could be punted on for a first draft. Then after the Web took off it built out infrastructure that made it possible for others to fill in the gaps. So Ted had search built in. Tim had a hole which was filled by others. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] IPv6 and IPSEC
(This is the last week before school goes back which is stopping me getting to the big iron and my coding platform if folk are wondering where the code is). I had a discussion with some IETF types. Should I suggest a BOF in Vancouver? Maybe this is an IRTF effort rather than IETF. One thing that we maybe should face is IPR considerations and move what is becoming a design discussion to a list with an established IPR rubric like Note Well. In the past I have had whole standards efforts collapse because Microsoft or whoever objected to the IPR being possibly contaminated by being discussed in a forum without an IPR regime (though I suspect that was a pretext rather than a reason). One question is whether we could make use of IPSEC and/or IPv6. Now I do not for an instant accept that we should make any proposal dependent on deployment of either. However IPv6 does have some very convenient characteristics for traffic analysis hardening. My view has always been that the proper approach to security is to have multiple layers so I would see IPSEC as being an addition to TLS and message layer security. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why human-readable IDs (was Re: Email and IM are ideal candidates for mix networks)
On Aug 28, 2013, at 11:18 AM, Dave Horsfall wrote: > On Wed, 28 Aug 2013, Perry E. Metzger wrote: > >> Anyway, I've already started implementing my proposed solution to that >> part of the problem. There is still a need for a distributed database to >> handle the lookup load, though, and one that is not the DNS. > > (Delurking) > > This suggests the use of LDAP. I don't see that at all. In fact I think that nothing has hurt deployment of PKI more than LDAP. The problem for the email client is very simple: "What is the key etc. to send email to al...@example.com" I can solve that very easily with a HTTP lookup or a very short Web Service with JSON query syntax. If LDAP is involved there will be a consultant setting up the directory and building fancy DIT trees and racking up bills of $100,000+ for something that makes no difference to the actual query. Now if the certs are already in an LDAP directory then fine, lets pull data from that resource. But if they are not in LDAP already there are much easier ways to interface a database of certs to a query interface. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Petnames & Zooko's triangle -- theory v. practice (was Email and IM are...)
On Wed, Aug 28, 2013 at 5:33 AM, ianG wrote: > Yes. I was never scared of the NSA. But the NSA and the FBI and the DEA > and every local police force ... that's terrifying. That's a purer essence of > terror, far worse than terrorism. We need a new word. It's a boot stamping on a human face, forever. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why human-readable IDs (was Re: Email and IM are ideal candidates for mix networks)
On Wed, 28 Aug 2013, Perry E. Metzger wrote: > Anyway, I've already started implementing my proposed solution to that > part of the problem. There is still a need for a distributed database to > handle the lookup load, though, and one that is not the DNS. (Delurking) This suggests the use of LDAP. -- Dave ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Email and IM are ideal candidates for mix networks
On Wed, 28 Aug 2013, Jerry Leichter wrote: > On the underlying matter of changing my public key: *Why* would I have > to change it? It's not, as today, because I've changed my ISP or employer > or some other random bit of routing information - presumably it's because > my public key has been compromised. Maybe it's because you've forgotten the passphrase guarding the corresponding private key? Or because you'd like to do the electronic equivalent of "change my name, start [this facet of] my electronic life over"? -- -- "Jonathan Thornburg Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA "There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time." -- George Orwell, "1984" ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/27/2013 09:47 PM, Jonathan Thornburg wrote: > Assuming it were widely deployed, would > DNSSEC-for-key-distribution be a reasonable way to store > email_address --> public_key mappings? It might be a reasonable way of protecting PGP key information in DNS records so that someone doesn't try inserting their own when it's looked up. Here's something I've been playing with for the first half of this: http://www.gushi.org/make-dns-cert/HOWTO.html - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ "The enemies know the system. The allies do not." --Jay Jacobs -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIeEFIACgkQO9j/K4B7F8EDGQCfdLmwFha87qK3PjVaUBD2gB+4 S90AoKkoy+lg6Pyww5HvV+fRJ2IcnhSg =jZy3 -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why not the DNS? (was Re: Implementations, attacks on DHTs, Mix Nets?)
On Aug 28, 2013, at 8:34 AM, Perry E. Metzger wrote: > On Tue, 27 Aug 2013 23:39:51 -0400 Jerry Leichter > wrote: >> It's not as if this isn't a design we have that we know works: >> DNS. Read what I said: There's a *design* that works. I never suggested *using DNS* - either its current physical instantiation, or even necessarily the raw code. In fact, I pointed out some of the very problems you mention. What defines the DNS model - and is in contrast to the DHT model - is: - Two basic classes of participants, those that track potentially large amounts of data and respond to queries and those that simply cache for local use; - Caching of responses for authoritative-holder-limited amounts of time to avoid re-querying; - A hierarchical namespace and a corresponding hierarchy of caches. DNS and DNSSEC as implemented assume a single hierarchy, and they map the hierarchy to authority. These features are undesirable and should be avoided. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why human-readable IDs (was Re: Email and IM are ideal candidates for mix networks)
A different take on the problem: Would something built around identify-based encryption help here? It sounds very tempting: My email address (or any other string - say a bitmap of a picture of me) *is* my public key. The problem is that it requires a central server that implicitly has access to my private key. There are some proposals around to work around that (e.g., by constructing the key from a combination of keys from different key generators). But we could go another route: I can run a key generator on my own hardware. That doesn't quite solve the problem, since you now need a secure way to find my key generator - any generator will happily tell you how to encrypt using leich...@lrw.com to generate the public key, and *it* will have the corresponding private key. I don't quite see how to make this work, but IBE seems like a primitive that might be helpful, somehow. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why human-readable IDs (was Re: Email and IM are ideal candidates for mix networks)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is exactly the problem that Kim Cameron and I tried to solve by developing what we called "call signs." The idea is to compress the hash of the public by solving a puzzle: find the arbitrary "salt" so that the hash of the salt and the public key ends with a large enough number of zeroes. (Or 1, or any arbitrary patterns.) Publish then the "call sign" as a fraction of the hash, say the leading bits, that is short enough to be memorized, or at least written on a napkin. Of course, you have to verify that N bits of call signs + M zeroes is long enough to provide a strong hash. The birthday paradox tells us that collisions will happen after 2^(N/2) users in the same space. We assumed that the practical length was at most 10 characters, 50 bits, which means collisions would happen after a few million users. We mitigated that by adding a human identifier in the mix, making the call sign something like "Perry.A32-H45Z-ZE0." Now the collisions only happen in the space of "all people named Perry", which is much smaller than "everybody." Of course, this was a Microsoft project, which Microsoft did not choose to develop. And it was patented... - -Original Message- From: cryptography-bounces+huitema=huitema@metzdowd.com [mailto:cryptography-bounces+huitema=huitema@metzdowd.com] On Behalf Of Perry E. Metzger Sent: Wednesday, August 28, 2013 5:53 AM To: Jerry Leichter Cc: Wendy M. Grossman; cryptography@metzdowd.com Subject: [Cryptography] Why human-readable IDs (was Re: Email and IM are ideal candidates for mix networks) On Tue, 27 Aug 2013 23:52:23 -0400 Jerry Leichter wrote: > But none of that matters much any more. "Publication" is usually > on-line, so contact addresses can be arbitrary links. When we meet > in person, we can exchange large numbers of bits between our > smartphones. Hell, even a business card can easily have a QR code > on the back. Just as an FYI, this describes exactly zero of the times that I've gotten people's email or jabber addresses in recent years. Very typically people have written them down for me, told them to me over the phone, or the equivalent. I've had to read mine over the phone a fair bit, too. I wouldn't know how to trust publication online in the first place. "Perry Metzger's email is " "How do I know that's true?" "Because it is encrypted in " "What if that's a lie? I've never heard Perry utter " "What, you don't trust me? No dishonest person has a web server!" If someone tells me they're f...@example.com, and I have a trustworthy way of mapping f...@example.com into a long lived key (see my first message in this sequence of three that triggered this discussion), life is a lot better. I think this alone is a lot of why X.500 died so fast compared to SMTP -- the addresses were simply untenable, and they were at least in theory human readable. Anyway, I've already started implementing my proposed solution to that part of the problem. There is still a need for a distributed database to handle the lookup load, though, and one that is not the DNS. Perry - -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) Comment: Using gpg4o v3.1.107.3564 - http://www.gpg4o.de/ Charset: utf-8 iQEcBAEBAgAGBQJSHgr0AAoJELba05IUOHVQdwgH/2bhJZYagObK1yzl27r9w+BP ests/CMmUOVxnAnICY0MeoH5/GLbyNX2u5ZKGh32DikoTCFEHpMItgxpT8hQpEtD 81j5NV4X2qRaYc183C0HGxpJe2Cq2vQNAVGTJbJAV08dDZuu2W/IxuPsBjF0U3p+ yxham0qSnbngYSNBi31WXg4X08EV/Z3H5NoTsWkiHfSs+LLcyT9uNXwi7IxP4tmU filmYGKBIdw16A9wGuqAy/V7edFG4tqgNtVdKH+yAYDGwY7NW+NYzOQCn8HOMQ4w sxXMDuUEg+KQ1PvtfIgk3tfTSEb45Rsiu9VH2Vir9PKOzzCzQIneJvG2V8nCDdI= =AtVw -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why human-readable IDs (was Re: Email and IM are ideal candidates for mix networks)
On Aug 28, 2013, at 8:52 AM, Perry E. Metzger wrote: > On Tue, 27 Aug 2013 23:52:23 -0400 Jerry Leichter > wrote: >> But none of that matters much any more. "Publication" is usually >> on-line, so contact addresses can be arbitrary links. When we meet >> in person, we can exchange large numbers of bits between our >> smartphones. Hell, even a business card can easily have a QR code >> on the back. > > Just as an FYI, this describes exactly zero of the times that I've > gotten people's email or jabber addresses in recent years. Very > typically people have written them down for me, told them to me over > the phone, or the equivalent. I've had to read mine over the phone a > fair bit, too. The apps to make the transfer easy don't exist, so we still use the old mechanisms. Think about the absurdity: You have a high-speed digital connection to someone, and rather than using it to transfer a couple of hundred bits reliably, you encode it ambiguously in an analogue waveform, write it down on a piece of paper, then type that data back in. Yes, it works - but does that sound like a rational way to do things? > I wouldn't know how to trust publication online in the first > place. In exactly the same way you trust paper publications that contain today's style of addresses. > > "Perry Metzger's email is " > "How do I know that's true?" And exactly how is this different from "Perry Metzger's email is pe...@piermont.com"? > "Because it is encrypted in " > "What if that's a lie? I've never heard Perry utter " > "What, you don't trust me? No dishonest person has a web server!" > > If someone tells me they're f...@example.com, and I have a trustworthy > way of mapping f...@example.com into a long lived key (see my first > message in this sequence of three that triggered this discussion), > life is a lot better. A minority of people have addresses that are easy to remember. Most - by far the majority - have some random-looking set of letters and digits with some part of their first or last name or a nickname embedded somewhere inside at gmail or yahoo or some institution. You can say "Well, if everyone has their own server, then they can pick their own name" - but then you end up with non-memorable domain names. Frankly, I have trouble remembering the last time I got someone's email address by having them tell it to me. Most addresses come to me these days from LDAP or a similar institutional database; or embedded in a mail message (like one of the ones on this list); or printed somewhere. Since I got a domain name way back when it was actually possible to get three-letter names, I have an address that's reasonably easy to tell people - so I'll often tell them, after they've rattled off something I'll certainly forget within minutes - "write to me at leich...@lrw.com so I'll have your address". :-) > I think this alone is a lot of why X.500 died > so fast compared to SMTP -- the addresses were simply untenable, and > they were at least in theory human readable. X.500 died because everything it was connected to died. And in the end it never actually got to the point where it solved anyone's problems. > Anyway, I've already started implementing my proposed solution to > that part of the problem. There is still a need for a distributed > database to handle the lookup load, though, and one that is not the > DNS. It's perfectly reasonable to have human-name-to-computer-identity maps. It's certainly something I depend on all the time at a local level: Mail.app knows tons of addresses I use, and if all else fails I can, and do, search my previous email's to find someone's address. (That makes for a much more flexible, and useful, person database than any stand-alone database I've seen: I can search based on anything I can remember about the person, such as what he wrote about, when we last corresponded, who else was involved in the conversation.) Large institutions have their own internal databases. But a global database seems rather pointless to me. There are too many people with similar names. Try using LinkedIn to find someone who you only know a bit about by name. Sometimes it works; sometimes you find ten people who *might* be the person you're looking for. The whole notion of talking securely to someone who you yourself have no way of specifying uniquely is incoherent. No clever implementation can help. -- Jerry > Perry > -- > Perry E. Metzger pe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Separating concerns
My target audience, like Perry's is people who simply can't cope with anything more complex than an email address. For me secure mail has to look feel and smell exactly the same as current mail. The only difference being that sometime the secure mailer will say 'I can't contact that person securely right now because…' I also agree that the devil is in the deployment. And that is why I think we need to separate concerns. We are not going to get anywhere if each and every one of us who has an idea has to implement an email client to make it work. And we certainly won't get any deployment if we have to deploy plug ins and other stuff for 50+ MUAs. My experience of SET was that the scheme failed largely because it lacked agility. The first draft of the protocol was to burdensome to use. But we could not persuade banks who had paid $6 million to a vendor to deploy SETv1 to pay the same vendor another $6 million for the changes necessary to deploy a V2. In the case of secure email there is an asymmetry. I think that deployed S/MIME has the problem of receiving and decrypting mail solved pretty well. The part that remains broken is establishing keys and sending the messages. Which is why I think a critical step is to separate out the parts of the problem which can fixed for all proposals from the parts where innovation is possible. I consider the following parts of the problem to be fixed: 1) Message formats: S/MIME There is no intrinsic advantage to PGP or S/MIME format so choose one format according to which has the larger installed base. S/MIME wins. End of story. This does not mean committing to S/MIME PKI, or not supporting Web of Trust, but it does mean using CMS/PKCS#7 for message packaging. 2) MUA crypto User Interface: None There must be no demand made of the user whatsoever. No button to press to send the message encrypted instead. The message is encrypted if the MUA can send it encrypted, end of story. The only UI that may be needed in the MUA would be to give the user feedback as to why something can't be sent. As it happens, I have been working on a protocol to provide exactly this degree of separation. The idea being that the MUA makes a (secured) remote procedure call to a trusted service that tells it: 1) Whether the email should be sent encrypted 2) The crypto parameters (key, algorithm, etc,) to use if so 3) (optional) proof that allows the MUA to validate the action of the trusted service if the assertion of the trusted service is audit able and the MUA understands how to validate the assertion. So here is how I would see it working, I have a scheme that combines elements of Certificate Transparency with a meta-notary scheme I have been working on. To implement this scheme I would write the necessary handlers for an omnibroker server to allow us to deploy the scheme and test it. If we find we need to tweak the scheme we tweak the omnibroker side of the scheme, the MUA side stays constant. If we think it is ready for prime time we can reduce the trust dependency on the broker by migrating some or all of the checking into the MUA. In practice it is likely that we would have omnibrokers that support more than one scheme and in particular provide support for legacy schemes as well. If we have six schemes and three get some sort of traction then we are likely to want to combine ideas into a seventh rather than fight a VHS vs Betamax. In my particular scheme the omnibroker is a permanent fixture as my approach is to attempt to mitigate the risks of using trusted third parties through separation of duties and multiple controls rather than eliminate them entirely. But I think that people will still find a value in using my scheme as a testbed even if they believe that the only acceptable approach is to eliminate the Trusted Third Parties entirely. In practice the cost of crypto expertise is always going to exceed the cost of crypto products. I don't know what folk charge in the bargain basement for crypto clues but I rather doubt its less than my plumber. If someone can make a buck from a PRISM Proof email scheme then they will have a motive to facilitate deployment and spread it quicker. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why human-readable IDs (was Re: Email and IM are ideal candidates for mix networks)
> There is still a need for a distributed > database to handle the lookup load, though, and one that is not the > DNS. > What do you think of namecoin? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Truth comes as conqueror only to those who have lost the art of receiving it as friend. — Tagore ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why human-readable IDs (was Re: Email and IM are ideal candidates for mix networks)
On Wed, 28 Aug 2013 10:24:43 -0400 Jerry Leichter wrote: > > I wouldn't know how to trust publication online in the first > > place. > > In exactly the same way you trust paper publications that contain > today's style of addresses. But I don't. As I said, I typically get a friend or collaborator's email address from them or from someone else I know. I don't get them from paper publications, or QR codes. Often as not they are literally written on cocktail napkins at conference receptions. > > "Perry Metzger's email is " > > "How do I know that's true?" > And exactly how is this different from "Perry Metzger's email is > pe...@piermont.com"? If you meet me and I say it to you, I'm probably reasonably correct about it. If you ask a mutual friend what it is (possibly by email), they're probably reasonably correct. > A minority of people have addresses that are easy to remember. That's not true, actually. I know because I make a habit of not using an address book in my mail program. In any case, "easy to remember" isn't the issue, "easy to scribble down accurately" is. > Most - by far the majority - have some random-looking set of > letters and digits with some part of their first or last name or a > nickname embedded somewhere inside at gmail or yahoo or some > institution. So, I just did a check. I have a file with all the addresses I care about in it (I manually cut and paste them into email when I want to.) It has 625 addresses in it. Of those, 47 have digits in them. I note that the vast majority of those are addresses of people at Columbia University, which has a particularly bad naming system but where I have a lot of correspondents. Of the rest, the majority are things like "m...@example.com", or "joe.exam...@gmail.com" -- easy to write on a cocktail napkin. I note exactly none of the addresses contain 10 digits of base 64. Even the numeric ones are things like "jrn26" for someone with those initials, which is pretty easy to scribble down. > Frankly, I have trouble remembering the last time I got someone's > email address by having them tell it to me. For me, it was Monday, over the phone. Anyway, we both have our opinions here, I'm sure we're not going to come to a single agreement. I'm implementing something based on my hunches, I invite others to do the same. Let a thousand flowers bloom... Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Email and IM are ideal candidates for mix networks
On Aug 28, 2013, at 4:24 AM, danimoth wrote: > On 27/08/13 at 10:05pm, Christian Huitema wrote: >>> Suppose, as in Bitcoin, my email address *is* my public key >> >> You can even use some hash compression tricks so you only need 9 or 10 >> characters to express the address as hash of the public key. >> >> That works very well, until you have to change the public key. > > .. and until someone want to find a public key which shares the first > 10 digits of the hash with yours. 9 or 10 *characters*, not *digits*. You need enough bits that, even given the birthday paradox, the probability of this occurring is low enough not to matter. Since the birthday paradox will lead to a 50% probability of collision after about the square root of the number of possible values, given a 10-character signature, that's at about 5 characters. Way too low, for digits. If "characters" are full bytes, 2^40 generated public keys is plausible, though perhaps uncomfortably small; and if the "characters" have to be printable - then I agree, way too low. You could use hash compression, but the retained compressed values will have to be rather larger. Say 150 bits worth, at least. On the underlying matter of changing my public key: *Why* would I have to change it? It's not, as today, because I've changed my ISP or employer or some other random bit of routing information - presumably it's because my public key has been compromised. That's a disaster no matter how I identify myself, one that's very difficult to recover from - pretty much impossible unless (a) there's some way to revoke a key (yes, we've had problems with getting that to work even in the current PKI environment, but there's no real alternative); (b) I've prepared for the eventuality. Given (a), I can send out a signed revocation message. (So can the attacker, but presumably he had bigger plans for the key than just killing it.) Given (b), I have pre-shared one or more replacement keys that I still trust, and my revocation can name the one to put into use. (Of course, it cannot introduce a brand new key!) Done this way, my response to key compromise is no different from normal key rollover. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Email and IM are ideal candidates for mix networks
On 27/08/13 at 10:05pm, Christian Huitema wrote: > > Suppose, as in Bitcoin, my email address *is* my public key > > You can even use some hash compression tricks so you only need 9 or 10 > characters to express the address as hash of the public key. > > That works very well, until you have to change the public key. .. and until someone want to find a public key which shares the first 10 digits of the hash with yours. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Petnames & Zooko's triangle -- theory v. practice (was Email and IM are...)
On 28/08/13 02:44 AM, radi...@gmail.com wrote: Zooko's triangle, pet names...we have cracked the THEORY of secure naming, just not the big obstacle of key exchange. Perhaps in a sense of that, I can confirm that we may have an elegant theory but practice still eludes us. I'm working with a design that was based on pure petnames & ZT, and it does not deliver as yet. One part of the problem is that there are too many things demanding names, which leads to addressbook explosion. I have many payment vehicles, many instruments, and in a fuller system, many identities. Each demanding at least one petname. And so do my many counterparties. A second part of the problem is that petnames are those I give myself to some thing, but in some definitional sense, I never export my petnames (which is from which they derive their security). Meanwhile, the owner of another thing also has a name for it which she prefers to communicate about, so it transpires that there is a clash between her petname and my petname. To resolve this I am exploring the use of nicknames, which are owner-distributed names, in contrast to petnames which are private names. Which of course challenges the user even more as she now has two namespaces of subtle distinction to manage. Kerckhoffs rolls six times in his grave. Then rises the notion of secured nicknames, as, if Alice can label her favourite payment receptacle "Alice's shop" then so can Mallory. Doh! Introduction can resolve that in theory, but in practice we're right back to the world of identity trickery and phishing. So we need a way to securely accept nicknames, deal with clashes, and then preserve that security context for the time when someone wishes to pay the real Alice. Otherwise we're back to that pre-security world known as secure browsing. Then, map the privacy question over the above mesh, and we're in a traffic analyst's wetdream. One minor advantage here is that, presswise, we only need to do a little better than Bitcoin, which is no high barrier ;) In sum, I think ZT has inspired us. It asks wonderfully elegant questions, and provides a model to think about the issues. Petnames and related things like capabilities answer a portion of those questions, but many remain. Implementation challenges! ... And I don't think the wider public was concerned/scared enough to care before Snowden. Let's hope they care long enough to adopt any viable solutions to the problem that might pop up in the wake of all this. The traffic on this list the past week is a very welcome thing. Yes. I was never scared of the NSA. But the NSA and the FBI and the DEA and every local police force ... that's terrifying. That's a purer essence of terror, far worse than terrorism. We need a new word. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Why human-readable IDs (was Re: Email and IM are ideal candidates for mix networks)
On Tue, 27 Aug 2013 23:52:23 -0400 Jerry Leichter wrote: > But none of that matters much any more. "Publication" is usually > on-line, so contact addresses can be arbitrary links. When we meet > in person, we can exchange large numbers of bits between our > smartphones. Hell, even a business card can easily have a QR code > on the back. Just as an FYI, this describes exactly zero of the times that I've gotten people's email or jabber addresses in recent years. Very typically people have written them down for me, told them to me over the phone, or the equivalent. I've had to read mine over the phone a fair bit, too. I wouldn't know how to trust publication online in the first place. "Perry Metzger's email is " "How do I know that's true?" "Because it is encrypted in " "What if that's a lie? I've never heard Perry utter " "What, you don't trust me? No dishonest person has a web server!" If someone tells me they're f...@example.com, and I have a trustworthy way of mapping f...@example.com into a long lived key (see my first message in this sequence of three that triggered this discussion), life is a lot better. I think this alone is a lot of why X.500 died so fast compared to SMTP -- the addresses were simply untenable, and they were at least in theory human readable. Anyway, I've already started implementing my proposed solution to that part of the problem. There is still a need for a distributed database to handle the lookup load, though, and one that is not the DNS. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] human readable IDs, revokable keys (Re: Email and IM are ideal candidates for mix networks)
First of all, I think systems that make people associate arbitrary long strings with someone's email address aren't really acceptable. I'll repeat that my model is "give someone your email address on a napkin in a bar". I do things like this often enough right now. On Wed, 28 Aug 2013 06:41:27 -0400 Jerry Leichter wrote: > On the underlying matter of changing my public key: *Why* would I > have to change it? Because people make mistakes and reveal security critical information to the world at intervals. Because computers are sometimes compromised. A system that does not permit you to recover from rare events is not going to deploy very well. I think that to begin with, though, a system that requires people to somehow associate arbitrary strings with their friends won't work either. Anyway, I proposed a system to handle id to key mappings with reasonable trust in the first of my three messages on my proposed new model -- it also happens to handle revocation reasonably well (though imperfectly). Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Why not the DNS? (was Re: Implementations, attacks on DHTs, Mix Nets?)
On Tue, 27 Aug 2013 23:39:51 -0400 Jerry Leichter wrote: > It's not as if this isn't a design we have that we know works: > DNS. As I said elsewhere: as a practical matter, almost no one using email is a DNS administrator. This therefore cannot possibly deploy in finite time for the average user. If your mailbox is in a domain name controlled by someone else, you may wait effectively forever for permission. Indeed, DNSSEC itself has waited forever as a result of that. Furthermore, this is unacceptable because the trust model is unacceptable. If you are a user of gmail, for example, it implies that Google is in the trust loop for telling the world security critical information, like, for example, your key. Sovereign threats can order Google to insert different keys at will. As I've said elsewhere: the DNS is a very architecturally tempting idea for all of this. I fully understand why people would want to do it that way. It is not, however, practical if one wants to deploy in months and not decades, and it makes trust entirely hierarchical. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
