Re: Maybe It's Snake Oil All the Way Down
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 [EMAIL PROTECTED] 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) [EMAIL PROTECTED] (t) +31 24 36 52710/531532 | (f) +31 24 3653137 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Maybe It's Snake Oil All the Way Down
James A. Donald writes: 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. Why do you say that? You were already given pointers to how they could configure their web servers to use certificate based client authentication. These techniques work with standard browsers. I have used Netscape to access corporate-internal sites which required me to have a client certificate. 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. HTTPS is just HTTP over SSL/TLS. It says nothing about the trust model for the certificates; it merely specifies how each side can deliver its cert(s) to the other side. Deciding which ones to trust is out of scope for TLS or HTTPS. E-Gold could set things up to allow its customers to authenticate with certs issued by Verisign, or with considerably more work it could even issue certs itself that could be used for customer authentication. Why doesn't it do so? Well, it's a lot of work, and it would have some disadvantages - for one thing, customers would have difficulty accessing their accounts from multiple sites, like at home and at work. Further, it would require customers to use some features of their browser that most of them have never seen, which is going to be difficult and error-prone for most users. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Maybe It's Snake Oil All the Way Down
-- 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 [EMAIL PROTECTED]
RE: Maybe It's Snake Oil All the Way Down
Lucky Green [EMAIL PROTECTED] writes: 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. Naah, that third sentence is wrong. It's: The overwhelming majority of [SSL users] wouldn't know SSL from HTTP with a padlock GIF in the corner. 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 think the assertion was that SSH is used in places where it matters, while SSL is used where no-one really cares (or even knows) about it. Joe Sixpack will trust any site with a padlock GIF on the page. Most techies won't access a Unix box without SSH. Quantity != quality. If you could wave a magic wand and make one of the two protocols vanish, I'd notice the loss of SSH immediately (I couldn't send this message for starters), but it would take days or weeks before I noticed the loss of SSL. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Maybe It's Snake Oil All the Way Down
On Tue, 2003-06-03 at 07:04, Peter Gutmann wrote: That's a red herring. It happens to use X.509 as its preferred bit-bagging format for public keys, but that's about it. People use self-signed certs, certs from unknown CAs [0], etc etc, and you don't need certs at all if you don't need them, blatant self-promotionI've just done an RFC draft that uses shared secret keys for mutual authentication of client and server, with no need for certificates of any kind/blatant self-promotion, so the use of certs, and in particular a hierarchical PKI, is merely an optional extra. It's no more required in SSL than it is in SSHv2. the pk-init draft for kerberos allows public keys allowing both cert cert-less implementation blatant aads-promotion the scenario allows for public key registration in lieu of shared secret registration. the scenario is that r/o access, divulging, sniffing, etc doesn't result in compromise. in the token form http://www.garlic.com/~lynn/index.html#aadsstraw http://www.asuretee.com/ the key-pair is gen'ed in the chip and never leaves the chip. as part of 3-factor authentication * something you have * something you know * something you are the chip in the token purely provides something you have authentication ... and the digital signature done by the token is purely to prove that you have that particular token. It doesn't prove who you are, it just proves that you have a specific (extremely difficult to counterfeit) token as part of something you have authentication. if the token is augmented with a pin/password for its correct operation, then there can be 2-factor authentication. It doesn't involved shared-secrets since the pin/password is purely between the person and the hardware token. The business process validates that the token is of the type requiring PIN and/or biometric for correct operation. The ecdsa digital signature authentication protocol for kerberos, radius, x9.59 for all retail financial transactions, or ssh can be identical regardless of the integrity level. The ecdsa digital signature authentication protocol can be ubiquitous regardless of the authentication integrity level required. The business process to meet integrity requirements then can require sofware key-pair or hardware token key-pair, the level of integrity of the hardware token, and/or the operational characteristics of the hardware token (no-pin, pin, biometrics, etc) w/o changing the protocol. If the protocol is independent of the business process integrity issue then either the business and/or the end-user may be able to having personal choice about the level of integrity required. Furthermore, the person might even have personal choice whether they need a unique token per security environment, a single token for all security environment, and/or a small number of tokens selectively applied to different security environments the digital signature has nothing at all to do directly with the person, it is purely related to demonstrating the possession of the token (as part of something you have authentication) and possibly the integrity level of the token. The issue of the authentication protocol is getting the bits and bytes for transmission correct but doesn't normally say what it means ... i.e. secret, shared-secret, one factor authentication, two-factor authentication, something you have authentication, something you know authentication, etc. ... although frequently the protocol is envisioned to be a specific implementation of a specific kind of authentication and trust/integrity level. recent token discussions http://www.garlic.com/~lynn/2003i.html#1 Two-factor authentication with SSH? http://www.garlic.com/~lynn/2003i.html#2 Two-factor authentication with SSH? http://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation http://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation older token discussions http://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM] http://www.garlic.com/~lynn/aadsm7.htm#rhose12 when a fraud is a sale, Re: Rubber hose attack http://www.garlic.com/~lynn/aepay10.htm#65 eBay Customers Targetted by Credit Card Scam http://www.garlic.com/~lynn/2000f.html#65 Cryptogram Newsletter is off the wall? http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001g.html#1 distributed authentication http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure? http://www.garlic.com/~lynn/2001k.html#61 I-net banking security http://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security requested
Re: Maybe It's Snake Oil All the Way Down
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.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Maybe It's Snake Oil All the Way Down
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 [EMAIL PROTECTED]
Re: Maybe It's Snake Oil All the Way Down
At 03:04 PM 6/3/2003 -0700, James A. Donald wrote: I never figured out how to use a certificate to authenticate a client to a web server, how to make a web form available to one client and not another. Where do I start? What I and everyone else does is use a shared secret, a password stored on the server, whereby the otherwise anonymous client gets authenticated, then gets an ephemeral cookie identifying him.. I cannot seem to find any how-tos or examples for anything better, whether for IIS or apache. As a result we each have a large number of shared secret passwords, whereby we each log into a large number of webservers. Was this what the people who created this protocol intended? The issue is where does the authentication material come from. blatant aads promotion Basically, certificates were solution targeted for offline email from the early '80s. you dail-up, connect, exchange email, hang-up. then you read. some random person that you never, ever dealt with before sends you something. they claim to be somebody the certificate is signed by somebody you trust is offered as proof that they are who they claimed to be. the other approach in the online world /or with previous relations, is have a table of authentication material. the payment (debit/credit) card world went from non-electronic, offline to electronic and online (and skipped the step altogether that certificates represent ... the electornic and offline). note that even the certificate-based infrastructure are dependent on this method basically the certificate-enabled infrastructures have local table of CA public keys (i.e. those public keys that they've previously decided to trust) ... then certificates are validated with CA public keys and the current message/document is validate with public key from certificate. The primary difference between cert-based infrastructure and certless-based infrastructure is that the cert-based infrastructure there CAs have the database of all public keys and create these small R/O copies of their database records called certificates and spray them all over for use in offline environments. Then relying parties just have abbreviated CA-only public key tables and can't access the full tables maintained at the CAs. In the certless-based infrastructure the relying parties either maintain their own full tables of all public keys and/or have direct online access to the full tables. There is no need for these little R/O, static, stale, redundant and superfluous copies of somebody else offline database entry (called certificates) since there can be direct, online access to the original copy. generalized case can be hooking the web server to either radius or kerberos for handling the authentication process. both radius and kerberos support shared-secrets recorded in database as authentication. the radius example at http://www.asuretee.com/ shows example of radius recording public key in lieu of shared-secret and performing ecdsa digital signature authentication. pkinit for kerberos also allows for public key recorded in lieu of shared-secret and digital signature authentication. misc. radius public key authentication posts http://www.garlic.com/subpubkey.html#radius misc. kerberos public key authentication pots http://www.garlic.com/subpubkey.html#kerberos futher discussion specifically regarding static, stale, redundant, superfluous certificates. http://www.garlic.com/~lynn/subpubkey.html#rpo slightly related discussions regarding SSL merchant comfort certificates: http://www.garlic.com/~lynn/subpubkey.html#sslcerts /blatant aads promotion -- Anne Lynn Wheelerhttp://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 [EMAIL PROTECTED]
Re: Maybe It's Snake Oil All the Way Down
Tim Dierks wrote: At 09:11 AM 6/3/2003, Peter Gutmann wrote: Lucky Green [EMAIL PROTECTED] writes: 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 think the assertion was that SSH is used in places where it matters, while SSL is used where no-one really cares (or even knows) about it. Joe Sixpack will trust any site with a padlock GIF on the page. Most techies won't access a Unix box without SSH. Quantity != quality. I have my own opinion on what this assertion means. :-) I believe it intends to state that ssh is more successful because it is the only Internet crypto system which has captured a large share of its use base. This is probably true: I think the ratio of ssh to telnet is much higher than the ratio of https to http, pgp to unencrypted e-mail, or what have you. Certainly, in measureable terms, Tim's description is spot on. I agree with Peter's comments, but that's another issue indeed. However, I think SSL has been much more successful in general than SSH, if only because it's actually used as a transport layer building block rather than as a component of an application protocol. SSL is used for more Internet protocols than HTTP: it's the standardized way to secure POP, IMAP, SMTP, etc. It's also used by many databases and other application protocols. In addition, a large number of proprietary protocols and custom systems use SSL for security: I know that Certicom's SSL Plus product (which I originally wrote) is (or was) used to secure everything from submitting your taxes with TurboTax to slot machine jackpot notification protocols, to the tune of hundreds of customers. I'm sure that when you add in RSA's customers, those of other companies, and people using OpenSSL/SSLeay, you'll find that SSL is much more broadly used than ssh. Design wins! Yes, indeed, another way of measuring the success is to measure the design wins. Using this measure, SSL is indeed ahead. This probably also correlates with the wider support that SSL garners in the cryptography field. I'd guess that SSL is more broadly used, in a dollars-secured or data-secure metric, than any other Internet protocol. Most of these uses are not particularly visible to the consumer, or happen inside of enterprises. Of course, the big winners in the $-secured and data-secured categories are certainly systems inside of the financial industry and governmental systems. That would depend an awful lot on what was meant by dollars-secured and data-secured ? Sysadmins move some pretty hefty backups by SSH on a routine basis. -- iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Maybe It's Snake Oil All the Way Down
Erik is right: there must be very strong motivation to consider using a cryptographic mechanism/protocol which is not `standard` (de-facto standards are Ok). When this motivation is supposedly improved security, the new (supposedly more secure) primitive should preferably be composed with a supposedly-weaker but standard mechanism, in a `cryptanalysis-tolerant` manner, i.e. an attack should apply to _both_ mechanisms. But of course other motivations (e.g. performance) may rule out this approach. The basic security argument underlying computational cryptography is always the fact that it withstood cryptanalysis. Even when we provide `provable security`, what the proofs really show is only that the mechanism/protocol is as secure as some other assumption. The only exception is unconditional secure systems such as one-time pad, but these are usually not practical (e.g. due to key length requirements); in particular public key systems are always `only` computationally secure. This is not really a problem and certainly not a motivation to design new systems, without a proof of security... Best, Amir Herzberg http://amir.herzberg.name - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Maybe It's Snake Oil All the Way Down
Scott Guthery [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Maybe It's Snake Oil All the Way Down
Scott Guthery [EMAIL PROTECTED] writes: Suppose. Just suppose. That you figured out a factoring algorithm that was polynomial. What would you do? Would you post it immediately to cypherpunks?Well, OK, maybe you would but not everyone would. In fact some might even imagine they could turn a sou or two. And you can bet the buyer wouldn't be doing any posting. With apologies to Bon Ami, Hasn't cracked yet is not a compelling security story. It's vastly better than just designed last week by someone who has no relevant experience -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Maybe It's Snake Oil All the Way Down
The assumption that having cracked a cipher leads to can make lots of money from the break is one held mostly by those who have never attacked real systems, which have evolved with lots of checks and balances. The very best way to make money from cracking ciphers seems to be to patent the break, and the fixes, and then consult to those who use the cipher, because they need your expertise to fix their systems. P. may have a patent on this method. Adam On Sun, Jun 01, 2003 at 07:05:44PM -0400, Scott Guthery wrote: | Suppose. Just suppose. That you figured out a factoring | algorithm that was polynomial. What would you do? Would | you post it immediately to cypherpunks?Well, OK, maybe | you would but not everyone would. In fact some might | even imagine they could turn a sou or two. And you can | bet the buyer wouldn't be doing any posting. With apologies | to Bon Ami, Hasn't cracked yet is not a compelling security | story. | | Cheers, Scott | | -Original Message- | From: Rich Salz [mailto:[EMAIL PROTECTED] | Sent: Sun 6/1/2003 6:16 PM | To: Eric Rescorla | Cc: Scott Guthery; cypherpunks; [EMAIL PROTECTED] | Subject: Re: Maybe It's Snake Oil All the Way Down | | | |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 -- It is seldom that liberty of any kind is lost all at once. -Hume - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
