Re: Another entry in the internet security hall of shame....
Eric Rescorla wrote: Most chat protocols (and Jabber in particular) are server-oriented protocols. So, the SSL certificate in question isn't that of your buddy but rather of your Jabber server. Adam Back [EMAIL PROTECTED] writes: Thats broken, just like the WAP GAP ... for security you want end2end security, not a secure channel to an UTP (untrusted third party)! 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. That means that you also want to be sure you're talking to the right server (and that the server wants to be sure it is talking to an authenticated client). 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... Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Think end-to-end.. Even jabber has a way to encrypt messages end-to-end using user certificates (or PGP). -derek 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? Alaric smime.p7s Description: S/MIME Cryptographic Signature
Re: Another entry in the internet security hall of shame....
John Kelsey [EMAIL PROTECTED] writes: Recently, Earthlink's webmail server certificate started showing up as expired. (It obviously expired a long time ago; I suspect someone must have screwed up in changing keys over or something, because the problem wasn't happening up until recently.) This is now the third time in the last few months in which invalid/expired SSL server certs have totally failed to have any effect, at least until a security person noticed that there was a problem. Maybe one of the HCI people reading the list could be persuaded to investigate whether SSL server certs have any real security value and/or what changes to the UI need to be made to make them useful. Alternatively, how long can you get away with a $19.95 cert from Honest Joe's Used Cars and Certificates that expired several years ago? Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
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....
- Original Message - From: Perry E. Metzger [EMAIL PROTECTED] To: Adam Back [EMAIL PROTECTED] Cc: Peter Saint-Andre [EMAIL PROTECTED]; cryptography@metzdowd.com Sent: Friday, August 26, 2005 8:55 PM Subject: Re: Another entry in the internet security hall of shame [...] 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). 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/ Enzo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
In message [EMAIL PROTECTED], Adam Back writes: Thats broken, just like the WAP GAP ... for security you want end2end security, not a secure channel to an UTP (untrusted third party)! What is security? What are you trying to protect, and against whom? I use Jabber extensively, and I utterly rely on the SSL encryption to the server. I sometimes use end-to-end GPG encryption, but only when I need to discuss something very private. In general, I don't bother, because of my threat model. The biggest threat I face, in many situations, is people eavesdropping on my wireless link, or playing ARP-spoofing games on my wired link. SSL to the server combats that nicely. (I run psi, because it's the only open-source client I've found that actually checks the server's certificate against a pre-configured list. I have no idea what the default list is, since I just replace it with my own...) I'm not particularly worried about the server end. I and most of my Jabber correspondents use one of about four different Jabber servers. I run one myself; the other three are also very tightly administered. Sure, there could be a problem with any of them; given how bad typical endpoints are today, I'd guess that the servers are actually safer. I'm not even slightly worried about eavesdropping on the backbone. I assume NSA can do that if they really want to. But I *know* that it's hard enough that they're not going to waste their time without a reason, and I doubt if my IM conversations are high enough on their list. (They're pretty boring, as a rule...) I'm much more worried about implementation bugs. A previous version of psi had the bad habit of silently falling back to unencrypted mode if it couldn't find the local crypto library, and due to some glitches in my environment this could happen fairly easily. I was forced to resort to firewalling the unencrypted port on my machines... (The implementation has since been changed to make that failure much less likely.) If you don't trust your (or your correspondents') IM servers, it may be a different situation. I haven't read Google's privacy policies for IM; if it's anything like gmail, they're using automated tools that look at your messages and add to your behavioral profile. As Peter said, though, you can always run your own server or find one that you do trust. The protocol itself is quite nice, and was designed with due attention to privacy. (Aside: the Jabber RFCs were some of the best I dealt with while I was Security AD. They were remarkably easy to read, given their length and the complexity of the protocol.) Do I support e2e crypto? Of course I do! But the cost -- not the computational cost; the management cost -- is quite high; you need to get authentic public keys for all of your correspondents. That's beyond the ability of most people. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Federal Information Assurance Conference 2005, Oct 25-26
Federal Information Assurance Conference 2005, Oct 25-26, Univ. of Maryland http://www.fbcinc.com/fiac/ agenda http://www.fbcinc.com/fiac/agenda_full.asp and one of the sessions from above: Session Highlight: A5 - NIST and IBM Discuss Draft Publication SP 800-53A - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fwd: Tor security advisory: DH handshake flaw
Some info on primality testing. Miller-Rabin probabilistic primality tests work really well when you are searching for a prime and picking candidates from a uniform random distribution, also works well if you pick an initial candidate from a uniform random distribution and then increment on that initial candidate, until you find a probable prime. See the references Damgard, Landrock and Pomerance (1993), Average case error estimates for the strong probable prime test, Mathematics of Computation 61 (203). Brandt, Damgard (1993) On generation of probable primes by incremental search. CRYPTO 92. Summaries of the results can be found in the Handbook of applied Cryptography. On a side note about Miller-Rabin, there is something allot of people get wrong. The basic results we know is that one iteration of the Miller-Rabin test will err in declaring a composite integer to be prime with probability less than 1/4, while t iterations will err with probability (1/4)^t. You can find a proof for this is textbooks such as that of Koblitz. If X stands for n is composite, and Y_t stands for RepeatRabin(n, t) returned prime, where RepeatRabin is the algorithm that executes t iterations of Miller-Rabin's test and outputs composite as soon as an iteration fails, prime if all iterations passed. Now, given the basic theorem mentioned above, all we can say is that Prob[Y_t | X ] = (1/4)^t, in English if n is composite, then RepeatRabin(n,t) will return prime with probability less than or equal to (1/4)^t. Much more interesting is to figure out Prob[X | Y_t], that is if RepeatRabin(n,t) returns prime, what is the probability that X is actually composite and we got screwed?. It just happens to be that Prob[X | Y_t] = (1/4)^t when n is chosen from a uniform random distribution, because in such cases prob[Y_1 | X] is actually much smaller than ¼. See Beauchemin, Brassard, Crépeau, Goutier, Pomerance. The generation of random numbers that are probably prime, Journal of Cryptology, 1, 53-64. Ok, back to the main topic. So Miller-Rabin is good for testing random candidates, but it is easy to maliciously construct an n that passes several rounds of Miller-Rabin. The Miller-Rabin probabilistic primality test actually comes from a true primality test, called Miller test, which is polynomial (but not efficient in practice) and works assuming the Extended Riemann Hypothesis. On proposed algorithm is to use two iterations of the Miller-Rabin test followed by a single iteration of the Lucas probable prime test. The advantage of this test is that there is yet no known composite integer that passes even a single Miller-Rabin test to the base 2 followed by a single Lucas probable prime test. There is also an open challenge regarding this (something like 640$ coming directly from the pockets of Pomerance and al.). See Pomerance (1984) Are There Counter-Examples to the Baillie-PSW Primality Test? This is the algorithm mentioned by Hal. No, there is no proof that you cant find a counter-example, but Pomerance hasnt found one yet, and thats good enough for me for the time being! If you want primality certificates, and not just a randomized test that has some probability of given you a wrong answer, look at Elliptic curve primality test and Maurers algorithm. These are both described in the ISO 18032 prime number generation standard and ANSI X9.80 (this just goes to show that these are not purely academic creations, but stuff you can use in practice). Elliptic Curves for Primality Proving (ECPP) is used like Miller-Rabin in order to generate a prime: chose random candidates until one passes the test; but in addition it produces a certificate that allows you to verify primality using a different algorithm (much less complicated than the one used to generate a prime, so this allows you to validate the correctness of the implementation of the prime generating algorithm as well). See Atkin, Morain (1993). Elliptic curves and primality proving. Mathematics of Computations. Maurers method doesnt pick and test random candidates, rather it constructs, in a special way, an integer that is guaranteed to be prime. Dont be concerned about secrecy of prime generated with Maurers method, the method generates primes that are almost uniformly distributed over the set of all numbers (this is different from another algorithm called Shawe-Taylor, which is similar in functioning but only reaches 10% of all primes of a specified set). Maurers method is much easier to code than ECPP. See Maurer (1995) Fast generation of prime numbers and secure public-key cryptographic parameters. Journal of Cryptology, 8(3), 123-155 Maurer. Fast generation of secure RSA-moduli with almost maximal diversity. EUROCRYPT'89. So, in conclusion, there is allot of good stuff to choose from! --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe
e2e all the way (Re: Another entry in the internet security hall of shame....)
On Fri, Aug 26, 2005 at 11:41:42AM -0400, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Adam Back writes: Thats broken, just like the WAP GAP ... for security you want end2end security, not a secure channel to an UTP (untrusted third party)! What is security? What are you trying to protect, and against whom? 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). Do I support e2e crypto? Of course I do! But the cost -- not the computational cost; the management cost -- is quite high; you need to get authentic public keys for all of your correspondents. That's beyond the ability of most people. I don't think it is that hard to do e2e security. Skype does it. Fully transparently. Another option: I would prefer ssh style cached keys and warnings if keys later change (opportunistic encryption) to a secure channel to the UTP (MITM as part of the protocol!). Ssh-style is definitely not hard. I mean nothing is easier no doubt than slapping an SSL tunnel over the server mediated IM protocol, but if the security experts are arguing for the easy way out, what hope is there. I'm more used to having to argue with application functionality focussed people that they need to do it properly -- not with crypto people. I do think we have a duty in the crypto community to be advocates for truly secure systems. We are building piecemeal the defacto privacy landscape of the future; as everything moves to the internet. Take another example... the dismal state of VOIP security. I saw similar arguments on the p2p-hackers list a few days ago about security of p2p voip: who cares about voice privacy etc. Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
periodically, some of the PKI related comments remind me of some stories about power production from the 70s. some of the '70s energy stories focused on the different quality of support for power generation technologies based on whether they were institutional centric (and would be able to charge for delivery) vis-a-vis individual oriented generation technologies (even when they involved identical/same/similar solar, wind, etc energy sources). one of the issues from the energy stories of the 70s was that institutional centric solutions frequently collected a lot more backing because proponents were willing to put the effort into the activity in anticipation of revenue flows. however, there are sometimes significant differences between the PKI institutional centric operations and institutional power generation operations. The power being generated (and delivered) tends to be relatively standard and individuals may view it a reasonable trade-off to have it supported by large institution rather than being responsible for their own power generation installations. There tends to be a much larger variation in the types of things which PKI relying-parties are interested in haved certified by some PKI certification authority (somewhat different from bland uniform power production operation). Furthermore, PKI relying-parties frequently may still operate a significant relationship management infrastructure of their own ... where the information being certified by a trusted 3rd-party certification authority represents a tiny fraction of the information that a production relying party will be keeping. In these situations, once a relying-party has to operate their own relationahip management infrastructure of any significance, then the benefit of any certification added value by a trusted 3rd-party certification authority becomes marginal at best. Once a relying-party is operating any significant relationship management infrastructure of their own, any certification done by some 3rd party certification authority frequently becomes redundant and superfluous. It then follows, if the certification by some 3rd party certification authority becomes redundant and superfluous, the associaed digital certificate (representing that certification operation) then also becomes redundant and superfluous. A trivial example in p2p ... is an individual doesn't necessarily know that the presentation of a John Smith x.509 identity certificate in any way corresponds to a specific John Smith that the relying-party individual is familiar with. They are frequently going to still rely on some locally maintained repository as well as additional out-of-band and/or other communication processes. Once they have done that ... then the incrmeental effort to also include the other individual's public key becomes trivial (at least from a high-level business process and information theory standpoint). This, in turn, renders any added value from a trusted 3rd party certificate authority (and their digital certificaes) marginal at best. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
On 8/26/05, Steven M. Bellovin [EMAIL PROTECTED] wrote: ... If you don't trust your (or your correspondents') IM servers, it may be a different situation. I haven't read Google's privacy policies for IM; if it's anything like gmail, they're using automated tools that look at your messages and add to your behavioral profile. As Peter said, though, you can always run your own server or find one that you do trust. Got a nice little surprise yesterday when I [ge]mailed someone, and moments later gaim beeps at me. Checking gaim, I see that suddenly these users had been added to my gaim/gtalk buddies list without my intervention. Grr Anyway, I wouldn't be the least bit surprised if somewhere down the road a folder called archived gtalk shows up in gmail where you can search through all your old conversations. CK -- GDB has a 'break' feature; why doesn't it have 'fix' too? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
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....
In message [EMAIL PROTECTED], Chris Kuethe writes: On 8/26/05, Steven M. Bellovin [EMAIL PROTECTED] wrote: ... If you don't trust your (or your correspondents') IM servers, it may be a different situation. I haven't read Google's privacy policies for IM; if it's anything like gmail, they're using automated tools that look at your messages and add to your behavioral profile. As Peter said, though, you can always run your own server or find one that you do trust. Got a nice little surprise yesterday when I [ge]mailed someone, and moments later gaim beeps at me. Checking gaim, I see that suddenly these users had been added to my gaim/gtalk buddies list without my intervention. Grr Yup -- documented in the Googletalk pages. Anyway, I wouldn't be the least bit surprised if somewhere down the road a folder called archived gtalk shows up in gmail where you can search through all your old conversations. That wouldn't be a surprise at all -- a number of IM programs, including at least Gabber and Psi, keep local logs. Given Google's core competency of retaining searchable data, one would expect them to do that. But this underscores one of my points: communications security is fine, but the real problem is *information* security, which includes the endpoint. (Insert here Gene Spafford's comment about the Internet, park benches, cardboard shacks, and armored cars.) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: e2e all the way (Re: Another entry in the internet security hall of shame....)
In message [EMAIL PROTECTED], Adam Back writes: On Fri, Aug 26, 2005 at 11:41:42AM -0400, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Adam Back writes: Thats broken, just like the WAP GAP ... for security you want end2end security, not a secure channel to an UTP (untrusted third party)! What is security? What are you trying to protect, and against whom? 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). On the contrary -- I did say that I support and use e2e security. I simply said that user-to-server security solves a lot of many -- most? -- people's security needs. Do I support e2e crypto? Of course I do! But the cost -- not the computational cost; the management cost -- is quite high; you need to get authentic public keys for all of your correspondents. That's beyond the ability of most people. I don't think it is that hard to do e2e security. Skype does it. Fully transparently. Really? You know that the public key you're talking to corresponds to a private key held by the person to whom you're talking? Or is there a MITM at Skype which uses a per-user key of its own? Another option: I would prefer ssh style cached keys and warnings if keys later change (opportunistic encryption) to a secure channel to the UTP (MITM as part of the protocol!). Ssh-style is definitely not hard. I mean nothing is easier no doubt than slapping an SSL tunnel over the server mediated IM protocol, but if the security experts are arguing for the easy way out, what hope is there. I'm more used to having to argue with application functionality focussed people that they need to do it properly -- not with crypto people. I'm not arguing for the easy way out; I'm saying that security is an engineering matter, and that there are tradeoffs, including in the human factors. People who click yes to every download aren't going to understand when to accept a key change notice. Btw, I regularly use 3 different machines when talking to my Jabber server. Is your client going to cache all 3 keys for me? Will all of my correspondents know when to click yes and when not to? My son sometimes uses AIM from public web browsers. What then? I'm sure you're itching to type that my keying material should be on a smart card of some sort, so that I could carry it with me and use the same key from any machine I choose. If so, you'd be 100% right. I'll note that for about 99.99% of people, that's just not feasible; they don't have a smart card and their OS doesn't have an interface that makes it easy to do the right thing. Heck, I don't have a smart card; I don't even know of any smart card readers that talk properly to NetBSD, my OS of choice. Here's the problem for a protocol designer. You want to design a protocol that will work as securely as possible, on a wide range of platforms, over a reasonably long period of time. What do you do? If you engineer only for e2e security, you end up in a serious human factors trap (cue Why Johnny Can't Encrypt and Simson Garfinkel's dissertation). Instead, I recommend engineering for a hybrid scenario -- add easy-to-use client-to-server security, which solves at least 75% of most people's threats (I suspect it's really more like 90-95%), while leaving room in the protocol for e2e security for people who need it and/or can use it, especially as operating environments change. This is precisely what Jabber has done. To sum it up in one sentence: design for the future *and* the present. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Ian G wrote: none of the above. Using SSL is the wrong tool for the job. For the one task mentioned - transmitting the username/password pair to the server - TLS is completely appropriate. However, hash based verification would seem to be more secure, require no encryption overhead on the channel at all, and really connections and crypto should be primarily P2P (and not server relayed) anyhow. It's a chat message - it should be encrypted end to end, using either OpenPGP or something like OTR. And even then, you've only covered about 10% of the threat model - the server. yeah. you have a unencrypted interchange point - the server. There are aspects to that which make it both a good and bad thing, mostly bad. for example you allow interception at the server (may be a requirement for an american based company, but still bad), and you provide a single point of failure for hackers (very bad) Most of the good aspects revolve around only having to support one client cert you can embed in your own client (or make available on your website) and not an entire PKI infrastructure. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
reading PINs in secure mailers without opening them
Often, banks send people PINs for their accounts by printing them on tamper secure mailers. Some folks at Cambridge have discovered that it is easy to read the PINs without opening the seals... http://news.bbc.co.uk/1/hi/technology/4183330.stm -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
