Re: [Cryptography] Functional specification for email client?
Some comments, only. On 30/08/13 11:11 AM, Ray Dillinger wrote: Okay... User-side spec: 1. An email address is a short string freely chosen by the email user. It is subject to the constraint that it must not match anyone else's email address, but may (and should) be pronounceable in ordinary language and writable with the same character set that the user uses for writing. They require extension with a "domain" as current email addresses do, but not a "domain name" in the IETF sense; just a chosen disambiguator (from a finite set of a million or so) to make name collisions less of a problem. 2. An email user may have more than one email address. In fact s/he can make up more email addresses at any time. He or she may choose to associate a "tagline" -- name, handle, slogan or whatever -- with the address. An email user may have one or more identities... (confusion between email addresses, keys, chat handles, etc). 3. When an email user gets an email, s/he is absolutely sure that it comes from the person who holds the email address listed in its "from" line. S/he may or may not have any clue who that person is. S/he is also sure that no one else has seen the contents of the email. The "tagline" and email address are listed in the "from:" line. This requirement is troubling, and it has bedevilled many systems because it has artificially locked them into perfect traffic analysis, low key agility, poor economics, and messy identity semantics. It typically is an assumption of the email providers that an email address must have a certificate, and this allows the certificate to be 'checked' against the email address. But it is not necessary nor particularly effective. A better requirement might be worded: When a user receives an email, she is sure that it comes from the stated identity as found in the address book. The stated identity may not be related to the "from" line. 4. A user has an address book. The address book can be viewed as a whole or as seen by just one of the user's email addresses. IOW, if you have an email address that you use for your secret society and a different email address that you use for your job, you can choose to "be" one or the other and your address book will reflect only the contacts that you have seen from that address or have been visible to under that address. 5. A mail client observes all email addresses that go through it. all identities (email addresses and/or keys)... When a user receives mail from someone who has not directly sent them mail before, the client opens a visible entry in the address book and makes available a record of previous less-direct contacts with that address, for example from posts to mailing lists, from CC: lists on emails, etc. The client also makes visible a list of possible contact sources; places where the correspondent may have seen the address s/he's writing to. However, often enough, especially with cases where it's a "scribbled on a napkin" address, the client just won't know. 6. When a user sends mail, s/he knows that no one other than the holder of the address/es s/he's sending it to will see the body of the mail, and also that the recipient will be able to verify absolutely that the mail did in fact come from the holder of the user's address. This needs to nailed down, otherwise the system falls into the abyss of digital signatures. What this means (at a lower level) is that every mail is digitally signed by the sender. It needs to be stated that the signature of the sender's key means that the message came from the sender's key, and not anything else. Especially, it is not a signed contract, not a non-repudiable bla bla, and is not even a proof that the person sent the message (without significant other support). That is, the digsig is a low-level protocol tool, not a legal digital signature. Also, to bed in a complete understanding, a separate requirement 6.b should be added for a second signing process using separate "signing keys" following the notions expressed in (eg) EU digital signature directive (eg) OpenPGP cleartext signing. However, this should be clearly stated as optional, as such digital signatures are fraught, and if not optional, the system will fail to be implemented and be accepted. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
On 08/30/2013 08:10 PM, Aaron Zauner wrote: I read that WP report too. IMHO this can only be related to RSA (factorization, side-channel attacks). I have been hearing rumors lately that factoring may not in fact be as hard as we have heretofore supposed. Algorithmic advances keep eating into RSA keys, as fast as hardware advances do. A breakthrough allowing most RSA keys to be factored could be just one or two more jumps of algorithmic leverage away (from academics; possibly not from the NSA). It could also be the case that special-purpose ASICs that accelerate the process substantially may have been designed and built. We know about Shor's algorithm for factoring in NlogN time. It requires a quantum computer to run though. We have heard rumors of quantum computers being built, and I recall a group of academics who actually built one nearly eight years ago. That seems to be the sort of thing that would attract attention from a lot of three-letter agencies, and efforts to scale it up would be intensely supported with all the resources and brainpower that such an organization could bring to bear. How far have they come in eight years? It is both interesting and peculiar that so little news of quantum computing has been published since. Bear ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
On 31/08/13 06:10 AM, Aaron Zauner wrote: On Aug 30, 2013, at 1:17 PM, Jerry Leichter wrote: So the latest Snowden data contains hints that the NSA (a) spends a great deal of money on cracking encrypted Internet traffic; (b) recently made some kind of a cryptanalytic "breakthrough". What are we to make of this? (Obviously, this will all be wild speculation unless Snowden leaks more specific information - which wouldn't fit his style, at least as demonstrated so far.) I read that WP report too. IMHO this can only be related to RSA (factorization, side-channel attacks). It's all speculation of course, but that is what it feels like to me. An interesting clue from the earlier report is that they aren't there yet, they're building towards a capability. They've figured out some way to crack in theoretically, and with a big investment they'll get there. Which suggests a combination of massive crunch power, keys on the margin *and* cribs from side-channel attacks. The bright shiny new 3rd division of the NSA is responsible for the side-channel attack. And it was very expensive... Coincidence? Or, it could all be fluff, designed to suck money from cow in w.DC. Many a conman has made rich by claiming some secret invention; the investors are the muggins for putting their money in without doing the due diligence. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
If I had to bet, I'd bet on bad rngs as the most likely source of a breakthrough in decrypting lots of encrypted traffic from different sources. --John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Functional specification for email client?
I think it makes sense to separate out the user-level view of what happens (the first five or six points) from how it's implemented (the last few points, and any other implementation discussions). In order for security to be usable, the user needs to know what he is being promised by the security mechanisms--not which digital signature scheme is being used or whether decoy messages are sent to frustrate traffic analysis. If something arrives in my inbox with a from address of nob...@nowhere.com, then I need to know that this means that's who it came from. If I mail something to nob...@nowhere.com, then I need to know that only the owner of that address will be able to read it. I need to know that nobody should be able to know with whom I'm communicating. But I don't need to know about keys, digital signatures, mix nets, etc. That's what I want to know as a cryptographer, but as a user, I just want to know what the security system is promising and how reliable its promises are. My intuition is that binding the security promises to email addresses instead of identities is the right way to proceed. I think this is something most people can understand, and more importantly it's something we can do with existing technology and no One True Name Authority In The Sky handing out certs. One side issue here is that this system's email address space needs to somehow coexist with the big wide internet's address space. It will really suck if someone else can get my gmail address n the secure system, but it will also be confusing if my inbox has a random assortment of secure and insecure emails, and I have to do some extra step to know which is which. --John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Keeping backups (was Re: Separating concerns
On 8/29/13 11:30 AM, Perry E. Metzger wrote: > On Wed, 28 Aug 2013 20:04:34 +0200 Faré wrote: >> 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? > > So, as has been discussed, I envision people having small cheap > machines at home that act as their "cloud", and the system prompting > them to pick a friend to share encrypted backups with. Why not share some parts with some friends and some with others? This is related to the recently-discussed idea of a network of friends (maybe it's because I've worked on Jabber for so long, but I like the idea of leveraging your buddy list for many interesting features, including data backup and mix networking). Peter -- Peter Saint-Andre https://stpeter.im/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
On 2013-09-01 4:02 AM, Ray Dillinger wrote: On 08/30/2013 08:10 PM, Aaron Zauner wrote: I read that WP report too. IMHO this can only be related to RSA (factorization, side-channel attacks). I have been hearing rumors lately that factoring may not in fact be as hard as we have heretofore supposed. Algorithmic advances keep eating into RSA keys, as fast as hardware advances do. So far, not much affect on elliptic keys. Except that all elliptic keys of the extremely useful gap-diffie-hellman group are potentially subject to techniques analogous to those that are attacking RSA. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts about keys
On 2013-08-25 16:29:42 -0400 (-0400), Perry E. Metzger wrote:
[...]
> If I meet someone at a reception at a security conference, they might
> scrawl their email address ("al...@example.org") for me on a cocktail
> napkin.
>
> I'd like to be able to then write to them, say to discuss their
> exciting new work on evading censorship of mass releases of stolen
> government documents using genetically engineered fungal spores to
> disseminate the information in the atmosphere worldwide.
>
> However, in our new "everything is always encrypted" world, I'll be
> needing their encryption key, and no one can remember something as
> long as that.
>
> So, how do I translate "al...@example.org" into a key?
>
> Now, the PGP web-of-trust model, which I think is broken, would have
> said "check a key server, see if there's a reasonable trust path
> between you and Alice."
[...]
At free software conferences, where there is heavy community
penetration for OpenPGP already, it is common for many of us to
bring business cards (or even just slips of paper) with our name,
E-mail address and 160-bit key fingerprint. Useful not only for key
signing (when accompanied by photo identification), but also simply
allows someone to retrieve your key from a public keyserver and
confirm the fingerprint matches the one you handed them.
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Backup is completely separate
So I was thinking about Jon's claim that keys should be 'disposable'. Not sure if I buy that. But I did decide that key backup is a completely separate problem and demands a separate infrastructure. Let us imagine that I do the key-splitting and share in 5 places thing for my Comcast email. I probably need the same for my file system backups as well. And I probably want to be able to rely on the same in the future if I roll keys or whatever. So the way to deal with that problem is to have a separate key escrow protocol. Probably a JSON Web Service. The protocol results in a 'key escrow identifier' which is essentially just a retrieval index on the public key. So mine might be CBK:w9idkw992ksl3. Whenever I initialize a new public key, I give the keygen system that URI and that provides the information necessary to do a backup against my escrow setup. To check that I have the right one the system comes back and says 'Daleks are bad' which is the check phrase I chose when I initialized the system. Beneath the covers the backup scheme is simply locating a public key cert that matches the hash code I gave it, encrypting the private key under the specified public and sending the package to the email address registered in the cert. Probably want some sort of escrow agent that can be trusted to keep the encrypted bits of the private key pair and not lose them (Fort Meade would serve for that) and give them back when needed (ok, Google then). The reason I suggest a hash rather than a domain name is that this system has to work for decades and domain names are not stable enough over those periods. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
On Aug 31, 2013, at 2:02 PM, Ray Dillinger wrote: > ... It is both > interesting and peculiar that so little news of quantum computing has been > published since. I don't understand this claim. Shor's work opened up a really hot new area that both CS people and physicists (and others as well) have rapidly jumped into. There's been a huge amount of publication on quantum computing and, more generally, the field of quantum information. No one - at least publicly - claims to know how to build a non-toy quantum computer here (the D-wave machine, if it's really doing quantum computation, is a special kind of machine and couldn't run Shor's algorithm, for example). But there are many reported advances on the physics. Simultaneously, there's quite a bit of published work on the algorithmic/complexity side as well. A look at http://en.wikipedia.org/wiki/Quantum_computer will readily confirm this. If you want to dig deeper, there's Scott Aaronson's blog at http://www.scottaaronson.com/blog/ -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts about keys
On 2013-09-01 11:16 AM, Jeremy Stanley wrote: At free software conferences, where there is heavy community penetration for OpenPGP already, it is common for many of us to bring business cards (or even just slips of paper) with our name, E-mail address and 160-bit key fingerprint. Useful not only for key signing (when accompanied by photo identification), but also simply allows someone to retrieve your key from a public keyserver and confirm the fingerprint matches the one you handed them. The average user is disturbed by the sight a 160 bit hash. When posting graphic images on my blog, I have to name the image twice, once when I store it on my website, and once when I reference it in a post. Despite the fact that the names are meaningful and human readable, and the total number of images is not unreasonably large, I find it quite difficult to enter exactly the same name the same way twice. Much of the time the image mysteriously fails to appear, even though I cannot see any typo, the two spellings right in front of me look exactly alike. The end user's instinctive fear of 160 bit hashes is well founded.. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
