Re: [Cryptography] Why prefer symmetric crypto over public key crypto?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/7/13 9:06 PM, Christian Huitema wrote: Pairwise shared secrets are just about the only thing that scales worse than public key distribution by way of PGP key fingerprints on business cards. The equivalent of CAs in an all-symmetric world is KDCs. Instead of having the power to enable an active attack on you today, KDCs have the power to enable a passive attack on you forever. If we want secure crypto that can be used by everyone, with minimal trust, public key is the only way to do it. I am certainly not going to advocate Internet-scale KDC. But what if the application does not need to scale more than a network of friends? A thousand times yes. One doesn't need to communicate with several billion people, and we don't need systems that scale up that high. Most folks just want to interact (chat, share photos, voice/video conference, etc.) with their friends and family and colleagues -- maybe 50 - 500 people. IMHO we only need to scale up that high for secure communication. (I'm talking about individual communication, not enterprise stuff.) What about talking with someone new? Well, we can design separate protocols that enable you to be introduced to someone you haven't communicated with before (we already do that with things like FOAF, LinkedIn, Facebook). Part of that introduction might involve learning the new person's public key from someone you already trust (no need for Internet-scale certificate authorities). You could use that public key for bootstrapping the pairwise shared secrets. Another attractive aspect of a network of friends is that it can be used for mix networking (route messages through your friends) and for things like less-than-completely-public media relays and data proxies for voice, video, file transfer, etc. And such relays might just live on those little home devices that Perry is talking about, separate from the cloud. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSLQDNAAoJEOoGpJErxa2phHAQAJ76DfrFmz6Sv+HkczOgxJA1 v0kqmLphDhzgT/9eUiF1cCkowF0HE1l84DTuMefrwT2DmOLZJVQANy0Tg/CzWLRu 3JBDkPRQ/cdlfDyy1ZHNb4bsGWyxHIXViQg2sNQZ9KB8yRF4pouYewXOpoJDIabN G40mVlWzuO5cTUWLColwDCaoR20Q+04Ln19BAiJi58d2UT4c55ZyF45hbbQSYL7T bl1JQkvZdtp2Syn4DaGS+WmCUIGsv5KpdXmZv0ljKXoRqsOW7GjaiaQz84MMMQg9 EHZIDnAetTXdfbEki8AsO5PlGRmi944tHL7DtvXJKd76CY5dIZ6kywMU2g+/LrIn 1uWwTSogu4n4yiQrLyYfOnsttkzJWC9BE9YJXXeH0IN6VRvkC710zphCZLVw6LZJ TsNvtskigIQ9jnPO1le1zkHIagXHhns6fVTURFuWd9ZHCOOdbNT7h6Lj+I8OGCkp KFAbRfXzAQDZgVrl42IZ8Sn4DioCLGbscP3maU/C8J3s1+ega3lxfX3DNbJpX+id FtnaXHfushv9xIkoNT/sBJrg79BblU5ZOH/GUBMwV+rFlWA0ofvIrhkaSnRUPFTI gq2C913YWQfyybolHKRNsZ/JpYjarZAJ5eJdW9ALo3xrCxlTr/EcIek7hCVKBK1o d7FvIpkYoexTO08AKfcZ =GRXj -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Usage models (was Re: In the face of cooperative end-points, PFS doesn't help)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/8/13 1:51 PM, Perry E. Metzger wrote: On Sun, 8 Sep 2013 14:50:07 -0400 Jerry Leichter leich...@lrw.com wrote: Even for one-to-one discussions, these days, people want transparent movement across their hardware. If I'm in a chat session on my laptop and leave the house, I'd like to be able to continue on my phone. How do I hand off the conversation - and the keys? I wrote about this a couple of weeks ago, see: http://www.metzdowd.com/pipermail/cryptography/2013-August/016872.html In summary, it would appear that the most viable solution is to make the end-to-end encryption endpoint a piece of hardware the user owns (say the oft mentioned $50 Raspberry Pi class machine on their home net) and let the user interact with it over an encrypted connection (say running a normal protocol like Jabber client to server protocol over TLS, or IMAP over TLS, or https: and a web client.) Yes, that is a possibility. Personally I'm still mulling over whether we'd want your little home device to be a Jabber server (typically requiring a stable IP address or an FQDN), a standard Jabber client connected to some other server (which might be a personal server at your VPS or a small-scale server for friends and family), or something outside of XMPP entirely that merely advertises its reachability via some other protocol over Jabber (in its vCard or presence information). It is a compromise, but one that fits with the usage pattern almost everyone has gotten used to. It cannot be done with the existing cloud model, though -- the user needs to own the box or we can't simultaneously maintain current protocols (and thus current clients) and current usage patterns. I very much agree. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSLQUgAAoJEOoGpJErxa2p9NUP/3R2p37pupeFB3GV5NJt1sN9 kOO+P9TXO8Ra3WXeQcNcwe43tVfpKlJIbHa9tZbs5Mvl6F2TSqChTxZ2ftS178Ul QAhX3SuztbPr7LUjROmmwLBVHr9k06LMVjSM4B5XFk3uGV+5IrTfpRkBLH7UB7vh 9mA21Zu/tGjUNPZBbHJIqXHhHMFTS4ewUznEwr4vT87xVkcG2yJ385IF/6Q22a1u n6hWuLPcWwABROIXRhZ/wDafEKnchUGiAICiGpAjd6Ngrc3gzvsOGPjcIdFS9sO8 SWO1W+AJQi6HlcnMrmlmlRJL/pBkQbOvV97/VozOKmwdP7a6LZ+OcRkpyy4HrV2C 5KBvYrl66G/G6WaWF9juRbjSvQLhpJ6CkSJ0vwfttCfI2oTmAGo/+d/L1V6Pdmv5 RYWoON6wyHTOTmvmewEcjHGzTKgae+u4BcbzZND1vpaoN4Wo5eXWQ5NkAUzK1INY NIz4kORhnHsGOfy8SCKV7WO6JQHFzFc7hZMZ8y0VkfozVK1N0IJRxPblWynI/wo6 xy3WtCWvAmCmDL0fm0SdVC3K85hJFD2kbPQWoqyKPq700PjE4/WJyL4/0Eu2cYa5 m9rB/vM5Cdkrv9LEJtZjQ7Ro0flV21P+rr2iZXVSXPVbzuj4K4oRGihcXwD9E/B7 +o+v/Ckzamfi1fpawnDk =ICV8 -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/6/13 8:36 AM, Perry E. Metzger wrote: One solution, preventing passive attacks, is for major browsers and websites to switch to using PFS ciphersuites (i.e. those based on ephemeral Diffie-Hellmann key exchange). It occurred to me yesterday that this seems like something all major service providers should be doing. I'm sure that some voices will say additional delay harms user experience. Such voices should be ruthlessly ignored. +1 In practice, how do we make that happen? On the XMPP network we're pushing to make sure that all client-to-server and server-to-server hops are encrypted (yes, I know, per-hop encryption is not enough, we need end-to-end encryption too). Is there a handy list of PFS-friendly ciphersuites that I can communicate to XMPP developers and admins so they can start upgrading their software and deployments? Thanks! Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSKgDaAAoJEOoGpJErxa2pMssQAKVjwZZqy0q2ogIk13rGZkym 8PnXm6H9qsw08q4w3NEXPOU41rEh/GpS4agcgVxA+huYo5hU+qeA8YuhrVXt2xS7 Jt/fUgpJup297W4ErUpzMDQegVfP8ckNizI2AXBfr631PKUs7U3ije6wdxK30Hyx 262V/SLP0uVnJpbmepWUMCfzTGMY0SAvq2blVAPJjqjulC6lshj/aiKP6RBi9hCF CW8yWO4L7Uot1mAa7j87Ywlyg9V8j6nKNEsKu81rjhSLpGvmed0GncK7U3GxLmsM z2VzZKRJ+NxwJ3MKicmEy2bNnPjSJUd8itUWKru2vYMZftGImljWv1cUsLjXkxI7 DvQQ0lrjl3W8tisN7aqmGPi2734j8AN6ilHAUCbWniJfaarfC6rU/fDuk6fGnFss N/zq9+NhYdvegmJiLvwVm42d1XdCxgoKzb27g/d8CsUWqWWXtQhxTeLL+OcKXiqh kXLDDTv9uqBgdqWDZ/uhhlFGd/PFfeakeW7QWDjAvRMyF3XWaHA+OBJpg+nE/Dsl kSfLmiCzOj4FN8aPQoM39T9IHbASpp+KYgnCl0nDweYXXBH/v5B/bCwsqz5Sy0ut SET7zglbKm6oVf9hWoXsv01Kqsrxw6xj2bdnMU6YSUQoDvDHdXlilRZ6dTP5G63v 8XfdEe3k0aa+7uPpWQ5t =SiIp -END PGP SIGNATURE- ___ 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é fah...@gmail.com 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] Email and IM are ideal candidates for mix networks
On 8/27/13 7:48 PM, Perry E. Metzger wrote: On Tue, 27 Aug 2013 22:04:22 +0100 Wendy M. Grossman wen...@pelicancrossing.net wrote: On 08/27/2013 18:34, ianG wrote: Why do we need the 1980s assumption of being able to send freely to everyone, anyway? It's clear you're not a journalist or working in any other profession where you actually need to be able to communicate spontaneously with strangers. Of course, as a reporter, you are probably getting email addresses of people to talk to via referral, and that could be used to get past the barrier. And that's how friend-of-friend stuff is happening now (LinkedIn and the like). In a way the old-fashioned letter of introduction had a lot to recommend it. :-) Peter -- Peter Saint-Andre https://stpeter.im/ ___ 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 8/27/13 7:45 PM, Perry E. Metzger wrote: On Tue, 27 Aug 2013 21:33:01 + radi...@gmail.com wrote: Iang wrote: Why do we need the 1980s assumption of being able to send freely to everyone, anyway? tech.supp...@i.bought.your.busted.thing.com is one that comes to mind. i...@sale.me.your.thing.com is another. I think the types of prior whitelist only secure systems being discussed on-list here lately will in the long run win out with the lions share of messages, but that bog standard 'dirty' email will persist for commercial interactions of the type I list above. On the other hand, tech.support@sillycompany could just accept all contact requests, at least temporarily. Realistically they all have a web-based contact form these days anyway. Similarly, they all have live web-based chat systems that don't require opening up more broadly. HTTP is the new TCP and all that. For truly federated communication (BigRetailer wants its employees to exchange messages with smaller companies in its supply chain), a more open technology is needed, but we have those for email and IM. However, we're off-topic for what's truly important here: not enterprise email and IM, but secure technologies for individuals. Peter -- Peter Saint-Andre https://stpeter.im/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
On 8/27/13 7:47 PM, Jonathan Thornburg wrote: On Tue, 27 Aug 2013, Perry E. Metzger wrote: Say that you want to distribute a database table consisting of human readable IDs, cryptographic keys and network endpoints for some reason. Say you want it to scale to hundreds of millions of users. This sounds remarkably like a description of DNSSEC. Assuming it were widely deployed, would DNSSEC-for-key-distribution be a reasonable way to store email_address -- public_key mappings? You mean something like this (email address -- OTR key)? https://datatracker.ietf.org/doc/draft-wouters-dane-otrfp/ Peter -- Peter Saint-Andre https://stpeter.im/ ___ 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 8/26/13 8:14 AM, Perry E. Metzger wrote: there is a good reason that I proposed that in the long run, whitelist only systems like Jabber and Facebook messaging are a better model. As one of those Jabber guys, I agree. :-) Perry, thanks for starting some very interesting threads here -- I'll post more soon. Peter -- Peter Saint-Andre https://stpeter.im/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: X.509 certificate overview + status
Travis wrote: Recently I set up certificates for my server's SSL, SMTP, IMAP, XMPP, and OpenVPN services. Actually, I created my own CA for some of the certificates, and in other cases I used self-signed. plug BTW, we give away free certificates for XMPP services here: http://xmpp.org/ca/ The root CA is StartCom, which is accepted in Mozilla, OS X, and various other cert stores. I've noticed that these certs are becoming quite popular on the XMPP network (plus, they result none of those cert warnings that scare of normal users). /plug Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: security questions
Stefan Kelm wrote: Wells Fargo is requiring their online banking customers to provide answers to security questions such as these: Does Wells Fargo really use the term security question here? Yes it does. I'm a Wells Fargo customer and I had to set my security questions yesterday in order to keep using their online banking system. The resulting email notification said in part: Thank you for taking the time to set up your security questions. If we ever need to confirm your identity, your ability to give the correct answers to these questions will help us verify it's you. /psa smime.p7s Description: S/MIME Cryptographic Signature
security questions
Wells Fargo is requiring their online banking customers to provide answers to security questions such as these: *** What is name of the hospital in which your first child was born? What is your mother's birthday? (MMDD) What is the first name of your first roommate in college? What is the name of the first street you lived on as a child? What year did you start junior high/middle school? () What is your oldest sibling's nickname? What is your dream occupation? What is your spouse's nickname? In what city was your father born? What is the name of the high school you attended? What is your best friend's first name? What is the name of the junior high/middle school you attended? What is the first name of your maternal grandfather (mother's father)? What is the name of your favorite childhood superhero? In what city did you meet your spouse? In what city did your parents meet? In what city did you attend high school? What is name of the hospital in which you were born? What is the last name of your favorite teacher? In what city was your maternal grandmother (mother's mother) born? What was your most memorable gift as a child? *** It strikes me that the answers to many of these questions might be public information or subject to social engineering attacks... Peter smime.p7s Description: S/MIME Cryptographic Signature
Re: security questions
Chris Kuethe wrote: On Wed, Aug 6, 2008 at 8:23 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Wells Fargo is requiring their online banking customers to provide answers to security questions such as these: *** ... *** It strikes me that the answers to many of these questions might be public information or subject to social engineering attacks... Lie. I don't actually give the real answers to those questions for just that reason. Make up some plausible and memorable words (maybe using a tool like yould), and pick your mother a new random name from the phone book. Oh, I know we're smart enough to do that, but I doubt that your typical Facebook user will realize that their high school and best friend's first name (etc.) are public information. Peter smime.p7s Description: S/MIME Cryptographic Signature
Re: Strength in Complexity?
[EMAIL PROTECTED] wrote: With the caveat that I am reading mail in reverse order (i.e., panic-mode), I do have to say one thing and it isn't even to mount a stirring defense of Kerberos, which does not need defending anyhow... The design space for practical network security has always been: I'm OK You're OK The Internet is a problem A gathering storm of compromised machines, now variously estimated in the 30-70% range depending on with whom you are talking, means that the situation is now: I'm OK, I think I have to assume that you are 0wned The Internet might make this worse Put differently, network security has now come close to Spaf's famous line about netsec in the absence of host security being assured delivery of gold bars from a guy living in a cardboard box to a guy sleeping on a park bench. BTW the original quote seems to be: Secure web servers are the equivalent of heavy armored cars. The problem is, they are being used to transfer rolls of coins and checks written in crayon by people on park benches to merchants doing business in cardboard boxes from beneath highway bridges. Further, the roads are subject to random detours, anyone with a screwdriver can control the traffic lights, and there are no police. -- http://homes.cerias.purdue.edu/~spaf/quotes.html /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: SSL certificates for SMTP
Paul Hoffman wrote: At 6:34 PM +0200 5/23/07, Florian Weimer wrote: But no one is issuing certificates which are suitable for use with SMTP (in the sense that the CA provides a security benefit). No one? I thought that VeriSign and others did, at least a few years ago. FWIW, last year we established a dedicated Intermediate Certification Authority for issuing digital certificates to admins of XMPP servers: https://www.xmpp.net/ Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: Failure of PKI in messaging
Leichter, Jerry wrote: On the other hand, the push/pull combination of spam and IM/SMS are well on their way to killing Internet mail. Video killed the radio star? I'm an IM partisan, but even I have given up on trying to kill off email. Meanwhile, the next generation of users is growing up on the immediacy of IM and text messaging. Mail is ... so 20th century. I prefer the phrase second-millennium. :-) I think the whole notion of decentralizing *everything* has turned out to be a trap. Interestingly, the public communication systems that are secure (Hushmail, Skype, etc.) are all centralized. I can't claim that a decentralized approach like Jabber is secure, though we're working on it... Trust has *always* been based on personal contact, extended to organizations that work hard to have a human face on the one hand, and to various human-scale, humanly-transparent ways of reifying and rendering portable the smile and the handshake, from letters of credit to various business rating organizations (DB, BBB), and so on. Replacing that with some abstract cryptographic system that no one understands, no one can see or touch - and that ultimately can only be perceived as trustworthy if it comes from trustworthy institutions anyway - is just a non-starter. Can't agree more. (Not that agreement is the sine qua non of discussion.) With this shaky base, it should perhaps not come as a surprise that after all these years of trying, we haven't managed to come up with human interfaces to these systems that actually allow them to work effectively in the human world. So how do we abstract from or extend what (somewhat) works in the real world to something that might work in the online world? Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: SSL Cert Prices Notes
John Gilmore wrote: Date: Sun, 6 Aug 2006 23:37:30 -0700 (PDT) From: [EMAIL PROTECTED] Subject: SSL Cert Notes Howdy Hackers, Here is the latest quick update on SSL Certs. It's interesting that generally prices have risen. Though ev1servers are still the best commercial deal out there. The good news is that CAcert seems to be posistioned for prime time debut, Based on my experience with CAcert, that statement strikes me as a bit optimistic. And yes, I am a CAcert assurer (currently ranked #151) and I follow all the mailing list discussions etc. But AFAICS, prime time is a ways off for CAcert. and you can't beat *Free*. :-) SSL Certificate Authorities VerificationSubdomains Too Low HighLow High Verisign$399$995 Geotrust$189$349$599$1499 Thawte $149$199$799$1349 Comodo / instantssl $49 $62.50 $449.95 godaddy.com $17.99 $74.95 $179.99 $269.99 freessl.com $69 $99 $199$349 ev1servers $14.95 $49 CAcert FreeFreeFreeFree Have you looked at StartCom? https://cert.startcom.org/ Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: NPR : E-Mail Encryption Rare in Everyday Use
Ian G wrote: Chris Palmer wrote: Peter Saint-Andre writes: http://www.saint-andre.com/blog/2006-02.html#2006-02-27T22:13 3. I see on your site you use and advertise for CACert. I hope CACert's signing cert(s) are never trusted by my browser, because then my browser would trust any cheap-ass random pseudonym in the world. IMHO trust is something you do, not something your browser does. Unless you're going to delegate trust to the browser manufacturers... Which brings us to my next point... You are probably talking about the Class 1 root that CAcert uses to issue pseudonymous certs. Yes, they can be acquired by any cheap-ass psuedonym (but not randomly, as I think there is a serial number in there which I was told was an unavoidable artifact of x.509). Over on Peter's blog it seems to indicate he is an Assurer ... assuming that is correct [it isn't a cryptographically sound image :) ] then this means he is at least assured which is their term for his identity having been verified. In CAcert, assurance is an action. You show me two government-issued photo IDs (GIPIDs) and I compare them with your visage and physical person; if I think they match, I assure you for some number of points in the web of trust. If you get to a certain number of points, you can use the Class 3 root. If you get even more points, you can become an assurer (someone who does assurances). I happened to use the trusted third party process for assurance (get copies of my GIPIDs witnessed and notarized by two persons who are legally authorized in my jurisdiction to witness and notarize documents), which results in more points initially and the ability to become an assurer more quickly. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: NPR : E-Mail Encryption Rare in Everyday Use
Victor Duchovni wrote: On Wed, Mar 01, 2006 at 06:15:36PM +0100, Ian G wrote: Email is hard to get encrypted, but it didn't stop Skype from doing encryped IMs easily. Likewise I have secured email communications with my wife via a single key exchange, so what? Skype has not easily created an interoperable federated system that secures all IM communications end-to-end, and many of the issues in doing that are non-technical. Right. Nor did email create a single federated system that crosses across to mobile phones. There is always a boundary where a system stops. Federated accross millions of account issuing organizations, not technologies, and email did do that, and IM did not. IM is like email from a choice MCI, Sprint or ATT, sure they can control the medium better, but this is a temporary state of affairs... Monolithic consumer IM services (AIM, MSN, Yahoo, etc. are like that. Existing federated IM standards (e.g., Jabber/XMPP) are not. The point is that the non-technical issues we are looking at here are *better* handled at the level of competitive systems, because they have incentives to solve them, whereas technical committees writing RFCs do not. These are closed systems that compete with each other, once they become federated, they can no longer compete on end-to-end security, because that is a property of the interoperability framework, not the individual product. Also with millions of account issuers, the abuse and identity problems become just as bad as for email. The problem is intrinsic, is not the result of lazy RFC writers. Well, in the Jabber/XMPP world we require authentication, servers must stamp the from addresses, and we use (at a minimum) reverse DNS lookups to verify server identities (or use certs with TLS + SASL-EXTERNAL if you want true server-to-server authentication). So I'd say the abuse and identity problems are not as bad in IM (at least the IM technology I'm familiar with) as in email. But you'd hope that we've learned a thing or two since email was invented. ;-) Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: NPR : E-Mail Encryption Rare in Everyday Use
Anton Stiglic wrote: More strongly, if we've never met, and you are not in the habit of routinely signing email, thereby tying a key to your e-persona, it makes no sense to speak of *secure* communication to *you*. Regularly signing email is not necessarily a good idea. I like to be able to repudiate most emails I send... As previously mentioned, anonymity and repudiability aren't high on my list of values -- not that anyone cares about my hierarchy of values ;-) But as promised I did blog about it: http://www.saint-andre.com/blog/2006-02.html#2006-02-27T22:13 Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: NPR : E-Mail Encryption Rare in Everyday Use
Victor Duchovni wrote: On Wed, Mar 08, 2006 at 12:53:16PM -0700, Peter Saint-Andre wrote: These are closed systems that compete with each other, once they become federated, they can no longer compete on end-to-end security, because that is a property of the interoperability framework, not the individual product. Also with millions of account issuers, the abuse and identity problems become just as bad as for email. The problem is intrinsic, is not the result of lazy RFC writers. Well, in the Jabber/XMPP world we require authentication, servers must stamp the from addresses, and we use (at a minimum) reverse DNS lookups to verify server identities (or use certs with TLS + SASL-EXTERNAL if you want true server-to-server authentication). So I'd say the abuse and identity problems are not as bad in IM (at least the IM technology I'm familiar with) as in email. But you'd hope that we've learned a thing or two since email was invented. ;-) What is the value of such authentication? Which organizations will you trust? For example, most mail that passes SPF is spam... Authentication by the issuing organization is only useful, if you can keep bad issuers of the net... If federated Jabber becomes universal, the bad guys cannot be excised from the network. The botnets cannot be excised from the network, ... The problem is technology neutral. Loosely along the lines of Goedel's incompleteness theorem, any universally deployed federated communications medium will exhibit spam. I never made the strong claim that the federated Jabber network is or always will remain spam free, only the weaker claim that its abuse and identity problems are and will remain less serious than those of the federated email network as it exists today. There is no magic bullet, and a spam-free utopia is not an option if federated communications are desired. I do not dispute that if Jabber becomes popular enough, there will be rogue servers that don't enforce local authentication (although with server dialback and TLS they can't fake from addresses at other domains, see RFC 3920), and that those who deploy Jabber services will need to blacklist those domains. I do not dispute that there will be spam bots and that server admins or end users will need to block communication with those bots (e.g., using the privacy list protocol defined in RFC 3921). I do not dispute that there will be phishing attacks (e.g., using internationalized addresses that look like but are not identical to familiar addresses) and that client software will need to take appropriate measures to differentiate between legitimate and mimicked addresses (e.g., using petname systems as described in JEP-0165). All I'm saying is that we have a lot of the infrastructure in place (and are building more) to make abuse harder and identity stronger than it is on the existing email network. Is Jabber perfect? No. We're just trying to make it good enough that the bad guys will go elsewhere (which, so far, they have). Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: NPR : E-Mail Encryption Rare in Everyday Use
bear wrote: On Fri, 24 Feb 2006, Peter Saint-Andre wrote: Personally I doubt that anything other than a small percentage of email will ever be signed, let alone encrypted (heck, most people on this list don't even sign their mail). I don't think I've said anything here that I will later want to be able to prove incontrovertibly was said by me. In general, signing your mail has a downside in this age of litigous potential mail recipients, and except when your mail regards the disposition of assets, no upside. In the long run, I think the population of people who want to sign their mail is about the same as the population of people who want to post on usenet with their real name and put their street address and phone number at the bottom of every post. Why give the anonymous cowards who are collecting information with robotic trawlers, whether for spam lists or any other reason, proof of exactly who you are? The short answer to your unstated question is: anonymity is not high in my scale of values. The long answer will require some reflection on my part, which I won't post here but at my blog when I have the time. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: Another entry in the internet security hall of shame....
Adam Back wrote: Thats broken, just like the WAP GAP ... for security you want end2end security, not a secure channel to an UTP (untrusted third party)! Well, in the Jabber/XMPP world you can run your own server (just as you can in the email world). I see no harm in e2m channel encryption in that (or any other) case if you've got a client-server architecture. Granted, e2e security is also desirable. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: Another entry in the internet security hall of shame....
Alaric Dailey wrote: I am aware of Jabbers support for GPG/PGP, but did I miss their support for user certificates? I have seen no indication of such support, what client supports it? RFC 3923. But no clients support that yet to my knowledge. Peter smime.p7s Description: S/MIME Cryptographic Signature
Re: Another entry in the internet security hall of shame....
Enzo Michelangeli wrote: Remember that Jabber and similar protocols also trust servers to some extent. Servers store and distribute valuable information like presence data -- it is architecturally hard to do otherwise. Well, not really: the buddies on the list can be located through a Distributed Hash Table such as Kademlia, and, once their IP addresses are known, their presence can be checked by ping/pong exchange of UDP packets every few seconds. The biggest problem is represented by NATs, but there are techniques that can alleviate it (hole punching or, in stubborn cases, relaying through non-NATted nodes). We don't expose IP addresses in XMPP, instead we use logical addresses managed by servers. That's a different approach from what you've described, but of course you're free to build an alternative presence and messaging protocol and network if you'd like. :-) I agree that you *also* want end to end, such as pgp over Jabber provides. I really wish Gaim supported the pgp over Jabber stuff the way PSI does... Why not get OTR then? http://www.cypherpunks.ca/otr/ OTR encrypts only the message text, but XMPP can be used to send all sorts of interesting XML traffic (such as SOAP, XML-RPC, etc.) in addition to simple IM. So we want to encrypt more than what in XMPP is the XML character data of the body/ child of the top-level message stanza. RFC 3923 enables XMPP implementations to encrypt the entire XML stanza, but no one has implemented that yet and it doesn't support perfect forward security etc. Another possible approach being discussed is here: http://www.jabber.org/jeps/jep-0116.html Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: e2e all the way (Re: Another entry in the internet security hall of shame....)
Adam Back wrote: Well I think security in IM, as in all comms security, means security such that only my intended recipients can read the traffic. (aka e2e security). I don't think the fact that you personally don't care about the confidentiality of your IM messages should argue for not doing it. Fair enough you don't need it personally but it is still the correct security model. Some people and businesses do need e2e security. (It wasn't quite clear, you mention you advised jabber; if you advised jabber to skip e2e security because its too hard... bad call I'd say). No one advised any such thing, and e2e was a requirement addressed within the IETF by the XMPP WG, resulting in RFC 3923. Peter smime.p7s Description: S/MIME Cryptographic Signature
Re: Another entry in the internet security hall of shame....
Trei, Peter wrote: Ironically, Peter's message above kicked off warning dialogs from MS Outlook, since it was signed using a keypair signed with Peter's own self-signed root, which was not in MSO's list of trusted roots. You may trust CAcert's root more or less than a root that is trusted by Microsoft. Personally, I find CAcert to be an interesting experiment in webs of trust. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: Another entry in the internet security hall of shame....
Tim Dierks wrote: [resending due to e-mail address / cryptography list membership issue] On 8/24/05, Ian G [EMAIL PROTECTED] wrote: Once you've configured iChat to connect to the Google Talk service, you may receive a warning message that states your username and password will be transferred insecurely. This error message is incorrect; your username and password will be safely transferred. iChat pops up the warning dialog whenever the password is sent to the server, rather than used in a hash-based authentication protocol. However, it warns even if the password is transmitted over an authenticated SSL connection. I'll leave it to you to decide if this is: - an iChat bug - a Google security problem - in need of better documentation - all of the above - none of the above It seems Google is assuming that SASL PLAIN is acceptable once you've completed STARTTLS on port 5222 (or if you've connected via SSL on the old-style port 5223). Decide for yourself if that's secure and whether the iChat warning is justified. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: Cross logins
Rich Salz wrote: Is it possible for two web sites to arrange for cross logins? Check out SAML, esp the browser artifact profile. Check out Passel, which lacks the complexity of SAML: http://www.passel.org/ Peter smime.p7s Description: S/MIME Cryptographic Signature
Re: Encryption plugins for gaim
On Tue, Mar 15, 2005 at 02:14:48PM -0500, Ian Goldberg wrote: OTR works over Jabber today. Granted, it's not very Jabberish (as far as I understand the term; I don't know the Jabber protocol very well): it just replaces the text of the message with ciphertext. [gaim, at least, doesn't seem to have a way to construct a more Jabberish message, as far as I could tell.] I'd be more than happy to help Jabber-ify the OTR protocol. The reason we designed OTR was exactly that the GPG-over-IM solutions have semantics that don't match those of a private conversation: you have long-term encryption keys, as well as digital signatures on messages. You don't *want* Bob to be able to prove to Charlie that Alice said what she did. [Yet you want Bob to be himself assured of Alice's authorship.] And a compromise of Bob's computer tomorrow should not expose today's messages. OTR also adds a couple of extra features (malleable encryption, publishing of the MAC keys, a toolkit for forging transcripts) to help Alice claim that someone's putting words in her mouth. Obviously I need to read up more on OTR, but thanks for the offer of assistance -- I'll reply further when my level of ignorance is not quite so high as it is now. /psa - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
