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