Hello, Rich ... When I drill down on the many pontifications made by computer security and cryptography experts all I find is given wisdom. Maybe the reason that folks roll their own is because as far as they can see that's what everyone does. Roll your own then whip out your dick and start swinging around just like the experts. Perhaps I'm not looking in the right places. I wade through papers from the various academic cryptography groups, I hit the bibliographies regularly, I watch the newgroups, and I follow the patent literature. After you blow the smoke away, there's always an "assume a can opener" assumption. The only thing that really differentiates the experts from the naifs is the amount of smoke. Now I'm certainly not arguing that given wisdom and hard experience have nothing to contribute but they aren't substitutes for either mathematical or even statistical certainty. And I do note in passing that their history of delivering fundamental truth would counsel having a backup plan particularly when it comes to the family jewels. Cheers, Scott -----Original Message----- -----Original Message----- From: Rich Salz [mailto:rsalz@datapower.com] Sent: Fri 5/30/2003 9:26 PM To: Eric Rescorla Cc: Bill Stewart; cypherpunks; cryptography@metzdowd.com Subject: Re: Nullsoft's WASTE communication system > It's utterly baffling to me why people like this choose to design > their own thing rather than just using SSL. Totally agree. At this point in time, if it's a TCP based protocol and it isn't built on SSL/TLS, it should pretty much be treated as snake oil, I'd say. Perhaps some kind of evangelism is needed. /r$ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
"Scott Guthery" <sguthery@mobile-mind.com> writes:
When I drill down on the many pontifications made by computer security and cryptography experts all I find is given wisdom. Maybe the reason that folks roll their own is because as far as they can see that's what everyone does. Roll your own then whip out your dick and start swinging around just like the experts.
Perhaps I'm not looking in the right places. I wade through papers from the various academic cryptography groups, I hit the bibliographies regularly, I watch the newgroups, and I follow the patent literature. After you blow the smoke away, there's always an "assume a can opener" assumption. The only thing that really differentiates the experts from the naifs is the amount of smoke.
Hmm.... I'd characterize the situation a little differently. There are a number of standard building blocks (3DES, AES, RSA, HMAC, SSL, S/MIME, etc.). While none of these building blocks are known to be secure, we know that: (1) They have withstood a lot of concerted attempts to attack them. (2) Prior attempts at building such systems revealed a lot of problems which these building blocks are designed to avoid. (3) People who attempt to design new systems generally make some of the mistakes from (2) and so generally design a system inferior to the standard ones. We're slowly proving the correctness of these building blocks and replacing the weaker ones with others that rely upon tighter proofs (e.g. OAEP for PKCS-1) but it's a long process. However, I don't think it's helpful to design a new system that doesn't have any obvious advantages over one of the standard systems. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
There are a number of standard building blocks (3DES, AES, RSA, HMAC, SSL, S/MIME, etc.). While none of these building blocks are known to be secure ..
So for the well-meaning naif, a literature search should result in "no news is good news." Put more plainly, if you looked up hash and didn't find news of a SHA break, then you should know to use SHA. That assumes you've heard of SHA in the first place. Perhaps a few "best practices" papers are in order. They might help the secure (distributed) computing field a great deal. /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
Rich Salz wrote:
Perhaps a few "best practices" papers are in order. They might help the secure (distributed) computing field a great deal. /r$ --
The new book, Practical Cryptography, by Niels Ferguson and Bruce Schneier is useful. regards, Frederick --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
A lot of the tools and blocks are too hard to understand. "Inaccessible" might be the proper term. This might apply to, for example, SSL, and more so to IPSec. These have a lower survival rate, simply because as developers look at them, their eyes glaze over and they move on. I heard one guy say that "you can read SSH in an hour and understand what's going on, but not SSL." (This was the point raised by the chap who recently wanted to role his own from a pouch of fine cut RSA.) Also, a lot of cryptosystems are put together by committees. SSH was originally put together by one guy. He did the lot. Allegedly, a fairly grotty protocol with a number of weakneses, but it was there and up and running. And SSH-2 is apparantly nice, elegant and easy to understand, now that it has been fixed up. (SSH is the only really successful net crypto system, IMHO, in that it actually went into its market and made a mark. It's the only cryptosystem that is as easy to use as its non-crypto competitor, telnet. It's the only one where people switch and never return.) PGP was also mildly successful, and was done by one guy, PRZ. The vision was very clear. All others had to do was to fix the bugs... Sadly, free versions never quite made the jump into GUI mail clients, so widespread success was denied to it. I'd say that conditions for Internet crypto system success would include: 1. One guy, or one very small, very close team. 2. The whole application is rolled out, ready to use. 3. Crypto is own-rolled, tuned to the application. 4. Concentrate on the application, not the crypto. 5. The application meets a ready need, and 6. The app is easy to use. 7. User doesn't need to ask anyone's permission. These aren't very strong indicators of success, if only because there have been so few fires, for so much smoke. Counterexamples are speakfreely, which was again one lone hacker (John Walker?). Maybe it stalled on latter points. (One doesn't hear much about crypto phones these days. Was this really a need?) My own "interested" protocol (SOX, done by Gary H, not me) trys to meet the above criterion and hasn't succeeded, like all other money protocols. I leave speculation on why success is still just around the corner to others :-) So, I'm with Scott on that. When it comes down to it, there's an awful lot of smoke, and precious little real life crypto success out there. It's no wonder that people roll their own. -- iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
On Monday, June 2, 2003, at 07:09 AM, Ian Grigg wrote:
PGP was also mildly successful, and was done by one guy, PRZ. The vision was very clear. All others had to do was to fix the bugs... Sadly, free versions never quite made the jump into GUI mail clients, so widespread success was denied to it.
I would've characterized PGP version 2, 1992, as the first usable version. And it was done by about half a dozen people. The first version was not, to my knowledge, actually used by anyone. It might have done better had creaping featuritus and the "integration with mailers and other programs" and the "better GUI" distractions not dissipated so much energy. Also, the Clipper chip politics and the belief that PRZ was about to be arrested gave PGP a certain kind of notoriety...it became "cool" ("bad," "def") to use PGP. These days, "that's _so_ 90s." --Tim May
Ian Grigg wrote:
Also, a lot of cryptosystems are put together by committees. SSH was originally put together by one guy. He did the lot. Allegedly, a fairly grotty protocol with a number of weakneses, but it was there and up and running. And SSH-2 is apparantly nice, elegant and easy to understand, now that it has been fixed up.
ssh2 is in essence a re-invention of what SSL did without having to use X.509 keys. This reinvention was, IMHO, largely the result of the limitations of the ssh1 design.
(SSH is the only really successful net crypto system, IMHO, in that it actually went into its market and made a mark. It's the only cryptosystem that is as easy to use as its non-crypto competitor, telnet. It's the only one where people switch and never return.)
I trust that we can agree that the volume of traffic and number of transactions protected by SSL are orders of magnitude higher than those protected by SSH. As is the number of users of SSL. The overwhelming majority of which wouldn't know ssh from telnet. Nor would they know what to do at a shell prompt and therefore have no use for either ssh or telnet. Given that SSL use is orders of magnitude higher than that of SSH, with no change in sight, primarily due to SSL's ease-of-use, I am a bit puzzled by your assertion that ssh, not SSL, is the "only really successful net crypto system". --Lucky
Lucky Green wrote:
Ian Grigg wrote:
Also, a lot of cryptosystems are put together by committees. SSH was originally put together by one guy. He did the lot. Allegedly, a fairly grotty protocol with a number of weakneses, but it was there and up and running. And SSH-2 is apparantly nice, elegant and easy to understand, now that it has been fixed up.
ssh2 is in essence a re-invention of what SSL did without having to use X.509 keys. This reinvention was, IMHO, largely the result of the limitations of the ssh1 design.
OK. Learning more every day :-)
(SSH is the only really successful net crypto system, IMHO, in that it actually went into its market and made a mark. It's the only cryptosystem that is as easy to use as its non-crypto competitor, telnet. It's the only one where people switch and never return.)
I trust that we can agree that the volume of traffic and number of transactions protected by SSL are orders of magnitude higher than those protected by SSH. As is the number of users of SSL. The overwhelming majority of which wouldn't know ssh from telnet. Nor would they know what to do at a shell prompt and therefore have no use for either ssh or telnet.
Indeed! Although I trust that we can also look at many different ways of measuring success. In order to *compare* success, like for like, we have to start with an understanding of the marketplace for each system, and assume that the marketplace for each application is its universe. I (arbitratrily) define the marketplace for SSL as browsing. (I.e., HTTP, as used between a browser and a webserver. The SSL protected part might be referred to as HTTPS. This of course ignores all the other users of the protocol.) There, we can show statistics that indicate that SSL has penetrated to something slightly less than 1% of servers. It would of course be interesting to see what the bandwidth figures are like, for example, but I wouldn't be surprised if they are also less than 1% (think about all those yahoo monsters that overflow your POTS). The fact that a user of SSL is neither aware nor capable of being protected by SSH is irrelevant, neither is a sysadmin concerned in his job with protecting his work with SSL. (Actually that's not true; there was an SSL terminal system for a while, as an adjunct to SSLeay, but that is a dead or dying protocol, rapidly replaced by SSH whenever the two entered competition. Which is a good thing, the SSL terminal was a nightmare to get going, due to its insistance on hand crafting certificates.).
Given that SSL use is orders of magnitude higher than that of SSH, with no change in sight, primarily due to SSL's ease-of-use, I am a bit puzzled by your assertion that ssh, not SSL, is the "only really successful net crypto system".
SSL's 1% penetration into the browsing market doesn't strike me as successful. If I was "selling SSL" as a business, I'd be looking at the other 99% and wondering why it's just sitting there, not being sold. As there are big expensive companies doing just that; then I guess they have tried. Have a look at the penetration reports on http://www.securityspace.com/ On the other hand, SSH, as a cryptosystem, as an application (think: replacement for telnet, not as competitor to the SSL protocol) penetrates its market very well. I have no more than anecdotal evidence for that, but any sysadmin knows that once they started using SSH, they would never go back to the alternate unless forced, kicking and screaming. It would be very interesting to find out what SSH v. telnet traffic looks like. That's what I mean by success. Within its market place, SSH rules. -- iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
At 11:38 AM 06/03/2003 -0400, Ian Grigg wrote:
I (arbitratrily) define the marketplace for SSL as browsing. ... There, we can show statistics that indicate that SSL has penetrated to something slightly less than 1% of servers.
For transmitting credit card numbers on web forms, I'd be surprised if there were 1% of the servers that *don't* use SSL/TLS. Virtually all deployed browsers support SSL, except a few special-purpose versions. The web servers supporting almost all of the web support SSL if they have keys installed. While many of them haven't bothered paying money for certified keys or doing self-signed keys, I'd be surprised if it's really as low as 1%. What's your source for that figure? While only a small fraction of web pages, and a much smaller fraction of web bits transmitted, use SSL, that's appropriate, because most web pages are material the publisher wants the public to see, so eavesdropping isn't particularly part of the threat model, and even integrity protection is seldom a realistic worry. (By contrast, eavesdropping protection and integrity protection are critical to telnet-like applications, so SSH is a big win.) It's nice to have routine web traffic encrypted, so that non-routine traffic doesn't stand out, and so that traffic analysis is much harder, but there is a significant CPU hit from the public-key phase, which affects the number of pages per hour that can be served. Corporate intranet web traffic carried across the public internet sometimes uses SSL, but usually uses IPSEC because that also supports email. In addition to web browsing and email submission, there's an emerging market for SSL-based VPNs appliances. Neoteris is one of the pioneers, and Aventail and some others are players. The intention is that you can get "clientless" (browser-based) support for intranet web browsing and email, and lightweight client support for telnet, while only having to buy an overpriced server box. (And the box doesn't even need crypto accelerator help, because the public-key phase only gets used for login, while most sessions are long enough that this amortizes quickly.)
Bill Stewart wrote:
At 11:38 AM 06/03/2003 -0400, Ian Grigg wrote:
I (arbitratrily) define the marketplace for SSL as browsing. ... There, we can show statistics that indicate that SSL has penetrated to something slightly less than 1% of servers.
For transmitting credit card numbers on web forms, I'd be surprised if there were 1% of the servers that *don't* use SSL/TLS.
I've seen it a lot. Not that I pay much attention, but I'd suspect it is less than 10%, but much more than 1%. Also, a lot of credit card numbers get delivered by email. These are all to small time merchants who have MOTO agreements without the net part, but take the CCs anyway. After all, a sale is a sale, and nobody ever heard of a credit card number being lost over the net... OK, I'm teased by this: how many sites use open unencrypted CC delivery? I went to google and searched on: "<form" credit card number expiry I found 2 on the first page, and 1 on the second page. There were 240,000 hits. So, we are looking at some significant numbers there, I hesitate to say 24,000 as the tail in the google search could be skewed, but, "a lot" seems a fair assessment.
Virtually all deployed browsers support SSL, except a few special-purpose versions. The web servers supporting almost all of the web support SSL if they have keys installed. While many of them haven't bothered paying money for certified keys or doing self-signed keys, I'd be surprised if it's really as low as 1%. What's your source for that figure?
http://www.securityspace.com/s_survey/sdata/200305/index.html Total SSL servers 131,566. Now go to here: http://www.securityspace.com/s_survey/data/200305/domain.html Total webservers 10,432,910 (derived by 5280096 / 0.5061). That gives SSL penetration as 10,432,910 / 131,566 == 1.26% (Darn! I was wrong, it's slightly more than 1%, not less. I should be stoned and cursed!)
While only a small fraction of web pages, and a much smaller fraction of web bits transmitted, use SSL, that's appropriate, because most web pages are material the publisher wants the public to see, so eavesdropping isn't particularly part of the threat model, and even integrity protection is seldom a realistic worry.
Hmmm... You might say that, but I would have said it was the other way around! There is - surprisingly - not much of a threat model for eavesdropping of credit cards (and - shockingly - even less of an MITM threat model). It's easier for a crook to break in and hack the DB, and pick up tens of thousands than to haunt the net looking for an elusive 16 digit number out of a browser page. But, there is a big personal cost with reputational information. Few people would want to see my credit card info, but I can think of lots that would be keen on seeing my adult browsing, my gaming addition, or my participation in my kleptomaniacal therapy group, not to mention anything embarrassing I might get up to! What I find curious is why all those open source people worked so hard to build in the crypto to protect credit cards, but didn't want to protect anything else. I can understand Netscape programmers - they wanted to sell secure servers for cash. But I don't understand why Apache and KDE and Mozilla deliver software tuned to protect credit cards. It would make sense if they were all paid to do this by the credit card companies ... but they aren't, are they? What's their incentive?
(By contrast, eavesdropping protection and integrity protection are critical to telnet-like applications, so SSH is a big win.)
It's nice to have routine web traffic encrypted, so that non-routine traffic doesn't stand out, and so that traffic analysis is much harder, but there is a significant CPU hit from the public-key phase, which affects the number of pages per hour that can be served.
We run a dozen or more web servers here, and I can never tell the difference between the unprotected ones and the protected ones, so I'm not sure what to make of the argument that SSL should be reserved for "important credit card numbers". I think CPU has gotted so cheap that running out of CPU is a great sign of a successful business, no more. The last time I made a serious business decision based on CPU horsepower was back in 1989. We are almost at the point where raw PCs can do 1000 RSAs per second. Companies like Visa and Mastercard process in the order of 1000 - 10,000 transactions per second. Which means if they were using an efficient payment system - one or 2 RSAs per transaction - they could be now thinking about putting their entire crypto processing on one PC. Maybe it's only an issue if one is serving continuously... in which case, maybe one could either "use less crypto" like switch back to smaller keys - way more secure than no keys - or buy a faster box? -- iang
On Tuesday, Jun 3, 2003, at 01:13 US/Eastern, Lucky Green wrote:
Given that SSL use is orders of magnitude higher than that of SSH, with no change in sight, primarily due to SSL's ease-of-use, I am a bit puzzled by your assertion that ssh, not SSL, is the "only really successful net crypto system".
(I noticed that SSL and HTTPS are sometimes used interchangeably in this thread and sometimes not (i.e. STARTTLS). I'll concentrate on HTTPS in this mail. Note that HTTPS is slightly broader than just SSL: it also includes the browser interface.) Absolute numbers are one measure. Another would be to consider the ratio of HTTPS/HTTP and SSH/telnet. You could define a successful protocol by ability to displace its unprotected equivalent. I for one would consider that a more useful measure. I bet you find that HTTPS is non-existent according to this definition, completely disappearing in the noise. Interestingly (and IMHO correctly) enough OpenPGP fails this test too. Miserably. Perhaps that measure is too coarse grained. For instance, in the domain of "security advisories" most emails are digitally signed with OpenPGP. And in the domain of online credit card payments HTTPS has displaced HTTP. But HTTPS covers only those transactions for which users demand protection. Actually, that isn't quite correct. It is those transactions for which the users want to *feel* [2] protected. It is mindbogglingly easy to spoof an HTTPS site. Either with or without the impostor using a certificate. (Today, I can register http://www.e-g0ld.com/ and obtain a matching certificate for $100. All the user will see is a lock icon and he thinks he is safely on http://www.e-gold.com/.) A large part of the problem obviously is the browser's user interface. The other part mainly concerns the use of CA certificates. Self-signed certificates only compound the problem by teaching the user bad habits. ("Oh, if the browser asks a question, just click yes." Guess what: people will now always click "YES" on certificate related questions, whatever the question or warning is.) Penetration? Even privacy-sensitive sites like, say, http://www.cypherpunks.to/ do not utilize HTTPS by default. The possibility of HTTPS access isn't even mentioned on the homepage. No support for RFC 2817 and no transparent redirect either. You have to manually change http: to https: for it to work. Same for http://www.cryptorights.org/. When you manually go to the HTTPS version you will note that they use a self-signed certificate which: a) requires user interaction and a user knowing what she is doing; b) erodes the value of security questions (through teaching bad habits) c) doesn't cache the key so subsequent MITM attacks are not defended against. Another sensitive site? How about HTTPS access to Google ... ? SSH on the other hand succeeded in protecting network infrastructure nearly transparently. It virtually replaced telnet in places where it matters (and a whole lot where it doesn't). I don't have to change addresses or port numbers. Open-source UNIXes have it enabled by default. It completely redefined how X screens are remoted for the (small?) set of users that are interested in that. Of course its protocol isn't perfect and it certainly is vulnerable to the MITM on the first connection. But I bet it offers more real protection than HTTPS, as *presently* implemented, ever will. SSH is the closest thing to opportunistic encryption I know of. I guess this is qualified agreement with Ian's statement that SSH is the "only really successful net crypto system". I can only hope that people will adopt the displacement ratio as a measure of success and design their protocols (all the way up to the user interface) accordingly. Lifting and modifying a quote from Peter Gutmann's homepage: "I think a lot of purists would rather have cryptographic protocols be useless to anyone in any practical terms than to have it made simple enough to use, but potentially "flawed"." -- with apologies to Chris Zimman. -J [1] One exception would be the subset of mail roughly corresponding to security advisories. There OpenPGP signatures are the norm. [2] Airport "security" anyone? -- Jeroen C. van Gelderen - jeroen@vangelderen.org A single glass of beer was passed, from which I was the last one to sip - a ritual signifying that I was not to be poisoned.
At 2:21 PM -0700 6/3/03, Jeroen C. van Gelderen wrote:
Perhaps that measure is too coarse grained. For instance, in the domain of "security advisories" most emails are digitally signed with OpenPGP. And in the domain of online credit card payments HTTPS has displaced HTTP.
I know of one system that takes credit cards over HTTPS, and then sends the credit card number, encrypted with GPG to a backend system for processing. It isn't perfect, but it's better than storing the credit card number on a database accessible to the web server. (I would feel a lot better if Amazon didn't remember my credit card number.) Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | Due process for all | Periwinkle -- Consulting (408)356-8506 | used to be the | 16345 Englewood Ave. frantz@pwpconsult.com | American way. | Los Gatos, CA 95032, USA --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
On Tuesday, Jun 3, 2003, at 18:15 US/Eastern, Bill Frantz wrote:
At 2:21 PM -0700 6/3/03, Jeroen C. van Gelderen wrote:
Perhaps that measure is too coarse grained. For instance, in the domain of "security advisories" most emails are digitally signed with OpenPGP. And in the domain of online credit card payments HTTPS has displaced HTTP.
I know of one system that takes credit cards over HTTPS, and then sends the credit card number, encrypted with GPG to a backend system for processing. It isn't perfect, but it's better than storing the credit card number on a database accessible to the web server. (I would feel a lot better if Amazon didn't remember my credit card number.)
I noticed this the other day whilst buying something at Amazon: allegedly, Amazon doesn't store your CC number in a network readable database: http://www.amazon.com/exec/obidos/tg/browse/-/518224/002-9740615-3944845 "To provide you with an additional layer of security, all credit card numbers provided to Amazon.com are stored on a computer that is not connected to the Internet. After you type or call it in, your complete credit card number is transferred to this secure machine across a proprietary one-way interface. This computer is not accessible by network or modem, and the number is not stored anywhere else." Now I'm not sure how they get to use the number during the billing process but hey... :) I don't know if I'd feel much better if Amazon didn't have my CC on file. The danger of a disgruntled sysadmin snarfing the numbers while they pass trough the system for one time use during a single billing cycle seems to real for me. -J -- Jeroen C. van Gelderen - jeroen@vangelderen.org War prosperity is like the prosperity that an earthquake or a plague brings. The earthquake means good business for construction workers, and cholera improves the business of physicians, pharmacists, and undertakers; but no one has for that reason yet sought to celebrate earthquakes and cholera as stimulators of the productive forces in the general interest. -- Ludwig von Mises
The White House Communications Agency is also working hard to secure presidential communications, with legacy systems needing ever-increasing maintenance and upgrades, the market continuing to outpace the big-ticket legacy clunker equipment, too expensive to chuck outright, yet having flaws begging for discovery, patches galore (most relying upon obscurity and secrecy), and the operators from the four military branches which run the system turning over regularly and each new wave needing special training to work the patchwork klutz, with retiring old salts who are the only ones who know how the hybrids work and whether they are truly secure, and not least, NSA doing it damndest to get new systems installed in all the prez's habitats and vehicles and layovers around the world, deploying crypto tools partly off the shelf, partly purpose-built at Ft Meade -- and the whole precarious mess subject to a 20-year-old pulling a thumb out of the dike and letting flow proof that the leader of the free world is up to what you'd expect despite the multi-million rig to hide the obvious. Rumor is that 98% of what is handled top secretly is trivial fluff, as with most mil comm, SIGINT, cellphone, microwave, fiber-optic, so that snake oil is apt protection. If all telecomm was shut down no more would change than pulling the plug on television. The other 2% is what the billions and billions is trying to find among the EM cataract of plaintext and speak smoke and whine -- by whoever may be plotting a world of pure bugfuck. But that could also be discovered by thoughtful analysis of any singular mania, whether religion, higher-ed, sport, stock market, politics, or mil-biz. Here's a recent account from "Army Communicator" of what's up at ever busier and harried and thumbplugging WHCA: http://cryptome.org/whca2003.pdg (680KB) WHCA itself is recruiting thumbs: http://www.disa.mil/whca
Depends on how it gets passed from the web servers to that computer. If it's encrypted with a public key on the web server that only the database has the private half, you're safe from someone sniffing that "proprietary one-way interface." However, if somone's already broken into the web server, they can collect the cc:'s before they get sent to the secure db. So if you're an old Amazon customer and don't change your CC >BEFORE< someone hacks into their web server, you're safe. It's certainly better than storing all CC's on the web server. Now if those CC's are in raw text on the DB end, Amazon is up shit's creek if someone walks away with a db dump, backup tape, or whatever. I don't claim to know what they're using, but long, long time ago, in another galaxy, I used to work with a product from OpenMarket that worked similarly, but they held all credit cards encrypted in the DB making it much harder. (Of course if you have the key it's as good as cleartext, but it was at least another layer of protection.) Ultimately they'll need either a cybercash interface or some interface to a bank to charge your card. If the bad guy intercepts at that level or gets unencrypted access to the DB, or you change your CC while the web server is compromised, you are in for some interesting CC statements. However, this is in a lot of ways MORE secure than handing that waiter or store clerk your CC. Remember that nice yellow slip has your signature, CC number and expiration date on it. Very useful for an attacker. Infact, they likely had physical access to the CC and have that extra 3 digit # on the back too. Some stores even ask for your driver's license to prove that you are you, which at least in NY has your date of birth and address as well. Even more useful to the evildoer. If they can also get your SSN on top of that, you're at their mercy. Think about any credit application type transactions.... these days, buying (some) cell phones, or car, or signing up for satelite TV requires these. I feel safer with Amazon's use of my CC than the above, don't you? ----------------------Kaos-Keraunos-Kybernetos--------------------------- + ^ + :25Kliters anthrax, 38K liters botulinum toxin, 500 tons of /|\ \|/ :sarin, mustard and VX gas, mobile bio-weapons labs, nukular /\|/\ <--*-->:weapons.. Reasons for war on Iraq - GWB 2003-01-28 speech. \/|\/ /|\ :Found to date: 0. Cost of war: $800,000,000,000 USD. \|/ + v + : The look on Sadam's face - priceless! --------_sunder_@_sunder_._net_------- http://www.sunder.net ------------ On Tue, 3 Jun 2003, Jeroen van Gelderen wrote:
"To provide you with an additional layer of security, all credit card numbers provided to Amazon.com are stored on a computer that is not connected to the Internet. After you type or call it in, your complete credit card number is transferred to this secure machine across a proprietary one-way interface. This computer is not accessible by network or modem, and the number is not stored anywhere else."
Now I'm not sure how they get to use the number during the billing process but hey... :)
I don't know if I'd feel much better if Amazon didn't have my CC on file. The danger of a disgruntled sysadmin snarfing the numbers while they pass trough the system for one time use during a single billing cycle seems to real for me.
Bill Frantz wrote:
I know of one system that takes credit cards over HTTPS, and then sends the credit card number, encrypted with GPG to a backend system for processing. For that matter, our system here discards the CC after use (the pre-auth step with the merchant bank agent gives us back a "fulfillment handle" that can only be used to fulfill or cancel that individual transaction - but of course Amazon *want* to keep your CC details so they can do their fast-checkout patented thingy.
At 12:02 PM 6/4/2003 +0100, Dave Howe wrote:
For that matter, our system here discards the CC after use (the pre-auth step with the merchant bank agent gives us back a "fulfillment handle" that can only be used to fulfill or cancel that individual transaction - but of course Amazon *want* to keep your CC details so they can do their fast-checkout patented thingy.
the ground rules given the x9a10 working group for the x9.59 standard was to preserve the integrity of the financial infrastructure for all (credit, debit, stored-value, POS, internet, non-internet, aka ALL) electronic retail payments. it was one of the things that led us down the path of certless operation. We had previously done the work on the original payment gateway and had to perform various kinds of due diligence on all the major CA vendors .... which started to dawn on us that stale, static certificates were actually redundant and superfluous in the financial business process. http://www.garlic.com/~lynn/aadsm5.html#asrn2 http://www.garlic.com/~lynn/aadsm5.html#asrn3 sort of the clinker was starting to do operational and performance profile on any of the existing payment networks .... and it was evident that there was a huge mismatch between the existing payment transaction payload size and any of the commonly used certificates (even the drastically simplified replying-party-only certificates carrying only an account number and public key). Two major characteristics of X9.59 was that it would provide 1) end-to-end authentication (aka the consumers financial institution would be the one responsible for performing authentication) and 2) account numbers used in X9.59 transactions could not be used in unauthenticated transactions. Some of the '90s digitally signature oriented specifications had authentication occurring at the internet boundary and stripping off the certificate (avoiding the extreme certificate payload penalty in the payment network). The downside was that the party performing the authentication didn't necessarily have the consumer's interest in mind and Visa subsequently presented statistics at a ISO standards meeting on the number of transactions flowing through the network 1) with a flag claiming to have been digitally signature authenticated and 2) they could prove that no digital signature technology was ever involved. Evesdropping, sniffing or harvesting account numbers in the current infrastructure (at any point in the process, by insiders or outsiders, traditionally financial exploits have been 90 percent insiders) can result in fraudulent transactions. As a result, existing account numbers effectively become a form of shared-secret and need to be protected. With the X9.59 business rule requiring the account number to only be used in authenticated transactions, simple harvesting of a X9.59 account number doesn't result in fraud. Issuing financial institutions then can use existing business processes that support mapping of different account numbers to the same account. A discussion of the security proportional to risk with regard to credit card transactions: http://www.garlic.com/~lynn//2001h.html#61 Net banking, is it safe? The issue with the use of SSL for protecting credit card transactions isn't addressing all or even the major vulnerability to the infrastructure. Eliminating the account number as a form of shared secret addresses all of the vulnerabilities, not just the transaction-in-flight vulnerability addressed by SSL. As a byproduct of addressing all of the shared-secret related vulnerabilities, it also eliminates the need to use SSL for protecting the shared secret while being transmitted. Detailed report of its use in the NACHA debit network trials can be found at http://internetcouncil.nacha.org/News/news.html scroll down to "July 23, 2001: Digital Signatures Can Secure ATM Card Payments" More details of X9.59 standard: http://www.garlic.com/~lynn/index.html#x959 -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
-- Everyone in America has several shared secrets identifying them -- the number of the beast to identify them to the state, and their credit card numbers identifying them to various financial institutions, plus a hundred passwords to login to their email, their bank, their network provider, e-gold, etc. The PKI idea was that we would instead use PK in place of shared secrets, but if an ordinary person had a private key, what could he use it for? The spam that seeks to get us to login to e-g0ld and the BankOf4merica.com works because the logins are based on shared secrets, not private keys, and the networks are setup to rely on shared secrets because there is no practical alternative. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG r9lUivpSt7tWiPOxVr17a9sjkgXnnbC5matqsa6/ 4UovWiFVbzH8bFEhVsekeydmrrDmez+5/B/3ZSo4B
At 04:25 PM 6/4/2003 -0700, James A. Donald wrote:
-- Everyone in America has several shared secrets identifying them -- the number of the beast to identify them to the state, and their credit card numbers identifying them to various financial institutions, plus a hundred passwords to login to their email, their bank, their network provider, e-gold, etc.
The PKI idea was that we would instead use PK in place of shared secrets, but if an ordinary person had a private key, what could he use it for?
The spam that seeks to get us to login to e-g0ld and the BankOf4merica.com works because the logins are based on shared secrets, not private keys, and the networks are setup to rely on shared secrets because there is no practical alternative.
one could claim that public-key is a practical alternative but it got significantly sidetracked with independent business model that wanted extract huge amount of money out of existing infrastructures (say totally brand new independent operations wanting $100/annum for every person, extracted from the existing infrastructure for no significant positive benefit ... aka say 200m people at @$100/annum is $20b/annum ... in return for some abstract bit vapor that doesn't change any core business issue). it is relatively trivial to demonstrate that public keys can be registered in every business process that currently registers shared-secrets (pins, passwords, radius, kerberos, etc, etc). the issue then becomes one of cost to change/upgrade those infrastructures to support digital signature authentication with the stored public keys in lieu of string comparison (no new business operations, no new significant transfer of wealth to brand new outside business entities, etc). however, think about even these simple economics for a minute .... even for relatively modest technology changes that don't change any of the business processes/relationships ... it still costs some money ... and the beneficiary isn't the institution, it is the individual. The individual has the paradigm changed from hundreds of shared-secrets to a single key-pair ... however each institution continues to see just as many individuals and account records. From a very practical standpoint ... entities don't frequently fund things that they don't benefit from ... and typically most success is achieved when the entity that benefits from the change is also driving/funding the change. the issue is to find out how the individual pays for the change .... or figure out how the institutions are going to benefit. -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
-- On 4 Jun 2003 at 20:58, Anne & Lynn Wheeler wrote:
it is relatively trivial to demonstrate that public keys can be registered in every business process that currently registers shared- secrets (pins, passwords, radius, kerberos, etc, etc)
I don't think so. Suppose the e-gold, to prevent this sea of spam trying to get people to login to fake e-gold sites, wanted people to use public keys instead of shared secrets, making your secret key the instrument that controls the account instead of your shared password. They could not do this using the standard IE webbrowser. They would have to get users to download a custom client, or at least, like hushmail, a custom control inside IE. HTTPS assumes that the certificate shall be blessed by the administrator out of band, and has no mechanism for using a private key to establish that a user is simply the same user as last time. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG q1a1Whb1YeRws7qoDm6h15qfDstFHciUyP2I4fte 42lCFXf0IqXfh5Mz2mFtznxv6N40EuqpKvQJhLBgS
On Fri, 06 Jun 2003, James A. Donald wrote:
Suppose the e-gold, to prevent this sea of spam trying to get people to login to fake e-gold sites, wanted people to use public keys instead of shared secrets, making your secret key the instrument that controls the account instead of your shared password.
Why does e-gold have any interest in what people do on other sites?
HTTPS assumes that the certificate shall be blessed by the administrator out of band, and has no mechanism for using a private key to establish that a user is simply the same user as last time.
Yes. There's a virtue there. Knowing a secure channel exists is frequently more important than who is on the other line. For example, What's my favorite brand of lighter? You live in a Bob's cold, dark cave, where you hate life. Insert water dripping and scabs until you're amused. You have the chance to contact, and maybe move to, Alice's bright, warm cave. Sounds good to you. How to authenticate the offer? Replay various notions of various fiction writers, here. The problem is interesting. Solved, but interesting. Very few folks have reason to help you authenticate them. Deal. Even if people don't understand what https (and ssl) do, they still serve a purpose. Even if it isn't the one you wanted solved. And if there were a problem worth solving, would it be unsolved? I'll refrain from asking how many people use digsigs, and what that solves. Only because that's rude. None of this solves life for average banking customers, but I think "this" is something that "they" are willing to ignore. Most people seem to trust one another. What do you do? -j -- Jamie Lawrence jal@jal.org "The sign that points to Boston doesn't have to go there." - Max Scheler
At 04:24 PM 6/6/2003 -0700, James A. Donald wrote:
I don't think so.
??? public key registered in place of shared-secret? NACHA debit trials using digitally signed transactions did it with both software keys as well as hardware tokens. http://internetcouncil.nacha.org/News/news.html in the above scroll down to July 23, 2001 ... has pointer to detailed report? X9.59 straight forward establishes it as standard .... with some activity moving on to ISO http://www.garlic.com/~lynn/index.html#x959 pk-init draft for kerberos specifies that public key can be registered in place of shared secret. following has demo of it with radius with public keys registered in place of shared-secret. http://www.asuretee.com/ the radius implementation has been done be a number of people. in all of these cases, there is change in the business process and/or business relationship .... doesn't introduce totally unrelated parties to the business activities. the is digital signing on the senders side (actually a subset of existing PKI technology) and digital signature verification on the receivers side (again a subset of existing PKI technology). To the extent that there is impact on existing business process ... it is like in the case of introducing x9.59 authentication for credit transactions that have relatively little authentication currently .... and as a result would eliminate major portion of the existing credit card transaction related fraud. The big issue isn't the availability of the technology ... although there is a slight nit in the asuretee case being FIPS186-2, ecdsa .... and having support in CAPI and related infrastructures. It not working (easily) is like when my wife and I were doing the original payment gateway .... with this little client/server startup in menlo park (later moved to mountain view and have since been bought by AOL) and people saying that SSL didn't exist ... misc ref from the past http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
-- On 6 Jun 2003 at 17:45, Anne & Lynn Wheeler wrote:
??? public key registered in place of shared-secret?
NACHA debit trials using digitally signed transactions did it with both software keys as well as hardware tokens. http://internetcouncil.nacha.org/News/news.html in the above scroll down to July 23, 2001 ... has pointer to detailed report?
X9.59 straight forward establishes it as standard .... with some activity moving on to ISO http://www.garlic.com/~lynn/index.html#x959
pk-init draft for kerberos specifies that public key can be registered in place of shared secret.
following has demo of it with radius with public keys registered in place of shared-secret. http://www.asuretee.com/ the radius implementation has been done be a number of people.
in all of these cases, there is change in the business process and/or business relationship
Precisely. I am talking about direct substitution that should be almost invisible to both parties, using private keys exactly as passwords are used, except that the fake site trick fails. In fact one can do a direct substitution that is almost invisible to both parties, but it requires custom software on both client and server. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG EWYCMfM1ZE4FqHNgG8Xxq4Raoo0u92HCJxUTm9d6 4UkMVch4UVf7oFF6jEx+Nj5WJffMhrKnlz65qZyH1 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
-- Over the past ten years there have been many attempts to get a micropayment system working, all of which have failed dismally, leading to a widespread attitude that internet micropayments just do not work, and never will work. In the past 24 hours, e-gold has done fifty thousand micropayments, of which thirty thousand were one milligram of gold or under (about one cent or under) These are non anonymous, in that e-gold can link payer to payee, but anonymous in that it laborious to link e-gold account numbers to true names. e-gold has no knowledge what they are being used for. If they gathered that much information, it probably would not be worthwhile for their customers, but I would guess these are mostly per-click-through payments for ads. Some proportion of these payments must be e-gold's own referral scheme, but the majority have to be other people's schemes, perhaps other people's similar schemes. The fact that e-gold does not know what is going on suggests that past attempts to support micropayments failed by putting too great a burden on those seeking to participate. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG bXT+Ssbr8YwqxmGU48nKVUNmy/V5W9MrCY8AJ1iu 4JjvpESYIz/nh/OrZvLSSq8INjokq5UGC2eACxupI --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
On Mon, Jun 02, 2003 at 10:09:06AM -0400, Ian Grigg wrote:
A lot of the tools and blocks are too hard to understand. "Inaccessible" might be the proper term. This might apply to, for example, SSL, and more so to IPSec. These have a lower survival rate, simply because as developers look at them, their eyes glaze over and they move on. I heard one guy say that "you can read SSH in an hour and understand what's going on, but not SSL."
Some who can't understand SSL won't be able to do better. Especially since there is at least one very good book on it.
Also, a lot of cryptosystems are put together by committees. SSH was originally put together by one guy. He did the lot.
The original SSH protocol had holes so large that you could drive a truck through them. Tatu posted it to various lists and got lots of advice on how to clean it up. It still had holes that were being found years later. SSLv2, which was also designed by an individual, also had major flaws. And that was the second cut! I haven't seen v1, maybe Eric can shed some light on how bad it was. Peer review is not "design by comittie". It is the way to get strong protocols. When I have to roll my own (usually because its working in a limited environment and I don't have a choice) I get it reviewed. The protocol designer usually misses something in his own protocol.
I'd say that conditions for Internet crypto system success would include:
0. USE EXISTING SECURITY PRIMITIVES which allows you to
4. Concentrate on the application, not the crypto.
Rolling your own crypto is where 95% of crypto apps fail... the developers either take too much time on it to the detrimient of the useability because it is the sexy thing to work on, or they write an insecure algorithm/protocol/system. Usually they do both! Eric --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
Eric Murray wrote:
On Mon, Jun 02, 2003 at 10:09:06AM -0400, Ian Grigg wrote:
A lot of the tools and blocks are too hard to understand. "Inaccessible" might be the proper term. This might apply to, for example, SSL, and more so to IPSec. These have a lower survival rate, simply because as developers look at them, their eyes glaze over and they move on. I heard one guy say that "you can read SSH in an hour and understand what's going on, but not SSL."
Some who can't understand SSL won't be able to do better. Especially since there is at least one very good book on it.
That presupposes that one can do "better" using SSL because SSL is "better". It is a challenge to translate SSL's strong peer reviewed heritage into a secure crypto system. In practice, if the tool is hard to use, an implementation opens itself up for problems in its usage of SSL. There can be bugs in the interface, bugs in the architecture reflected by the complexity of the interface, and there can be bugs in the underlying tools. It may be that the SSL underlying code is perfect. But that the application is weak because the implementor didn't understand how to drive it; in which case, if he can roll his own, he may end up with a more secure overall package.
Also, a lot of cryptosystems are put together by committees. SSH was originally put together by one guy. He did the lot.
The original SSH protocol had holes so large that you could drive a truck through them. Tatu posted it to various lists and got lots of advice on how to clean it up. It still had holes that were being found years later.
Yep. But the application got up and going, he didn't wait for the protocol to be perfected, which mean that the the application had a much greater chance of ultimate success, and many more scenarios were protected than otherwise would have been. Now it's a good protocol (Peter G reports that it is highly analogous to SSL, but with its own packet formats). It's hole-filled first effort doesn't seem to have done it so much harm.
SSLv2, which was also designed by an individual, also had major flaws. And that was the second cut! I haven't seen v1, maybe Eric can shed some light on how bad it was.
[ Someone commented before that v1 was not deemed serious (Marc A?) and v2 was the more acceptable starting point (Weinsteins?). ]
Peer review is not "design by comittie".
Let me clarify. SSL - the protocol - was not designed by committee, but, the size of the teams involved in the crypto systems was in excess of the people who were intimately familiar with the protocol. For the most familiar example, browsing, there were, it seems, many people involved in the overall grafting of SSL into the original HTML/HTTP system. Hence, SSL as a protocol might be a fine piece of work. SSL as a browsing application is flawed, and that's partly because too many different people and agendas were involved. (I think the design-by-committee criticism would stick more strongly to IPSec.)
It is the way to get strong protocols. When I have to roll my own (usually because its working in a limited environment and I don't have a choice) I get it reviewed. The protocol designer usually misses something in his own protocol.
Sure. If someone does roll their own, then they should get it reviewed.
I'd say that conditions for Internet crypto system success would include:
0. USE EXISTING SECURITY PRIMITIVES
:-) I know this is the mantra of the field. Quesion is: which PRIMITIVES? 1. RSA? 2. SSL, written from the RFC? 3. OpenSSL, the toolkit? EKR's fine effort? 4. RSADSI security consultants, selling you theirs? 5. ...
which allows you to
4. Concentrate on the application, not the crypto.
Rolling your own crypto is where 95% of crypto apps fail... the developers either take too much time on it to the detrimient of the useability because it is the sexy thing to work on, or they write an insecure algorithm/protocol/system. Usually they do both!
It's true that if there is a perfectly good alternative available, it is probably more expensive to roll your own than to use the perfectly good alternative. But, that assumes an awful lot. For a start, that it exists. SSL is touted as the answer to everything, but it seems to be a connection oriented protocol, which would make it less use for speech, media, mail, chat (?), by way of example. It's also very much oriented to x.509 and similar certificate/PKI models, which means it is difficult to use in web of trust (I know this because we started on the path of adding web of trust and text signing features to x.509 before going back to OpenPGP), financial and nymous applications whereby trust is bootstrapped a different way. Then there is understanding, both of the protocol, and the project's needs. I know that when I'm in a big project and I come across a complex new requirement, often, it is an open question as to whether make or buy is the appropriate choice. I do know that 'make' will always teach me about the subject, and eventually, it will teach me which one to buy, or it will give me a system tuned to my needs. In contrast, using a black box is always a big risk. Which black box? There are always 10 experts for every black box out there, and they are all asking for lots of bux to say they're right. And, traditionally, when you buy in a black box, chances are, it's a grey box, or it's a black bucket, or...
From the outside world's point of view, it still seems a very plausible decision to roll ones own crypto.
( Has anyone read Ferguson and Schneier's _Practical Cryptography_ ? Does it address this issue of how an outsider decides how to "make or buy"? I just read the reviews on Amazon, they are ... entertaining! http://www.amazon.com/exec/obidos/tg/detail/-/0471223573/qid=1054578908/sr=8-1/ref=sr_8_1/103-4510729-0384610?v=glance&s=books&n=507846 ) -- iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
Eric Murray wrote: It may be that the SSL underlying code is perfect. But that the application is weak because the implementor didn't understand how to drive it; in which case, if he can roll his own, he may end up with a more secure overall package. I don't think this is likely to be true. In my experience,
Ian Grigg <iang@systemics.com> writes: people who learn enough to design their own thing also learn enough to be able to do SSL properly.
SSLv2, which was also designed by an individual, also had major flaws. And that was the second cut! I haven't seen v1, maybe Eric can shed some light on how bad it was.
[ Someone commented before that v1 was not deemed serious (Marc A?) and v2 was the more acceptable starting point (Weinsteins?). ] That's not true as far as I know. V1 and V2 were designed by the same guy (Kipp Hickman). V1 is actually very similar to V2, except that the integrity stuff is all screwed up. As far as I can tell, the fact of the matter is that Kipp didn't understand the security issues until Abadi and to some extent Schiffman sold them some clues.
Peer review is not "design by comittie".
Let me clarify. SSL - the protocol - was not designed by committee, but, the size of the teams involved in the crypto systems was in excess of the people who were intimately familiar with the protocol. For the most familiar example, browsing, there were, it seems, many people involved in the overall grafting of SSL into the original HTML/HTTP system. As far as I know, that's not the case. The original Netscape team was very small and there really weren't any significant choices to be made.
It is the way to get strong protocols. When I have to roll my own (usually because its working in a limited environment and I don't have a choice) I get it reviewed. The protocol designer usually misses something in his own protocol.
Sure. If someone does roll their own, then they should get it reviewed. That's not my experience. WEP and PPTP come to mind.
I'd say that conditions for Internet crypto system success would include:
0. USE EXISTING SECURITY PRIMITIVES
:-)
I know this is the mantra of the field.
Quesion is: which PRIMITIVES?
1. RSA? 2. SSL, written from the RFC? 3. OpenSSL, the toolkit? EKR's fine effort? 4. RSADSI security consultants, selling you theirs? 5. ... I would say the highest level primitives you can get away with.
But, that assumes an awful lot. For a start, that it exists. SSL is touted as the answer to everything, but it seems to be a connection oriented protocol, which would make it less use for speech, media, mail, chat (?), by way of example. SSL is quite fine for chat, actually. It's one of the major things that people use for IM. The issue with speech and media isn't connection-orientation but rather datagram versus stream data.
Then there is understanding, both of the protocol, and the project's needs. I know that when I'm in a big project and I come across a complex new requirement, often, it is an open question as to whether make or buy is the appropriate choice. I do know that 'make' will always teach me about the subject, and eventually, it will teach me which one to buy, or it will give me a system tuned to my needs. The history of people who go this course suggests otherwise. They generally get lousy solutions.
-Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
Eric Rescorla wrote:
Eric Murray wrote: It may be that the SSL underlying code is perfect. But that the application is weak because the implementor didn't understand how to drive it; in which case, if he can roll his own, he may end up with a more secure overall package. I don't think this is likely to be true. In my experience,
Ian Grigg <iang@systemics.com> writes: people who learn enough to design their own thing also learn enough to be able to do SSL properly.
True, although, that begs the question as to how they learn. Only by doing, I'd say. I think one learns a lot more from making mistakes and building ones own attempt than following the words of wise.
SSLv2, which was also designed by an individual, also had major flaws. And that was the second cut! I haven't seen v1, maybe Eric can shed some light on how bad it was.
[ Someone commented before that v1 was not deemed serious (Marc A?) and v2 was the more acceptable starting point (Weinsteins?). ] That's not true as far as I know. V1 and V2 were designed by the same guy (Kipp Hickman). V1 is actually very similar to V2, except that the integrity stuff is all screwed up. As far as I can tell, the fact of the matter is that Kipp didn't understand the security issues until Abadi and to some extent Schiffman sold them some clues.
OK. Then I am confused about the post that came out recently. It would be very interesting to hear the story, written up.
Sure. If someone does roll their own, then they should get it reviewed. That's not my experience. WEP and PPTP come to mind.
Ah, good point: There should be some point on that list about building ones cryptosystem outside the domain of an institution, which tends to have too many conflicting requirements, and cannot limit itself to a simple system. (And, yes, some protocols don't get peer reviewed. I wasn't debating that.)
But, that assumes an awful lot. For a start, that it exists. SSL is touted as the answer to everything, but it seems to be a connection oriented protocol, which would make it less use for speech, media, mail, chat (?), by way of example.
SSL is quite fine for chat, actually. It's one of the major things that people use for IM. The issue with speech and media isn't connection-orientation but rather datagram versus stream data.
I knew I was in trouble on chat, that's why I stuck the interrogation mark in there :-) We recently added an email-like capability to our (homegrown) crypto system, and intend to expand that to chat. But, in order to do that, we have to expand the crypto subsystem (SOX) to include connection-oriented modes. [ Hence, an open question floating around here is "why don't we use SSL" which hasn't been definitively answered as yet. ]
Then there is understanding, both of the protocol, and the project's needs. I know that when I'm in a big project and I come across a complex new requirement, often, it is an open question as to whether make or buy is the appropriate choice. I do know that 'make' will always teach me about the subject, and eventually, it will teach me which one to buy, or it will give me a system tuned to my needs.
The history of people who go this course suggests otherwise. They generally get lousy solutions.
I think it would be very interesting to do a study of all the cryptosystems out there and measure what succeeds, what doesn't, what's secure, and what's not. What cost too much money and what saved money. One of the issues that we see is that too many security people assume that "insecure" is "bad". What they fail to perceive is that an insecure system is often sufficient for the times and places. WEP for example is perfectly fine, unless you are attacked by a guy with a WEP cracking kit! Then it's a perfectly lousy cryptosubsystem. It's like the GSM story, whereby 8 years down the track, Lucky Green cracked the crypto by probing the SIMs to extract the secret algorithm over a period of many months (which algorithm then fell to Ian Goldberg and Dave Wagner in a few hours). In that case, some GSM guy said that, it was good because it worked for 8 years, that shows the design was good, doesn't it? And Lucky said, now you've got to replace hundreds of millions of SIMs, that's got to be a bad design, no? (Lucky might be able to confirm the real story there.) Different ways of looking at the same thing. They are both valid points of view. To work out the difference, we need to go to costs and benefits. Who won and who lost? I never heard how it panned out. -- iang
Ian Grigg <iang@systemics.com> writes:
Eric Rescorla wrote: True, although, that begs the question as to how they learn. Only by doing, I'd say. I think one learns a lot more from making mistakes and building ones own attempt than following the words of wise. One learns by *practicing*.
That said, though, there's next to no need for people to know how to design their own communications security protocols, so it's not really that important for them to learn.
OK. Then I am confused about the post that came out recently. It would be very interesting to hear the story, written up. The rough version of it is in my book.
-Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/
At 08:40 AM 06/03/2003 -0400, Ian Grigg wrote:
Eric Rescorla wrote:
Ian Grigg <iang@systemics.com> writes:
....
I don't think this is likely to be true. In my experience, people who learn enough to design their own thing also learn enough to be able to do SSL properly.
True, although, that begs the question as to how they learn. Only by doing, I'd say. I think one learns a lot more from making mistakes and building ones own attempt than following the words of wise.
The catch, of course, is that most cryptosystems are only useful if they're widely deployed. Learning from mistakes is good, but endangering large numbers of users in the process is bad. By contrast, learning cryptanalysis doesn't have this weakness - if you can't crack somebody else's code, no problem, (with obvious exceptions for people who need to learn cryptanalysis quickly in wartime or whatever, or undertrained cryptanalysts who are hired by people who are learning cryptography by making mistakes...)
WEP for example is perfectly fine, unless you are attacked by a guy with a WEP cracking kit! Then it's a perfectly lousy cryptosubsystem.
Even ROT-13's not too bad unless somebody tries to crack it, though some people who've spent way too much time with it can just read the stuff by recognizing it as an alternate font :-) Somebody else followed up by mentioning that, while GSM's privacy encryption is cracked, their authentication encryption isn't, and they aren't getting massively attacked. I thought the state of the art at this point was that the authentication is also crackable, but it's currently enough work that nobody's or almost nobody's bothering, because governments can get what they want by telling phone companies to give them the information, and regular criminals can get the equivalent of cracking GSM authentication by stealing mobile phones more easily than by hiring cryptanalysts, and unlike satellite TV smartcard cracking, nobody's figured out any potential market opportunities for widespread cracked GSM.
Ian Grigg wrote:
It's like the GSM story, whereby 8 years down the track, Lucky Green cracked the crypto by probing the SIMs to extract the secret algorithm over a period of many months (which algorithm then fell to Ian Goldberg and Dave Wagner in a few hours).
In that case, some GSM guy said that, it was good because it worked for 8 years, that shows the design was good, doesn't it?
And Lucky said, now you've got to replace hundreds of millions of SIMs, that's got to be a bad design, no?
Well the point here is that the data encryption in GSM is not relevant to the people running the network. The authentication is secure, so there is no fraud, so they still get the money from network usage. Privacy was never really there since the traffic is not encrypted once it hit the base station, so the relevant government agencies can be kept happy. The encryption was only relevant to protect the consumers from each other. eric (hopefully remembering things correctly) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
Ian Grigg wrote:
It's like the GSM story, whereby 8 years down the track, Lucky Green cracked the crypto by probing the SIMs to extract the secret algorithm over a period of many months (which algorithm then fell to Ian Goldberg and Dave Wagner in a few hours).
In that case, some GSM guy said that, it was good because it worked for 8 years, that shows the design was good, doesn't it?
And Lucky said, now you've got to replace hundreds of millions of SIMs, that's got to be a bad design, no?
Well the point here is that the data encryption in GSM is not relevant to the people running the network. The authentication is secure, so there is no fraud, so they still get the money from network usage. Privacy was never really there since the traffic is not encrypted once it hit the base station, so the relevant government agencies can be kept happy. The encryption was only relevant to protect the consumers from each other. eric (hopefully remembering things correctly) ----- End forwarded message -----
Ian Grigg wrote:
It's like the GSM story, whereby 8 years down the track, Lucky Green cracked the crypto by probing the SIMs to extract the secret algorithm over a period of many months (which algorithm then fell to Ian Goldberg and Dave Wagner in a few hours).
In that case, some GSM guy said that, it was good because it worked for 8 years, that shows the design was good, doesn't it?
And Lucky said, now you've got to replace hundreds of millions of SIMs, that's got to be a bad design, no?
Well the point here is that the data encryption in GSM is not relevant to the people running the network. The authentication is secure, so there is no fraud, so they still get the money from network usage. Privacy was never really there since the traffic is not encrypted once it hit the base station, so the relevant government agencies can be kept happy. The encryption was only relevant to protect the consumers from each other. eric (hopefully remembering things correctly) ----- End forwarded message -----
At 10:09 AM 6/2/03 -0400, Ian Grigg wrote: ...
(One doesn't hear much about crypto phones these days. Was this really a need?)
I think phones that encrypt the landline part of the call are pretty low-priority for most of us, since it costs something to eavesdrop on these calls. But anything that goes over the air, whether cellphone or cordless phone, ought to be properly encrypted, and it isn't now. This is a big vulnerability in a lot of places, and once you've built the intercept and decrypting hardware, it's easy to eavesdrop on huge numbers of people. You can imagine either rogue cops and spies doing this, or private criminals. I keep wondering how hard it would be to build a cordless phone system on top of 802.11b with some kind of decent encryption being used. I'd really like to be able to move from a digital spread spectrum cordless phone (which probably has a 16-bit key for the spreading sequence or some such depressing thing) to a phone that can't be eavesdropped on without tapping the wire. And for cellphones, I keep thinking we need a way to sell a secure cellphone service that doesn't involve trying to make huge changes to the infrastructure, which probably means a call center that handles all contact with the cellphone itself, always encrypted. Something like this would allow me to buy a phone and sign a contract, and quickly get real security on all my digital calls going over the air. End-to-end encryption isn't nearly as important. There's no reason it couldn't be supported, of course, when both endpoints had the right kind of phone, but it's a small additional value. The big win is to stop spewing private conversations over the radio in the clear.
iang
--John Kelsey, kelsey.j@ix.netcom.com PGP: FA48 3237 9AD5 30AC EEDD BBC8 2A80 6948 4CAA F259 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
At 7:42 AM -0700 6/3/03, John Kelsey wrote:
I keep wondering how hard it would be to build a cordless phone system on top of 802.11b with some kind of decent encryption being used. I'd really like to be able to move from a digital spread spectrum cordless phone (which probably has a 16-bit key for the spreading sequence or some such depressing thing) to a phone that can't be eavesdropped on without tapping the wire.
<rant> I've spent some time recently looking at Voice over IP (VoIP) implementations. My immediate reaction to reading the standards is that they a complete answer to a telephone company executive's wet dreams. Conferencing, Automatic call forwarding, Billing etc. etc., they're all covered. The result is a protocol that is beyond baroque and well into rococo. I think the various standards bodies are still trying to deal with issues in the protocols that weren't thought of from the start. Of course, once you have your call set up, you have to encrypt it. Most of the VoIP implementations use Real Time Streaming Protocol (RTSP, RFC2326), which requires two UDP ports through your firewall. Then you have to encrypt the RTSP traffic. I have seen reference to an encryption protocol specifically for RTSP, but a quick scan of STD1 didn't turn it up, so it is probably still a draft. I don't know anything about its security. The other choice is IPSec. IPSec seems happiest securing traffic between machines with permanent IP addresses. It is a nightmare to use with Network Address Translation. What would be really nice would be a VoIP system that used TCP instead of UDP. (I know that if TCP goes into error recovery, there is going to be major jitter in the voice. I know it will be hard to support conferencing. I know it will not gracefully bridge to the POTS network. Etc. I'm willing to put up with that to avoid the pain that comes with UDP.) Then I can just tunnel it through SSH, or hack it to use SSL/TLS. Oh well. </rant> Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | Due process for all | Periwinkle -- Consulting (408)356-8506 | used to be the | 16345 Englewood Ave. frantz@pwpconsult.com | American way. | Los Gatos, CA 95032, USA --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
On 2003-06-03, John Kelsey uttered to iang@systemics.com and EKR:
I think phones that encrypt the landline part of the call are pretty low-priority for most of us, since it costs something to eavesdrop on these calls.
I don't think the cost of listening into a single call is the primary issue, regardless of transmission technology. There are extra costs to tracking a mobile user, true, but from the standpoint of law enforcement agencies, these costs are rather minimal. (From the standpoint of a private eavesdropper the difference is much greater, since the subject is mobile and one cannot take advantage of the centralized points of failure of the mobile communications network.) Rather it's the fact that the Big Brother doesn't have the necessary total funds, and so doesn't listen into a considerable proportion of calls as a whole. The implication is, as the costs go down, it becomes possible to listen into more calls, and the fear goes up. Especially so when speech recognition and subsequent pattern analysis become computationally feasible at a wider scale. When this is the case, it should be expected that the use of crypto goes up. But right now, even people who "have something to hide" do not perceive cleartext communication to be a risk worth expending resources to thwart.
But anything that goes over the air, whether cellphone or cordless phone, ought to be properly encrypted, and it isn't now.
Why? As I see it, this is fundamentally an economic question, not a technical one. It's about the risk of somebody listening in, taking notice and acting adversely to the talker's own interest, versus speaking what one wants without having to take expensive precautions. Currently such risks mostly materialize when one *truly* has something to hide, that is, one talks about something criminal, there is reason to believe law enforcement agencies might be listening and one talks in terms which will reasonably lead to conviction in the right circumstances. The probability of that happening is surprisingly low, especially from the security professional's somewhat paranoid viewpoint.
This is a big vulnerability in a lot of places, and once you've built the intercept and decrypting hardware, it's easy to eavesdrop on huge numbers of people.
True. But in average people will shortly notice the development, and prepare from there on. So far they haven't, and for a good reason -- such surveillance is far too uncommon and inconsequential to actually be noticed. Of course, if encrypted communications become dirt cheap and are properly spun in the media, people will take on -- negligible cost combined with a serious threat thwarted is a sure sell. This would be good, too, since the risks of insecure communication tend to be sizable and also materialize rarely -- those are precisely the circumstances in which people suffer from the worst errors of judgment. But at the present, I think the costs of real security seriously outweight the benefit, for most people. That might change as much as a result of what people themselves do/think, as as a result of what the Man, the Hacker or the technologically sophisticated Neighbour does. Until such a change, crypto is, sadly, a fringe thing. No matter how it's used.
You can imagine either rogue cops and spies doing this, or private criminals.
Or just your neighbour. I mean, it doesn't take a cop, or a spy, or even a an immoral person to listen in on you. All it takes is a little curiosity. There's plenty of that going around.
I keep wondering how hard it would be to build a cordless phone system on top of 802.11b with some kind of decent encryption being used.
From what I can tell from my knowledge of the DSP and crypto circuits, a couple of months of full-time effort. In no case more than half a year at full steam.
The question is, who has a) the time, and b) the energy? Few do.
I'd really like to be able to move from a digital spread spectrum cordless phone (which probably has a 16-bit key for the spreading sequence or some such depressing thing) to a phone that can't be eavesdropped on without tapping the wire.
If it's feasible to encrypt the phone-to-base station link, it's equally feasible to encrypt end-to-end. It's also cheap enough to do what PGP et al. do, that is, combine public key methods with symmetric ones to achieve both efficiency in in-band operation and convenience with key distribution. Thus, there's no need to distinguish E2E encryption from the rest, even in mobile, low-power equipment. If you need security, you might as well do it right.
And for cellphones, I keep thinking we need a way to sell a secure cellphone service that doesn't involve trying to make huge changes to the infrastructure, which probably means a call center that handles all contact with the cellphone itself, always encrypted.
Try GSM's data features. They have extra error correction, true, and so lower rates than the primary voice codec, but combined with the kinds of high end voice codecs as the GSM halfband one, you can fit perfectly usable speech within the data standard. After that, you don't even have to worry about modulation -- you can just send bits. Fitting strong crypto into that is ridiculously easy, and also relatively cheap.
End-to-end encryption isn't nearly as important.
Huh? Bare on-the-air encryption only proofs you against nosy neighbours and the attendant probability of one of them giving you in for something illegal. Those probabilities are quite low, compared to what "someone with something to hide" would fear from law enforcement. E2E protects you against both the threats, at little, no, or negative extra cost -- if your chosen mobile standard permits access to a variant of the basic digital interface, you can design you own protocol, usually with no more than half the bitrate lost to FEC. Better voice codecs tend to be able to deal with that, as witnessed by GSM's half rate codec. Consequently E2E's a pure win compared to trusting your mobile provider. But it also needn't be more expensive. In fact it's likely that in digital incarnations of the mobile phone system, E2E's actually cheaper than the alternative protocol change, provided the standard permits access to some variant of the basic, digital interface. If you can send numbers, crypto is easy to add on, it's not too difficult to add a proper, low-rate voice codec, and so you have both intelligible voice and industrial strength security. -- Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
Sampo Syreeni wrote:
Rather it's the fact that the Big Brother doesn't have the necessary total funds, and so doesn't listen into a considerable proportion of calls as a whole.
Yet. As far as we know. :-) I agree it's an economic issue, and law enforcement doesn't seem to listen in on a considerable proportion of calls as a whole at the moment. But what happens to costs in the future? Remember, it takes 10 years to get any change to the cellphone/telecommunications infrastructure deployed, so it pays to think ahead. By the way, what's the story with those SIGINT planes supposedly advertised as being able to fly over a city and capture communications from the whole metropolitan area? John Young had a pointer on his web site at one point. Do you suppose they might snarf up all the cellphone traffic they can find, en masse? What proportion of calls would that be, as a fraction of the whole? One wonders whether your confidence in the security of cellphone traffic is well-founded.
On Tuesday, June 3, 2003, at 09:10 PM, David Wagner wrote:
Sampo Syreeni wrote:
Rather it's the fact that the Big Brother doesn't have the necessary total funds, and so doesn't listen into a considerable proportion of calls as a whole.
Yet.
As far as we know.
:-)
I agree it's an economic issue, and law enforcement doesn't seem to listen in on a considerable proportion of calls as a whole at the moment. But what happens to costs in the future? Remember, it takes 10 years to get any change to the cellphone/telecommunications infrastructure deployed, so it pays to think ahead.
By the way, what's the story with those SIGINT planes supposedly advertised as being able to fly over a city and capture communications from the whole metropolitan area? John Young had a pointer on his web site at one point. Do you suppose they might snarf up all the cellphone traffic they can find, en masse? What proportion of calls would that be, as a fraction of the whole? One wonders whether your confidence in the security of cellphone traffic is well-founded.
AWACS-type planes have long had the ability to act as "cell towers," so cell traffic is easily picked-up, if in fact they are doing this. Landline signals are vastly harder to pick up, and I doubt strongly that every minorly-radiating landline signal is being picked up. Perhaps for very, very targetted signals, but not cruising over general cities, it seems likely to me. I'm not sure of the context here, but in the past year there were some reports of planes circling over university campuses, and many were hypothesizing that SIGINT was being done on telephone and computer messages. This seemed unlikely to me. I concluded--and posted on Usenet about my thinking--that some campuses may have been targeted for low-level gamma ray surveys. Kind of a gamma ray version of Shipley's "war driving" maps. Possibly for construction of baseline maps of existing radioisotopes in university labs, hospitals, and private facilities. Then deviations from baseline maps could be identified and inspected in more detail with ground-based vans and black bag ops.
--Tim May "That the said Constitution shall never be construed to authorize Congress to infringe the just liberty of the press or the rights of conscience; or to prevent the people of the United States who are peaceable citizens from keeping their own arms." --Samuel Adams
Sampo Syreeni wrote:
But anything that goes over the air, whether cellphone or cordless phone, ought to be properly encrypted, and it isn't now.
Why? As I see it, this is fundamentally an economic question, not a technical one. It's about the risk of somebody listening in, taking notice and acting adversely to the talker's own interest, versus speaking what one wants without having to take expensive precautions. Currently such risks mostly materialize when one *truly* has something to hide, that is, one talks about something criminal, there is reason to believe law enforcement agencies might be listening and one talks in terms which will reasonably lead to conviction in the right circumstances.
Getting back to the world of users, there is a threat out there: idle listeners. For the famous and the vulnerable, there have been countless scandals whereby private conversations have been recorded and dumped on a shocked and titillated public. GSM stopped that one cold. It wasn't ever meant to be encrypted to stop LEOs listening in, and that never would have been an issue anyway, as taps are more conveniently put at the base station (assuming legal behaviour by LEOs). (And, we can pretty much assume that the encryption wouldn't be allowed any further than the basestation ... in fact, I'm given to understand that there is a reason that the microwave links were never encrypted ;-) What was a real issue was that people who had something to hide wouldn't use the phone. And, those people with something to hide, *wanted* to use the phone. It was actually economically sensible to give all those scandalising lovers secure phones so they could romance away the hours safely, because the charging was per-minute. The other issue was phone spoofing, which was a massive industry in Europe with the older analog devices. Again, the crypto in GSM phones killed that little loss leader.
End-to-end encryption isn't nearly as important.
Huh? Bare on-the-air encryption only proofs you against nosy neighbours and the attendant probability of one of them giving you in for something illegal.
I'm guessing here that neither civil litigation nor Murdoch papers are much seen in Finland :-) -- iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
On Tue, Jun 03, 2003 at 10:42:01AM -0400, John Kelsey wrote:
At 10:09 AM 6/2/03 -0400, Ian Grigg wrote: ...
(One doesn't hear much about crypto phones these days. Was this really a need?)
Yes, I believe there is a need. In my view, there are two factors in the way of wide spread adoption: cost and ease of use. Having spent many years messing with these things, I've come to the conclusion that what I personally want is a cell phone that implements good end-to-end crypto. This way, I've always got my secure communication device with me, there's no "bag on the side", and it can be made almost completely transparent.
And for cellphones, I keep thinking we need a way to sell a secure cellphone service that doesn't involve trying to make huge changes to the infrastructure, ...
Agreed. Given a suitably powerful enough Java or whatever equipped cell phone / pda and an API that provides access to a data pipe and the speaker and mic, you can do this without any cooperation from the folks in the middle. I think that this platform will be common within a couple of years. The Xscale / StrongARM platform certainly has enough mips to handle both the vocoding and the crypto. Also on the horizon are advances in software radio that will enable the creation of ad hoc self organizing networks with no centralized control. There is a diverse collection of people supporting this revolution in wireless communications. They range from technologists, to economists, lawyers, and policy wonks. For background on spectrum policy issues see http://www.reed.com/openspectrum, http://cyberlaw.stanford.edu/spectrum or http://www.law.nyu.edu/benklery Free software for building software radios can be found at the GNU Radio web site http://www.gnu.org/software/gnuradio Eric --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
At 01:25 PM 6/3/03 -0700, Eric Blossom wrote: ...
Having spent many years messing with these things, I've come to the conclusion that what I personally want is a cell phone that implements good end-to-end crypto. This way, I've always got my secure communication device with me, there's no "bag on the side", and it can be made almost completely transparent.
I agree end-to-end encryption is worthwhile if it's available, but even when someone's calling my cellphone from a normal landline phone, I'd like it if at least the over-the-air part of the call was encrypted. That's a much bigger vulnerability than someone tapping the call at the base station or at the phone company. Otherwise, encrypted phone calls with the secure cellphone start looking a lot like encrypted e-mail with PGP--I have PGP, so do a few other people, but most people I want to talk to don't have it installed, and so most of my calls remain in the clear. This includes phone calls to my doctor, mother, priest, shrink, sister, lawyer, best friend, wife, bank, accountant, etc., e.g., all the calls I probably really wanted secured, and which will basically never be secured end-to-end if this requires each of those people to buy a special new phone, or do some tinkering with configuring secure phone software for their PDA. "Hmmm, which key size do I need? Is 1024 bits long enough? Why do I have to move the mouse around, again, anyway?" For essentially all of these, just getting to where I can use a cordless or cell phone on these calls without feeling like I'm broadcasting my private conversations in the clear would be great. Securing the other end is even better, but I'd like to do the part I can do now, not when the world finally realizes that unencrypted wireless stuff is a gaping privacy hole. ...
And for cellphones, I keep thinking we need a way to sell a secure cellphone service that doesn't involve trying to make huge changes to the infrastructure, ...
Agreed. Given a suitably powerful enough Java or whatever equipped cell phone / pda and an API that provides access to a data pipe and the speaker and mic, you can do this without any cooperation from the folks in the middle. I think that this platform will be common within a couple of years. The Xscale / StrongARM platform certainly has enough mips to handle both the vocoding and the crypto.
Yep. I have this mental picture of downloading some software for my PDA/cellphone, and buying a $200 box for my home, and getting a secure cordless phone when I'm in range, and a secure cellphone when I'm not, maybe with a secure voicemail system thrown in for good measure. It seems like most of this is off-the-shelf technology (wireless networking, a box connected to two landlines, some minimal encryption and key management software, etc.). When you ask for a secure call, your cellphone calls the box in your house (over an encrypted link), and it makes the rest of the call. Similarly, when someone calls your secure phone line number, it rings at the box, and then gets forwarded over the encrypted link to your cellphone. If two boxes like this call each other, they do end-to-end encryption. But the over-the-air stuff always gets encrypted. It sure seems like this would be worth putting up with a little delay in the call setup. (But maybe there's some reason this won't work.)
Eric
--John Kelsey, kelsey.j@ix.netcom.com PGP: FA48 3237 9AD5 30AC EEDD BBC8 2A80 6948 4CAA F259
On Tue, Jun 03, 2003 at 06:17:12PM -0400, John Kelsey wrote:
At 01:25 PM 6/3/03 -0700, Eric Blossom wrote: ...
I agree end-to-end encryption is worthwhile if it's available, but even when someone's calling my cellphone from a normal landline phone, I'd like it if at least the over-the-air part of the call was encrypted. That's a much bigger vulnerability than someone tapping the call at the base station or at the phone company.
GSM and CDMA phones come with the crypto enabled. The crypto's good enough to keep out your neighbor (unless he's one of us) but if you're that paranoid, you should opt for the end-to-end solution. The CDMA stuff (IS-95) is pretty broken: *linear* crypto function, takes 1 second worst case to gather data sufficient to solve 42 equations in 42 unknowns, but again, what's your threat model? Big brother and company are going to get you at the base station... At our house we've pretty much given up on wired phone lines. We use cell phones as our primary means of communication. Turns out that with the bundled roaming and long distance, it works out cheaper than what we used to pay for long distance service. There is that pesky location transponder problem though.
...which will basically never be secured end-to-end if this requires each of those people to buy a special new phone, or do some tinkering with configuring secure phone software for their PDA. "Hmmm, which key size do I need? Is 1024 bits long enough? Why do I have to move the mouse around, again, anyway?"
It doesn't have to be hard. No requirement for PKI. Just start with an unauthenticated 2k-bit Diffie-Hellman and be done with it. Eric --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
At 03:50 PM 6/3/03 -0700, Eric Blossom wrote: ...
GSM and CDMA phones come with the crypto enabled. The crypto's good enough to keep out your neighbor (unless he's one of us) but if you're that paranoid, you should opt for the end-to-end solution. The CDMA stuff (IS-95) is pretty broken: *linear* crypto function, takes 1 second worst case to gather data sufficient to solve 42 equations in 42 unknowns, but again, what's your threat model? Big brother and company are going to get you at the base station...
Big brother has a limited budget, just like the rest of us. If he has to produce a warrant or tap a wire somewhere to listen in on me, he probably won't bother. The only thing protecting my cellphone calls right now is trivially-broken encryption, the need for some moderately expensive equipment, and some laws prohibiting cellphone eavesdropping. That means that some bad guys may be eavesdropping now, and there's no telling how many bad guys will be doing so tomorrow. Nobody here knows how much eavesdropping is being done, because communications intercepts can be done without leaving any record anywhere. Do the police in some cities troll for interesting cellphone calls? Does the NSA do that in the US, quietly? Do Russian or French intelligence agencies? How would we know? So, what can I do about it, as an individual? Make the cellphone companies build good crypto into their systems? Any ideas how to do that? The only way I can see getting decent security on my cellphone is to do something that doesn't require the rest of the world's permission or assistance. The simplest version of that is to have a box at my house that's connected to two phone lines, and have all calls to and from my cellphone go through that box. Calls to other secure cellphones can be encrypted end-to-end. Calls to everyone else get encrypted between my phone and my box at home. I spend a little extra for extra security, nobody else has to pay anything, and I can call friends on my cellphone without being susceptible to trivial eavesdropping. Can the bad guys defeat this? Sure, they can tap my landline, or bug my car, or do all sorts of other things. But none of those are cheap enough to do to everyone, and probably none are cheap enough to do to me. Tapping my landline either means interacting with the phone company, or paying someone to go install a tap, each of which implies a risk of getting caught, practical limits on how often it can be done, etc. This also bypasses the "network effect" of encrypting phones, where you get approximately zero benefit from having one until they're widespread. I have an old Comsec 3DES phone at home. It's nice technology. I think I've used it twice. If you're not a cryptographer or a cocaine smuggler, you probably don't know anyone who owns an encrypting phone or would particularly want to. Even if you'd like to improve your own privacy, you can't buy an end-to-end encrypting phone and improve it much. That's what I'd like to see change. ...
Eric
--John Kelsey, kelsey.j@ix.netcom.com PGP: FA48 3237 9AD5 30AC EEDD BBC8 2A80 6948 4CAA F259 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
On Wed, Jun 04, 2003 at 07:15:13PM -0400, John Kelsey wrote: | At 03:50 PM 6/3/03 -0700, Eric Blossom wrote: | ... | >GSM and CDMA phones come with the crypto enabled. The crypto's good | >enough to keep out your neighbor (unless he's one of us) but if you're | >that paranoid, you should opt for the end-to-end solution. The CDMA | >stuff (IS-95) is pretty broken: *linear* crypto function, takes 1 | >second worst case to gather data sufficient to solve 42 equations in | >42 unknowns, but again, what's your threat model? Big brother and | >company are going to get you at the base station... | | Big brother has a limited budget, just like the rest of us. If he has to | produce a warrant or tap a wire somewhere to listen in on me, he probably | won't bother. | | The only thing protecting my cellphone calls right now is trivially-broken | encryption, the need for some moderately expensive equipment, and some laws | prohibiting cellphone eavesdropping. That means that some bad guys may be | eavesdropping now, and there's no telling how many bad guys will be doing | so tomorrow. Nobody here knows how much eavesdropping is being done, More bad guys will be listening tomorow, because SDR and Moore's law will drive down the cost. At some point, we'll hit a knee in the curve, and cell phones will be either made more secure, or we'll live with the fact that all our calls are being listened to, much like the Brits are always on video. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume
John Kelsey wrote:
So, what can I do about it, as an individual? Make the cellphone companies build good crypto into their systems? Any ideas how to do that?
Nope. Cellphone companies are big slow moving targets. They get their franchise from the government. If the NSA wants weak crypto, they do weak crypto. There is literally no point in hoping the cell phone company - or any large franchise holder - will help you in your fight against big brother. OTOH, what you can do is argue for reasonable crypto. (Similar to GSM's. That is hard to attack, there is AFAIR no 'trival' attack, you have to get access to the SIM or you have to probe the phone with another phone over a period of hours. I.e., the attacker leaves tracks, and he does so in a way that will move him on to another mode of tapping, such as purchasing a straight listening device.) Now, it seems that the US standards didn't get even that. There's definately a case for arguing for better crypto in the US. And, market forces and all that, one would think that this would happen in due course. But arguing for strong crypto end-to-end - save your breath. John Kelsey (paraphrased):
The only way I can see getting decent security [in any application] is to do something that doesn't require the rest of the world's permission or assistance.
(I edited the above to broaden the assert!) Opportunistic crypto - that which uses the tools immediately available and delivers crypto that is the best available right now - is the only crypto that will work for *you* the user in any application. Anything that defers security off to some external party has a result of slowing or killing the application, or delivering less or no security than if you'd gone ahead in the first place. This isn't saying anything new. It's the Internet, after all. On the Internet, one doesn't ask for permission to participate. That's no accident, it's a core reason for its arisal. Any protocol that has a step of "now ask for permission" is, IMHO, breaking one of the major principles of the Internet.
... I have an old Comsec 3DES phone at home. It's nice technology. I think I've used it twice. If you're not a cryptographer or a cocaine smuggler, you probably don't know anyone who owns an encrypting phone or would particularly want to. Even if you'd like to improve your own privacy, you can't buy an end-to-end encrypting phone and improve it much. That's what I'd like to see change.
I guess there's no reason why you couldn't load up speakfreely on a custom Unix box with a flashed OS, put in the USB headset, and sell it as an end to end encrypting phone. The software's all free, a cheap machine is $300 at Walmart, some enterprising crypto guy could ship out a network appliance for $500. (Or, put it in a PDA that's got the right hooks?) Half the price of your old Comsec, wasn't it selling for $1000? -- iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
Ian Grigg wrote:
(Similar to GSM's. That is hard to attack, there is AFAIR no 'trival' attack, [...]
Just wait a little while. By the way, one can already buy fake base stations that mount man-in-the-middle attacks on GSM as a way to eavesdrop on GSM calls. It's off the shelf, but it costs ridiculous amounts of money.
Now, it seems that the US standards didn't get even that.
Right. The major barrier is the need for a digital scanner (which indeed is a major barrier against certain threat models, but not a barrier for other threat models).
And, market forces and all that, one would think that this would happen in due course.
I'm less optimistic. Market forces being what they are, one would expect that one would quickly get cellphones that are *claimed* and *perceived* to be more secure, regardless of their true merits or demerits. Oh wait, that already happened.
I thought the 3G (UMTS) cellphones at least were going to use reasonably good crypto; don't know about the overall security architecture though. Jaap-Henk On Fri, 06 Jun 2003 14:30:04 -0400 Ian Grigg <iang@systemics.com> writes:
John Kelsey wrote:
So, what can I do about it, as an individual? Make the cellphone companies build good crypto into their systems? Any ideas how to do that?
Nope. Cellphone companies are big slow moving targets. They get their franchise from the government. If the NSA wants weak crypto, they do weak crypto.
-- Jaap-Henk Hoepman | I've got sunshine in my pockets Dept. of Computer Science | Brought it back to spray the day University of Nijmegen | Gry "Rocket" (w) www.cs.kun.nl/~jhh | (m) jhh@cs.kun.nl (t) +31 24 36 52710/531532 | (f) +31 24 3653137 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
On Tue, Jun 03, 2003 at 06:17:12PM -0400, John Kelsey wrote:
At 01:25 PM 6/3/03 -0700, Eric Blossom wrote: ...
I agree end-to-end encryption is worthwhile if it's available, but even when someone's calling my cellphone from a normal landline phone, I'd like it if at least the over-the-air part of the call was encrypted. That's a much bigger vulnerability than someone tapping the call at the base station or at the phone company.
GSM and CDMA phones come with the crypto enabled. The crypto's good enough to keep out your neighbor (unless he's one of us) but if you're that paranoid, you should opt for the end-to-end solution. The CDMA stuff (IS-95) is pretty broken: *linear* crypto function, takes 1 second worst case to gather data sufficient to solve 42 equations in 42 unknowns, but again, what's your threat model? Big brother and company are going to get you at the base station... At our house we've pretty much given up on wired phone lines. We use cell phones as our primary means of communication. Turns out that with the bundled roaming and long distance, it works out cheaper than what we used to pay for long distance service. There is that pesky location transponder problem though.
...which will basically never be secured end-to-end if this requires each of those people to buy a special new phone, or do some tinkering with configuring secure phone software for their PDA. "Hmmm, which key size do I need? Is 1024 bits long enough? Why do I have to move the mouse around, again, anyway?"
It doesn't have to be hard. No requirement for PKI. Just start with an unauthenticated 2k-bit Diffie-Hellman and be done with it. Eric ----- End forwarded message -----
On Tue, Jun 03, 2003 at 06:17:12PM -0400, John Kelsey wrote:
At 01:25 PM 6/3/03 -0700, Eric Blossom wrote: ...
I agree end-to-end encryption is worthwhile if it's available, but even when someone's calling my cellphone from a normal landline phone, I'd like it if at least the over-the-air part of the call was encrypted. That's a much bigger vulnerability than someone tapping the call at the base station or at the phone company.
GSM and CDMA phones come with the crypto enabled. The crypto's good enough to keep out your neighbor (unless he's one of us) but if you're that paranoid, you should opt for the end-to-end solution. The CDMA stuff (IS-95) is pretty broken: *linear* crypto function, takes 1 second worst case to gather data sufficient to solve 42 equations in 42 unknowns, but again, what's your threat model? Big brother and company are going to get you at the base station... At our house we've pretty much given up on wired phone lines. We use cell phones as our primary means of communication. Turns out that with the bundled roaming and long distance, it works out cheaper than what we used to pay for long distance service. There is that pesky location transponder problem though.
...which will basically never be secured end-to-end if this requires each of those people to buy a special new phone, or do some tinkering with configuring secure phone software for their PDA. "Hmmm, which key size do I need? Is 1024 bits long enough? Why do I have to move the mouse around, again, anyway?"
It doesn't have to be hard. No requirement for PKI. Just start with an unauthenticated 2k-bit Diffie-Hellman and be done with it. Eric ----- End forwarded message -----
On Tue, Jun 03, 2003 at 10:42:01AM -0400, John Kelsey wrote:
At 10:09 AM 6/2/03 -0400, Ian Grigg wrote: ...
(One doesn't hear much about crypto phones these days. Was this really a need?)
Yes, I believe there is a need. In my view, there are two factors in the way of wide spread adoption: cost and ease of use. Having spent many years messing with these things, I've come to the conclusion that what I personally want is a cell phone that implements good end-to-end crypto. This way, I've always got my secure communication device with me, there's no "bag on the side", and it can be made almost completely transparent.
And for cellphones, I keep thinking we need a way to sell a secure cellphone service that doesn't involve trying to make huge changes to the infrastructure, ...
Agreed. Given a suitably powerful enough Java or whatever equipped cell phone / pda and an API that provides access to a data pipe and the speaker and mic, you can do this without any cooperation from the folks in the middle. I think that this platform will be common within a couple of years. The Xscale / StrongARM platform certainly has enough mips to handle both the vocoding and the crypto. Also on the horizon are advances in software radio that will enable the creation of ad hoc self organizing networks with no centralized control. There is a diverse collection of people supporting this revolution in wireless communications. They range from technologists, to economists, lawyers, and policy wonks. For background on spectrum policy issues see http://www.reed.com/openspectrum, http://cyberlaw.stanford.edu/spectrum or http://www.law.nyu.edu/benklery Free software for building software radios can be found at the GNU Radio web site http://www.gnu.org/software/gnuradio Eric ----- End forwarded message -----
On Tue, Jun 03, 2003 at 10:42:01AM -0400, John Kelsey wrote:
At 10:09 AM 6/2/03 -0400, Ian Grigg wrote: ...
(One doesn't hear much about crypto phones these days. Was this really a need?)
Yes, I believe there is a need. In my view, there are two factors in the way of wide spread adoption: cost and ease of use. Having spent many years messing with these things, I've come to the conclusion that what I personally want is a cell phone that implements good end-to-end crypto. This way, I've always got my secure communication device with me, there's no "bag on the side", and it can be made almost completely transparent.
And for cellphones, I keep thinking we need a way to sell a secure cellphone service that doesn't involve trying to make huge changes to the infrastructure, ...
Agreed. Given a suitably powerful enough Java or whatever equipped cell phone / pda and an API that provides access to a data pipe and the speaker and mic, you can do this without any cooperation from the folks in the middle. I think that this platform will be common within a couple of years. The Xscale / StrongARM platform certainly has enough mips to handle both the vocoding and the crypto. Also on the horizon are advances in software radio that will enable the creation of ad hoc self organizing networks with no centralized control. There is a diverse collection of people supporting this revolution in wireless communications. They range from technologists, to economists, lawyers, and policy wonks. For background on spectrum policy issues see http://www.reed.com/openspectrum, http://cyberlaw.stanford.edu/spectrum or http://www.law.nyu.edu/benklery Free software for building software radios can be found at the GNU Radio web site http://www.gnu.org/software/gnuradio Eric ----- End forwarded message -----
On Tue, 3 Jun 2003, John Kelsey wrote:
Date: Tue, 03 Jun 2003 10:42:01 -0400 From: John Kelsey <kelsey.j@ix.netcom.com> Subject: Re: Maybe It's Snake Oil All the Way Down
...
I keep wondering how hard it would be to build a cordless phone system on top of 802.11b with some kind of decent encryption being used. I'd really like to be able to move from a digital spread spectrum cordless phone (which probably has a 16-bit key for the spreading sequence or some such depressing thing) to a phone that can't be eavesdropped on without tapping the wire.
See http://www.silicon.com/news/148/1/3828.html?source=nh
...
--John Kelsey, kelsey.j@ix.netcom.com PGP: FA48 3237 9AD5 30AC EEDD BBC8 2A80 6948 4CAA F259
Thanks, Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com
At 10:09 AM 6/2/03 -0400, Ian Grigg wrote:
(One doesn't hear much about crypto phones these days. Was this really a need?) As a minor aside - most laptops can manage pgpfone using only onboard hardware these days, either using an integrated modem or (via infrared) a mobile phone.....
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
participants (26)
-
Adam Shostack -
Anne & Lynn Wheeler -
Bill Frantz -
Bill Stewart -
Dave Howe -
daw＠mozart.cs.berkeley.edu -
Donald Eastlake 3rd -
Eric Blossom -
Eric Murray -
Eric Rescorla -
Eric Young -
Frederick Hirsch -
Ian Grigg -
Jaap-Henk Hoepman -
James A. Donald -
Jamie Lawrence -
Jeroen C. van Gelderen -
Jeroen van Gelderen
-
John Kelsey -
John Young -
Lucky Green -
Rich Salz -
Sampo Syreeni -
Scott Guthery -
Sunder -
Tim May