December 2003 - cypherpunks-legacy

Re: RFC: A UNIX crypt(3) replacement
by Joshua E. Hill 17 Dec '03

17 Dec '03

I have gotten a lot of e-mail that has said basicly the same things: 1) Don't try to redo UNIX crypt(3), S-KEY (Secure Shell, etc.) is better. Well... This is most certainly the case. And if I could force the people in my user base to use one of these alternatives, I would. Unfortunately, I cannot. A fair number of the people who use the systems that I administer log on through dumb terminals. If I can't successfully teach them not to hit the "Ctrl-S" key, how am I going to teach them to do IDEA encryption in their heads? Or MD4 hashes for that matter? The fact is that if I tried to use S/KEY everyone would print out their key list for the month, and then promptly loose it, and regenerate a new one. Gee... Wouldn't that be secure. I have to stay with the one password system. 2) If your administer was worth his weight in spit, you would have a shadow password system, and the preexisting crypt(3) function would be good enough for you. Actually, I _am_ the administrator, and I am worth my weight in spit. Rather, I do use a shadow password suite. However, as security professionals, you must know that it is not whether an attacker can break into your system, but how long it takes. Once there, it is not whether the attacker can gain root, it is how long it takes (how many of the holes have been patched, and how many are even known about). And then to the password file. It is not whether the attacker can crack _all_ the passwords, it is how long it takes. With this algorithm, I hope to increase the last of these values. 3) The algorithm is too complex (or too simple) The algorithm that I proposed makes use of a NMAC as a basic cryptographic primitive. The security analysis of the algorithm should follow the same lines as a hash; that is: if the basic operator is secure, then the chaining of the operator is secure. The NMAC is provably as secure as the key used and the underlying hash function. I did everything that I could to maintain simplicity throughout the algorithm's design. I realize that a simple algorithm is easier to analyze and check for security. A fair bit of the complexity is to make it so that the algorithm is actually a NMAC. 4) Why don't you use FreeBSD's MD5 based crypt(8) replacement? I didn't like FreeBSD's MD5 drop in, because it lacked any security analysis, and complexity of the algorithm prevented any serious attempt at said analysis. It also uses MD5, which has not held up well to the ravages of time. The recent papers on easier ways to find collisions in MD5 did _not_ give me an attack of the warm-and-fuzzies. I would like to make use of an algorithm that is still thought to be secure. Joshua -----------------------------Joshua E. Hill----------------------------- | Thoreau's Law: | | If you see a man approaching you with the obvious intention | | of doing you good, you should run for your life. | -------jehill@<gauss.elee|galaxy.csc|w6bhz|tuba.aix>.calpoly.edu--------

1 0

re: San Jose Mercury News declares encryption battle over
by nobody＠cypherpunks.ca 17 Dec '03

17 Dec '03

Dale how long have you been awake? Take a gander at Wei Dei's Crypto++, Peter Gutman's cryptlib, and the half dozen other public domain multi algo source libs available at your finger tips. Anyone with a compiler on just about any platform has access to implementations of blowfish, idea, des, gost, the gamut. So Dale, get coding. diGriz

1 0

Re: RFC: A UNIX crypt(3) replacement
by Joshua E. Hill 17 Dec '03

17 Dec '03

> This is backwards logic; when security begins to hender in the > functionality of the system, the security needs to be gotten rid of. hmmm... Now that _completely_ depends on the system. Now for the system I administer, the level of security really isn't _that_ high (on the grand scale of things). It is, however, high enough that I inconvenience the users with a pro-active password guesser, and passwords that expire occasionally. I suppose that this is a _minor_ inconvenience, but it raises the level of security a very large amount. On a less mundane system (one run by the government, say), security is only _slightly_ less important than being able to use the system in the first place. :) On this type of system almost any inconvenience is worth the cost. > > You have previously said that the passwd file should not be available > > for public consumption. Though this is certainly true, it does not > > hurt that even if the passwd file is available, nothing particularly > > useful can be done with it. > Hince you use pseudorandom password generators and crack. If you count on > somebody not being able to preform an opperation quickly, they'll usually > prove you wrong. whoa... didn't you just say: > when security begins to hender in the > functionality of the system, the security needs to be gotten rid of. I think that psedu-random password generators would almost certainly "hinder in the functionality of the system"... :-) I want to make it so that users can use passwords > 8 characters, and I want to use something a bit better than FreeBSD's solution. Whether or not this is necessarily the One True Way (TM) to security, it will increase security. I'm not saying "Hey everyone. Here is a spiffy new password system that will make your entire system completely secure!" I'm saying "Could everyone please look at this algorithm that I'm thinking of using. Could you please comment on it, so that I can make it better." That's it. All questions on whether or not passwords should shadowed, crackable, not crackable, or consisting only of the letter "e", aside. Is this algorithm secure, and if not, why not. Joshua > --Deviant > The Macintosh is Xerox technology at its best. I very much like your signature... very nice... -----------------------------Joshua E. Hill----------------------------- | Allen's Law: | | Almost anything is easier to get into than out of. | -------jehill@<gauss.elee|galaxy.csc|w6bhz|tuba.aix>.calpoly.edu--------

