Re: PGP Encryption Proves Powerful
At 11:38 AM 05/30/2003 -0700, John Young wrote: If the FBI cannot crack PGP that does not mean other agencies with greater prowess cannot. It is unlikely that the capability to crack PGP would be publicly revealed for that would close an invaluable source of information. . Still, it is impressive that PRZ valiantly argues that PGP is algorithmically impregnable. That should satisfy its users as well as its crackers. And Phil was quoted as saying Does PGP have a back door? The answer is no, it does not, he said. If the device is running PGP it will not be possible to break it with cryptanalysis alone. But in fact that's incorrect. PGP doesn't have back doors, but it has two major weaknesses, which are weak user-chosen passphrases, combined with a secret key file format that makes it easy to verify whether a key has been guessed correctly, and human-rememberable passphrases, combined with rubber-hose cryptanalysis and a captured agent. If you're doing good operational security, and the Red Brigades probably are, your passphrases have good enough entropy that they're hard to crack, but if they got sloppy, and someone wants to feed all the information that's known about them to pgpcrack, it's possible that they'll find something. It's less likely than VENONA succeeding, because the importance of good passphrases was known, and unlike one-time pads there's no operational need to occasionally get sloppy under time pressure. I'm not aware of a PGP port to the Psion, but at least the Psion 3/3a/3c generation were 8086-like processors, and there was a C compiler ported to them, so perhaps somebody ported one of the earlier PGPs. (There was an old HP palmtop that ran genuine MS-DOS, unlike the Psion's more interesting operating system, and you could probably run PGP on that directly.) - 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: New vs Old (was Snake Oil)
On Tue, 3 Jun 2003 [EMAIL PROTECTED] wrote: I confess to being confused - though admittedly part of the blame for this is my own ignorance. I remember a time when PGP was a command line application. The only algorithms it used were IDEA (symmetric), RSA (assymetric) and MD5 (hash). I came to trust these algorithms. Now these once-'standard' algorithms are no longer encouraged. The new versions of PGP seem to prefer CAST instead of IDEA, DH/DSS instead of RSA, and SHA-1 instead of MD5. So, could someone please tell me: (1) What is the justification for using these new algorithms instead of the old ones? (A cynic might suggest that, since the powers that be couldn't break the old algorithms, they encouraged the use of new ones that they could. This probably isn't true, but I'm sure you can understand why someone might think that). Well - Hans Dobbertin found hash collisions in MD5 and while I haven't heard much more, that's a toehold that somebody might be able to use to break it, and makes it vulnerable in some applications. SHA-1 is now considered better. IDEA is still a good cipher as far as I know, but PGP has been driven away from it in the US due to intellectual-property issues. Rather than continue with incompatible versions for use inside/outside the USA, they're switching to CAST (although this is causing more, rather than less, version incompatibilities). RSA is still good, as far as I know, and has been in the public domain worldwide since September 2001. But it had the same kind of IP issues as IDEA until that point, and several versions of PGP had to be produced that used a different asymmetric cipher for that reason. I don't know enough about DH/DSS specifically to comment further on its relative security, but RSA has had several scares and people are concerned that custom hardware (such as a million-qubit quantum computing device or Bernstein's matrix hardware factoring device) might cause insecurity in RSA _and_ be possible for someone to keep secret. And lots of people quit using RSA because they don't like the big block of key that it requires. (2) What actually _IS_ DH/DSS? (I don't mean what do the initials it stand for, I mean what actually is the algorithm?). I ask because I can understand RSA, and implement it myself relatively straightforwardly, but I have not been able to find an explanation, simple or otherwise, of what the DH/DSS algorithm actually is, or of why it's hard to break. (3) Ditto CAST and SHA-1. for a good complete description of SHA-1 and a few others, try http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf (warning: link may be outdated). I don't have pointers to the other two offhand. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PGP Encryption Proves Powerful
At 08:17 AM 06/03/2003 -0700, bear wrote: what he said was with cryptanalysis alone. Rubber-hose methods are not cryptanalysis, and neither is password guessing. Eh? Password guessing certainly is. I'm not aware of a PGP port to the Psion, but at least the Psion 3/3a/3c generation were 8086-like processors, and there was a C compiler ported to them, so perhaps somebody ported one of the earlier PGPs. IIRC, there was/is a psion linux port, with gcc. Looks like it's still in active development, mainly for the Psion 5 series - they've even got X Windows running on them, as well as PGP. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Maybe It's Snake Oil All the Way Down
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. [EMAIL PROTECTED] | American way. | Los Gatos, CA 95032, USA - 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: Nullsoft's WASTE communication system
The AP wire reports that the founder of Nullsoft, Justin Frankel, plans to resign in the wake of WASTE being pulled. http://www.nytimes.com/aponline/technology/AP-AOL-Nullsoft.html --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New vs Old (was Snake Oil)
At 08:53 AM 06/03/2003 -0700, bear wrote: IDEA is still a good cipher as far as I know, but PGP has been driven away from it in the US due to intellectual-property issues. Rather than continue with incompatible versions for use inside/outside the USA, they're switching to CAST (although this is causing more, rather than less, version incompatibilities). Actually, they switched to letting the user choose algorithms, with CAST as the default but others such as 3DES available. One of the compatibility issues is that people have written patches for GPG that implement IDEA, so some users' systems support it and others don't. On the other hand, that mainly bothers the people who've picked only accept IDEA for their symmetric algorithms. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
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
On Tue, Jun 03, 2003 at 03:04:54PM -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? [ Resend to cryptography@ only coz the earlier attempt failed. ] Start by looking up the OpenSSL wrappers for your favourite high-level scripting language. There exists wrappers for Perl, Python, tcl, Ruby, etc. Some popular languages have several. Many of these programming language environments come with HTTP server implementations, and many of the OpenSSL wrappers hook into said HTTP server code to add HTTPS, and a number demonstrate how to do client-side certificates. My M2Crypto adds HTTPS to the popular web application server Zope (www.zope.org) and has some code to hook client-side certificates into Zope's own user authentication machinery. (By faking HTTP basic authentication, just like Apache's SSL do.) Once you have that, you can choose to serve whatever content you want. 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.. It seems HMAC'ing cookies are getting popular for this purpose. OpenACS, another popular web application server uses this: http://openacs.org/doc/openacs-4/security-design.html My Python crypto kit has an implementation of the scheme described here: http://www.pdos.lcs.mit.edu/cookies/pubs/webauth.html I'll be interested to hear this list's view on such schemes. From my app-plumber's perspective, such a technique for is good enough provided it is 'secure' enough. People understand passwords. Private keys, certificates, smart cards, etc., are more difficult. (I recall a paper on PGP UI useability testing called Why Johnny cannot encrypt or something like that.) 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? Actually, this is the crypto-wielding-open-source-hacker-wannabe's wet dream: So what you need now to track (or generate strong) passwords is a GUI password safe! (Like the one offered on (the old?) Counterpane site.) Again, Perl, Python, Ruby, yada yada, you name it, people are going to implement them for free. ;-) Especially since there are usually 3-5 GUI toolkits and 2-4 database toolkits for these language environments. Enough combinations to suit everyone. -- Ng Pheng Siong [EMAIL PROTECTED] http://firewall.rulemaker.net -+- Manage Your Firewall Rulebase Changes http://www.post1.com/home/ngps -+- Open Source Python Crypto SSL --94BE45B7.1054694140/vista.netmemetic.com-- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Maybe It's Snake Oil All the Way Down
-- On 3 Jun 2003 at 15:04, 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? Or to say the same thing in different words -- why can't HTTPS be more like SSH?Why are we seeing a snow storm of scam mails trying to get us to login to e-g0ld.com? --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG QtiFX0Q654gHh54NAMlLGE1FGDveixyzL0ZnAOVS 4hprBkT1zeYk/HdBOXiquwvz5vLUwF/21wW1Jf411 - 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
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. - 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 [EMAIL PROTECTED] writes: 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? There's a two-level answer to this problem. At an abstract level, doing client certs isn't hard, there are various HOWTOs around for Apache, Microsoft have Technet/MSDN papers on it for IIS, etc etc. At a practical level, it's almost never used because it's just Too Hard. That's not the SSL client-cert part, it's the using-X.509 part. To save having to type in a long explanation, I'll lift a representative paragraph from a (not-yet-published, don't ask :-) paper on PKI usability: There is considerable evidence from mailing lists, Usenet newsgroups and web forums, and directly from the users themselves, that acquiring a certificate is the single biggest hurdle faced by users [1]. For example various user comments indicate that it takes a skilled technical user between 30 minutes and 4 hours work to obtain a certificate from a public CA that performs little to no verification, depending on the CA and the procedure being followed. Obtaining one from non-public CAs that carry out various levels of verification before issuing the certificate can take as long as a month. A representative non-technical user who tried to obtain an (unverified) certificate from a public CA took well over an hour for the process, which involved [...] eventually the user gave up. and that doesn't even get into the mess of managing private keys, handling revocation, etc etc etc ad nauseum: The problems that this creates are demonstrated by what happens when technically skilled users are required to work with certificates. The OpenSSL toolkit [2][3] includes a Perl script CA.pl that allows users to quickly generate so-called clown suit certificates (ones that 'have all the validity of a clown suit' when used for identification purposes [4]), which is widely-used in practice. The cryptlib toolkit [5][6] contains a similar feature in the form of Xyzzy certificates (added with some resistance and only after the author grew tired of endless requests for it), ones with dummy X.500 names, an effectively infinite lifetime, and no restrictions on usage. Most commercial toolkits include similar capabilities, usually disguised as 'test certificates' for development purposes only, which end up being deployed in live environments because it.s too difficult to do it the way X.509 says it should be done. Certificates used with mailers that support the STARTTLS option consist of ones that are 'self-signed, signed-by the default Snake Oil CA, signed by an unknown test CA, expired, or have the wrong DN' [7]. The producer of one widely-used Windows MUA reports that in their experience 90% of the STARTTLS-enabled servers that they encounter use self-signed certificates [8]. This reduces the overall security of the system to that of unauthenticated Diffie-Hellman key exchange, circa 1976. In all of these cases, the entire purpose of certificates has been completely short-circuited by users because it.s just too difficult to do the job properly. The problematic nature of X.509 is echoed in publications both technical and non-technical, with conference papers and product descriptions making a feature of the fact that their design or product works without requiring a PKI. For example, one recent review of email security gateways made a requirement for consideration in the review that the product 'have no reliance on PKI' [9]. As an extreme example of this, the inaugural PKI Research Workshop, attended by expert PKI users, required that submitters authenticate themselves with plaintext passwords because of the lack of a PKI to handle the task [10][11]. 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 assumption of the protocol's creators was that someone would figure out how to make X.509 PKI work by the time SSL took off, and everyone would have their own certificates and whatnot. At least they got *most* of the design right :-). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Microsoft Ties Security to VeriSign, Certifications
http://www.internetnews.com/ent-news/print.php/2216571 www.internetnews.com/ent-news/article.php/2216571 Back to Article Microsoft Ties Security to VeriSign, Certifications By Thor Olavsrud and Mark Berniker June 3, 2003 Microsoft ( Quote ,Company Info ) moved to bolster its code-securing effort called Trustworthy Computing Initiative by announcing two security initiatives Tuesday. Microsoft and VeriSign said they would jointly develop improved solutions for authentication security, digital rights management (DRM) and other online security enhancements. Financial terms of the deal were not disclosed. The new security products from Microsoft-VeriSign are aimed at achieving improvements in existing software, while providing automated renewal of digital certificates, secure e-mail and digital signatures. The alliance also plans to help improve network security with reliable access to wireless LANs or virtual private networks . The two partners also said they plan to help customers embed PKI (public key infrastructure) security into desktop and networked applications. Microsoft also announced the availability of a new security certification program for system administrators and systems engineers: MCSA: Security and MCSE: Security. These programs will give IT professionals training to improve enterprise security. By introducing these new certifications, we're supporting the Secure in Deployment tenet of the company's Trustworthy Computing Initiative, said Lutz Ziob, general manager for Microsoft's Training and Certification group. This tenet speaks to an organization's ability to apply recognized and established best practices around security, so that Microsoft products and technologies are rolled out in the most secure way possible. We've taken those best practices and developed prescriptive certification tracks to help IT professionals demonstrate their acumen in designing and implementing a secure computing environment. We've also included CompTIA's Security+ credential in these tracks to extend the certifications to include cross-platform skills as well. Microsoft is beginning to make real progress in Trustworthy Computing on behalf of our customers and partners, particularly in the way we think about, design and develop our products and services to be more secure, reliable and privacy-compliant from the start, Scott Charney, chief trustworthy computing strategist at Microsoft, said during his Tech Ed 2003 keynote in Dallas Tuesday. Although much work remains to be done, we are delivering tools and resources so customers and partners can successfully manage their networks for optimum security in deployment. Still, critics of Microsoft's security strategy have had a lot of fodder with the recent discovery of security holes in its Passport personal information storage service, which were later patched, and other questionable levels of security for critical applications for businesses, governments and individuals. But the Trustworthy Computing Initiative is trying to change that, and Charney, together with Nico Popp, vice president of product development in the Security Services Division at VeriSign ( Quote ,Company Info ), said new efforts will see the two partners developing several security initiatives for enterprise customers, including PKI auto enrollment of VeriSign certificates, interoperability of certificate authorities, and secure mobile access. The initiatives will be built on the Windows Server 2003 PKI platform. The pact is expected to improve upon existing security use of digital signatures for Microsoft's Windows Server 2003. Digital signatures provide some authentication security, but with the recent security problems associated with Microsoft's Passport product, the company is moving to improve security software within its products. The deal aims to provide improved online security, especially for remote access. The two companies will build the security solutions into not only Microsoft's Windows Server 2003, but also VeriSign's Managed PKI (public key infrastructure) Services. VeriSign specializes in making server software that is able to handle a large number of digital signatures, and is expected to launch a service later this year that will be closely tied to the new features inside Microsoft's Windows Server 2003. Improvements in digital signatures could be helpful in the exchange of contracts and proposals sent over networks. In addition, corporate partners could send documents that would include a digital rights management tag along with an e-mail, which would enhance document security for both parties. The two companies said they would market the new solutions to enterprise users aiming to provide secure online information and digital identity management systems. Developing reliable and secure PKI authentication systems has proven to be complicated and difficult, as many companies have been slow to install the servers and software to support the
