Re: Another entry in the internet security hall of shame....
Dave Howe [EMAIL PROTECTED] writes: 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. Well, it's still attractive to have channel security in order to prevent hijacking. (Insert usual material about channel bindings here...) -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
instant lottery cards too, Re: reading PINs in secure mailers without opening them
Years ago, I could read instant win lottery cards and still leave them as new by using the laser photoacoustic effect. A low-power chopped laser beam is focused and line-scans the target while a microphone picks up the acoustic waves caused by differential absorption of the laser light as it sweeps the line. By phase-shifting the received acoustic signal versus the chopped light signal (they have the same frequency), you can read at different depths of the target. Adjusting to hearing at the depth of the paper substrate, below the covering ink, all markings could be read as if the covering ink did not exist, line by line. The apparatus could be built today by something like $500, I believe, using parts readily available. Distributors of the instant lottery cards could, without detection, separate the winning cards. Unlike ATM cards, there are no cards that must be stolen at the same time for the attack to be successful. Cheers, Ed Gerck Perry E. Metzger wrote: 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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
e2e security by default (Re: e2e all the way)
OK summing up: I think e2e secure, and secure by default. On Fri, Aug 26, 2005 at 04:17:32PM -0400, Steven M. Bellovin wrote: 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. I think user-to-server security is not secure by in my view the most important comms security metric -- e2e security. So if one engineers for this as the default your system becomes not secure by default. Don't forget that peoples security model can change radically without warning. (end users) typically give no prior thought to security until something goes wrong. At which point they are screwed if the default is secure comm to the UTP. People complain at microsoft for example, if their software is not secure by default. The BSD OS goes to some pains to be secure by default. If you're saying yes it _could_ be e2e secure if users jump through x,y,z hoops (like run your own IM server!) ... well you know that even power users, who do want security, may give up at the inconvenience of that. 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? I draw the line for IM security: - private keys generated on the client - public keys maybe by default certified by central entity - but advanced user has choice to use other ceritfication, including out of band, WoT etc (central entity one can easily automate, which is what skype does) now a-kind of active MITM with rogue CA attack is possible with collusion of the central CA (by issuing a second certficiate for the wire-tapping party), however the advanced user can detect and come away with evidence of this. The fact that the advanced user retains this ability I think adds value for even non-technical users; the CA run risk of ruining their reputation, violating the CPS etc. and of their being evidence. btw I think there is signifciant additional value in _forceing_ the attacker to sniff the traffic *and* do an active MITM with rogue CA attack. With your by default route through UTP, the attacker has a natural and convenient place to subpeona, OS penetrate etc. and undetectably snoop on traffic. 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? I used key roaming in this scenario when I had this problem. (Without giving the central server cleartext private key). 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. I disagree. My metrics for secure IM protocol design are: - private keys are generated on client machine - private keys do not leave client machine in unencrypted form - end2end security where possible - immediate forward secrecy where possible And you can do auth-key roaming in this. (Note for IM security you are better off certifying auth keys and using the auth keys to authenticate EDH; if the user forgets the password etc., you can just issue new auth certs). If you've looked at IM security, there are a number of other interesting challenges in IM security also btw, joining and leaving security, and the fact that comms group can be 2 endpoints. Joining and leaving security argue for backward secure and forward secure re-keying respectively. Adam - 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....)
Steven M. Bellovin wrote: 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? yes, this is the optimisation that makes Skype work, it is (probably) vulnerable to an MITM at the center. This is a tradeoff. What it means is that the center can do an active attack. But it can't do a passive attack (this is speculation but it seems reasonable or at least achievable). That's a good deal for users, when you consider their alternative. Fantastic value for money, really, it's really very hard to criticise... 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, The evidence suggests that if you just slap an SSL tunnel in place, you end up with an ongoing mess of key management - ref - what this thread started with from google. If you do the thing properly, and build it opportunistically, with the option of upgrading to signed certs for those that really want that, you can avoid all that. But few do, for some reason, or maybe those successful cases we just never hear about because they work without fuss... When SSL is your hammer, everything gets nailed as a server. 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. On this I think we'd all agree. Although I'd also add that it should be economic - if it doesn't deploy then it does not good. 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. It's fascinating that you see this and I wish you'd share the threats you see. I see only node threats, you see only wire threats. Why is this? (I can quote reams and reams of news articles that point to merchant data losses and PC malware and virus attacks... but it would be boring. Just ask Lynn for his feed ...) My view of the p2p threat model: other party - 70% own node- 20% center - 10% To an accuracy of +/- X%. Obviously, the wire threats - that are protected by Jabber's SSL and the like - are in the noise somewhere there (but I expect them to get much more aggressive in the future). Another way of looking at this is to ask what the damage is. If your chat traffic is breached by some random threatening outsider, what does he gain? Nothing, so it doesn't take a PhD to realise nobody's interested. But if your listener is a *related* other party and has your messages, then that's a whole other story... This is why for example the most popular IM security system is the discarded nym. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Steven M. Bellovin wrote: 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.) *That* makes much more sense, ignore my earlier email. http://homes.cerias.purdue.edu/~spaf/quotes.html 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. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