2 1

Re: HP announcing some International Cryptography stuff on Monday
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 12:49 PM 11/15/96 -0800, Timothy C. May wrote: >It sounds ominous to me. Another backroom deal, probably for some form of >key recovery strategy, aka GAK. I'd bet GAK too. RSADSI has been working on GAK protocols, so these ones might actually work. I feel as pessimistic about this one as Lucky usually is. At 12:05 PM 11/15/96 -0800, John Gilmore wrote: >Are they the next Big Company to knuckle under to the Feds? Their >pcmcia-with-local-country-surveillance-chip-socket initiative never >seemed to go anywhere. Since I am inherently optimistic, one ray of light may be that the San Jose Mercury News was mentioning the ability to export the system, and then when the necessary licenses (US and foreign) were obtained, turn on the encryption. I guess from this that the encryption is in hardware. Now, software/hardware interfaces are usually fairly simple, so what we have here is a software system with a crypto hook. ------------------------------------------------------------------------- Bill Frantz | The lottery is a tax on | Periwinkle -- Consulting (408)356-8506 | those who can't do math. | 16345 Englewood Ave. frantz(a)netcom.com | - Who 1st said this? | Los Gatos, CA 95032, USA

6 5

Re: ideal secure personal computer system
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 12:24 AM 11/16/96 -0600, Igor Chudov @ home wrote: >Bill Frantz wrote: >> Protection against strangers walking up to your machine and using it is >> nice, and easy to do. Protection against viruses which install Trojan >> horses in your system would also be nice, but is very hard to do in systems >> where programs run with all the privileges of their users. Examples >> include (in alpha order): DOS, MacOS, Unix, and Windows (including NT). > >I wonder what are the operating systems where programs may be run with >_less_ privileges than the user who starts them? Is VMS one of such >systems? Ah, you touch on 20+ years of my professional life. KeyKOS is such a system as is EROS, a similar system being developed at University of Pennsylvania. See: http://www.cis.upenn.edu:80/~eros/ http://www.cis.upenn.edu/~KeyKOS/ http://www.agorics.com/agorics/allkey.html - For KeyKOS documentation. In general these systems provide an execution environment where programs only have access to the resources they need. Think of it as a Unix chroot jail which is specifically designed for each program. Then add controlled communication links back to the user's terminal and you get the idea. Unless a program has a need to write the system file, it won't have the privilege, even if it's user does have the privilege. ------------------------------------------------------------------------- Bill Frantz | The lottery is a tax on | Periwinkle -- Consulting (408)356-8506 | those who can't do math. | 16345 Englewood Ave. frantz(a)netcom.com | - Who 1st said this? | Los Gatos, CA 95032, USA

1 0

RE: ideal secure personal computer system
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 12:51 PM 11/16/96 -0800, John Fricker wrote: >In WinNT a program may impersonate a user such as Guest. Also, trojan horses >are ineffective in NT as typical users do not have write permission to system >binaries. I assume that administrators only run programs from trusted libraries and do not include their current directory in their path. They never run programs that aren't directly related to systems administration etc. etc. etc. The typical Trojan horest sits around until someone with the proper authority runs it. That is not the way NT is used at one large commercial operation I am somewhat familar with. (I'm being obscure to protect the guilty.) I think there are very few NT (or Unix) systems which are administrated with a safe level of paranoia. I would like to see more compartmentalization in the system. (Note that even if it only runs with a user's privileges, a Trojan horse will have no problem stealing e.g. that user's PGP secret key ring. Not everything of value is in system files. Question, can a user-level Trojan horse insert itself as a keyboard monitor and get the PGP pass phrase as well?) ------------------------------------------------------------------------- Bill Frantz | The lottery is a tax on | Periwinkle -- Consulting (408)356-8506 | those who can't do math. | 16345 Englewood Ave. frantz(a)netcom.com | - Who 1st said this? | Los Gatos, CA 95032, USA

1 0

Off the subjects.
by twilley＠juno.com 17 Dec '03

17 Dec '03

Hi all, I am anxious to find an E-mail list forum dealing with financial matters. Possibly, there exists a forum to find a forum. Here in New Jersey there are rumors running about; that 401K's, and other corporation contribution plans are corporate assets: both their contribution, and the monies deducted from your pay, as well as, any other contributions you may have made. In the event of reorganization, in any form, including bankruptcy, these monies are available for redistribution to creditors. Meaning, not us. If true, it's a bit frightening; all and all. Thanks, Twilley.

