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

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

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

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.)

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.

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

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.

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

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 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

-- 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

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: 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 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

Ian Grigg 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/

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 -----

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

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.

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

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

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

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

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 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 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 -----

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