2 1

DSA over Elliptic Curves
by janke＠unixg.ubc.ca 17 Dec '03

17 Dec '03

Has anyone implemented this yet? I am going to and was wondering what good sizes for q (the prime corresponding to the 160 bit prime in DSA) and p (the prime corresponding to the 512-1024 bit prime in DSA) would be? Leonard

1 0

Re: Members of Parliament Problem
by Hal Finney 17 Dec '03

17 Dec '03

From: ph(a)netcom.com (Peter Hendrickson) > At 1:39 PM 11/17/1996, Simon Spero wrote: > > Create a number up public/private key pairs, blind them, then do the > > cut-and-choose thing with the security officer. He signs the blinded key, > > then returns it. Unblind the remaining pubic key, and you've got a public > > key with the appropriate signature on it. > > Okay, this would work. But, it requires that all (or at least many) of the > Members of Parliament cooperate. If not, then the security officer will > be able to make very good guesses about who is speaking. > > Parliamentarians may not cooperate for a variety of reasons. They may > not wish to be attacked by terrorists for the words of others. They > may believe that cowardice is not to be encouraged. They may not believe > in anonymity. It might be too hard for them. > > What I would like to see is a method which relies only on published > public keys and no other cooperation from the people who are (more > or less) being used as shields. This may be impossible. The 4th method of Chaum's, from Eurocrypt 91, somewhat satisfies this, as does a method from the Eurocrypt 94 paper. Each person can choose his own public key g**x for a discrete log system. However, the problem is that all members of the group have to choose the same prime p as the modulus, and generator g, for their discrete logs. The issue of using a common modulus in discrete log systems has been somewhat controversial. I think when the government first proposed DSS they planned to do something like this, one modulus with everyone having different secret x values with corresponding public keys y = g**x mod p. This has the advantage that public keys are smaller since everyone uses the same g and p. So all you need is one value for your public key. Without this you have to have g, y, and p be your public key so it is 3 times bigger. The problem is that the way the main discrete log algorithms work, once you have broken one discrete log for a certain g and p you can break all the others very easily. So the particular g,p pair which is chosen for everyone to share becomes one very big, fat target to try to apply discrete log algorithms. Now this is not necessarily as bad as it seems. Unlike the case with RSA, there is no secret information which could be leaked to make solving these discrete logs easier. Nobody knows how to do it. So the only way it can be done is by a massive operation roughly similar to factoring an RSA modulus the size of p. Choosing p of 1000 or 2000 bits should still make it effectively impossible for anyone to do this. The numbers are simply far too large. Still the consensus of opinion with discrete logs is that the advantages of slightly smaller keys have not been great enough to justify the risk involved in having eveyone share a modulus, even though that risk is seemingly insignificant. On the other hand maybe for cases like this the additional advantages to common moduli would be enough to tilt the argument in the other direction. Hal

1 0

Political influence [was: Re: A Disservice to Mr. Bell]
by Jim Ray 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit To: cypherpunks(a)toad.com Date: Mon Nov 18 20:54:31 1996 > > ....The only mainstream party to have been in > any measure influenced by libertarian ideas is the Republicans ... I suppose that's why Clinton called himself a "libertarian" when it comes to gay rights. (Calling yourself something and actually *being* that something are, of course, different things.) Phill, you need to listen more and talk less about libertarian politics, I first heard about various wild-sounding now "mainstream" ideas when talking with Libertarians. These ideas are now promoted by members of both parties, especially during the election campaign season. For one thing, we were probably the first party to have a policy against government restrictions on the peaceful use of cryptography. JMR Regards, Jim Ray Please note new 2000bit PGPkey & new address <jmr(a)shopmiami.com> This key will be valid through election day 2000. PGP id.A7D63DA9 98 1F 39 BA 93 86 B4 F5 57 52 64 0E DA BA 2C 71 DNRC Minister of Encryption Advocacy -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEPAwUBMpETWzUhsGSn1j2pAQGYQgfMCQSQsEEjekyjOaQTptq3ZGmh4eTbPwdT Ow6LGMOzNTBaONJlypERAm7S00NAf9/ri6liFL2xR/A51t47PPIg48WO4xYHbB2S UefMasDZ2q+jT1s9ukUgHL1EgXCJVggAsaN1mSphYlNgVrRoT0zga59MB3ynFVsH hM4NVJEPCv8waE9WohSLUm6Mp2fvA1zLtGmHdf6fR/R38Yw5aVOTA3ha/hV/zPmH MQIsN+WV16f4KXAL/0V56y1mnuPJ0TumUJwJNc/lNxhiSdlI9t5l3ywe7Aw1D1xo TQO4ARkBSN8+/C/g6R9wfEZ+YoAN42NzNpdcATmCgXhwYg== =hhPT -----END PGP SIGNATURE-----

2 1