From owner-freebsd-security Mon Jul 29 12:01:53 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA16078 for security-outgoing; Mon, 29 Jul 1996 12:01:53 -0700 (PDT) Received: from kdat.calpoly.edu (kdat.csc.calpoly.edu [129.65.54.101]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA16073 for ; Mon, 29 Jul 1996 12:01:51 -0700 (PDT) Received: (from nlawson@localhost) by kdat.calpoly.edu (8.6.12/N8) id MAA00753; Mon, 29 Jul 1996 12:01:38 -0700 From: Nathan Lawson Message-Id: <199607291901.MAA00753@kdat.calpoly.edu> Subject: Re: Crack 4.1 patches for FBSD To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Mon, 29 Jul 1996 12:01:38 -0700 (PDT) Cc: freebsd-security@freebsd.org In-Reply-To: <2867.838405954@critter.tfs.com> from "Poul-Henning Kamp" at Jul 26, 96 08:32:34 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> Any news on any attacks on our MD5 based passwords ? > > >>The only problem I see with them is that MD5 is so darn quick, your number >>of crypts goes way up even with the present number of iterations. The DES >>hash used in most Unicen was desigend to be slow (originally taking 1 second >>per crypt on a VAX 11/780), but that fell prey to optimization and exponential >>CPU speed increases. >> >>Perhaps some intermediate permutations between hashes might be appropriate, >>but I'd consider the algorithm very carefully as it is very easy to end up >>with something that is no slower than the original and significantly less >>secure. > > Have you actually timed them ? Have you actually looked at the code that > generates the MD5 passwords in FreeBSD ? It sounds to me like you havn't... Yes, I actually have looked at it and timed them. I do not have any numbers with me any more, but I'd definitely like to see some. To expand further on what I meant, there's a comment in the code which says that the hash loop takes 34 ms to execute on a Pentium 60. In my opinion, this is on the rather quick side still, hence my comment that perhaps some more permutation could be useful. I was hoping to provoke some kind of discussion as to the cryptographic correctness of the MD5 crypt substitute. Also, the choices for the center of the loop (& 1, % 7, etc) seem rather arbitrary, so it might be possible that these cases do not help much in certain instances. For instance, since it's known that you go from one to a thousand in the loop, the exact same sequence of MD5Updates are executed, no matter what the user uses as a password. This makes it a good candidate for unrolling the loop and possibly combining various phases of the Updates into one step. I'm curious as to whether FreeBSD's crypt has come under any scrutiny from the crypto community, and would perhaps like some justification for the choices in the hashing loop. It's very difficult when arbitrary choices are made in crypto to determine their validity or possible problems. -- Nate Lawson "There are a thousand hacking at the branches of CPE Senior evil to one who is striking at the root." CSL Admin -- Henry David Thoreau, 'Walden', 1854 From owner-freebsd-security Mon Jul 29 14:08:52 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA22852 for security-outgoing; Mon, 29 Jul 1996 14:08:52 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.177]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA22800; Mon, 29 Jul 1996 14:08:25 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id XAA01432; Mon, 29 Jul 1996 23:08:33 +0200 (MET DST) To: Nathan Lawson cc: freebsd-security@freebsd.org Subject: Re: Crack 4.1 patches for FBSD In-reply-to: Your message of "Mon, 29 Jul 1996 12:01:38 PDT." <199607291901.MAA00753@kdat.calpoly.edu> Date: Mon, 29 Jul 1996 23:08:32 +0200 Message-ID: <1430.838674512@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I'm curious as to whether FreeBSD's crypt has come under any scrutiny from >the crypto community, and would perhaps like some justification for the >choices in the hashing loop. It's very difficult when arbitrary choices are >made in crypto to determine their validity or possible problems. Well, let me tell you the story: We couldn't use DES, since it couldn't be distributed abroad and all that jazz. Somebody, I can't remember who, (Nate Williams ?) made a replacement that was kind of a hash. It was not very good. It was not at all good. This is not meant to attack Nate, he didn't mean it to be that good, he just didn't want clear-text passwords in /etc. We had our 2.0 release comming up, and we had this sore thumb popping up all the time, so finally I sat down and I wrote the md5 based one as a replacement. Since the study of MD5 was and still is inconclusive, wrt to chaining MD5's, I made up a sequence of actions (almost what you see in the code now), that was based on a general theory of frustrating the bits as much as possible. In particular I tried a couple of places to do something that would make the length of the input to the MD5 algorithm variable in relation to the local context, in an attempt to frustrate HW assisted attacks (which seems to have come quite in fashion with DES hackers these days). I timed it, found it to be pretty much fine, but way too fast, so I added the second half of it, merely as something that will take a lot of time to execure. the result being what we have today. I then applied all the various kinds of analysis I could think of. frequency, correlation, FFT and so on, on all bits of the output, and on all combinations of two and three bits, and on the bytes. I didn't find any correlations, (not that I expected to) that could even come close to be called significant, so I was pretty happy with the result. (Later I even ran the stuff into a neural net, just to see if it could find any patterns, I left a machine toying with this for about a month. I got a very confused neural network as the only result.) The most interesting three features from a security point of view of this particular algorithm is the longer salt, longer output string and longer runtime of the code. I would expect each of these to contribute a factor of two to the security improvement over the DES based stuff. I have never, until now, heard from anybody who have even attempted to analyse it. You are from all I know the first person to scrutinize the code at all. I must say though, I also don't think it is interesting to do so. My attitude to the security of it is probably reflected by the fact that I put a version number in the "salt". (``$1$''). This is where I see the importance of my contribution. Not in the inherent strength of the present code, but in the fact that you can plug in a new algorithm almost on the fly. (And I have actually already thought about it a couple of times already. And on a couple of critical machines, I have even installed a couple of slightly modified crypt() functions.) Remember, passwords are as a rule both lousy >and< easy to change. A new algorithm based on something else could be distributed, peoples passwords expired and there you are: hole closed. For a while at least. We will never get a password mechanism that is resistant to attack. The best we can do is make it possible to change it, in response to increasing pressure from the guys in black hats. The most common attack that I have seen is dictionary attacks. The fact that the salt is bigger now, makes your precomputed dictionary attack more bulky to deal with, that improves the odds of "stupid" passwords a little bit. Having said all that, I would like to thank you a lot for your kind interest, and apologize for the slightly snappy answer I sent you to your last email. I would also kindly encourage your continued attention to the subject if at all possible. I'm actually very worried about the fact that nobody before you have even asked me these questions, (I presume that MD5 crypt is running on a lot of FreeBSD's out there, but I don't think we have any idea of finding out how many), but there is of course the option that people have looked at the source and decided that "it looked ok and that we probably know what we're doing, so why even ask". That would of course be even more disturbing from a security point of view. yours, Poul-Henning PS: Here are some of the ideas that I have toyed with for future versions: Move encryption into kernel. That way a system secrect salt, or maybe even a hardware-contained salt could be used that would be well protected from everybody. This would mean that even if you discovered this salt, you would have to make a dictionary for each of these salts. Make a VERY slow crypt with very long output. Something in the order of 10s of seconds on a P6/200. It is of course annoying that things take that long, but dictionaries would be practically impossible. Make a public/private key version. ... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-security Mon Jul 29 15:56:57 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA28326 for security-outgoing; Mon, 29 Jul 1996 15:56:57 -0700 (PDT) Received: from tombstone.sunrem.com (tombstone.sunrem.com [206.81.134.54]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA28321 for ; Mon, 29 Jul 1996 15:56:54 -0700 (PDT) Received: (from brandon@localhost) by tombstone.sunrem.com (8.7.5/8.7.3) id QAA10467; Mon, 29 Jul 1996 16:56:30 -0600 (MDT) Date: Mon, 29 Jul 1996 16:56:30 -0600 (MDT) From: Brandon Gillespie To: Poul-Henning Kamp cc: Nathan Lawson , freebsd-security@freebsd.org Subject: Re: Crack 4.1 patches for FBSD In-Reply-To: <1430.838674512@critter.tfs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Move encryption into kernel. That way a system secrect > salt, or maybe even a hardware-contained salt could be used > that would be well protected from everybody. This would > mean that even if you discovered this salt, you would have > to make a dictionary for each of these salts. I like, I _really_ like. > Make a VERY slow crypt with very long output. Something > in the order of 10s of seconds on a P6/200. It is of > course annoying that things take that long, but dictionaries > would be practically impossible. As long as the sleep is optional, and can be enabled/disabled with a simple command (hooked into sysconfig). On some systems I would likely enable it, but on most (like my workstation) I could frankly care less--I feel secure enough in my local net from system to system (i.e. each system is rather isolated), and the huge login times would simply get irritating quickly. > Make a public/private key version. Interesting possibilities.. And on a related topic, is SHA-1 taboo for exporting (like most crypto), or is it more open like MD5? From owner-freebsd-security Mon Jul 29 20:04:39 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA11125 for security-outgoing; Mon, 29 Jul 1996 20:04:39 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA11117 for ; Mon, 29 Jul 1996 20:04:36 -0700 (PDT) Received: from ec.camitel.com ([206.231.123.130]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id UAA00589 for ; Mon, 29 Jul 1996 20:04:34 -0700 (PDT) Received: from jaba.ec.camitel.com (m0.ec.camitel.com [206.231.123.150]) by ec.camitel.com (8.7.5/8.7.3) with SMTP id XAA01746; Mon, 29 Jul 1996 23:00:30 GMT Message-ID: X-Mailer: XFMail 0.5-alpha [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 29 Jul 1996 22:58:34 -0000 () Organization: Labyrinthe Bbs 8-) From: Luc Chamberland To: Brandon Gillespie Subject: Re: Crack 4.1 patches for FBSD Cc: Poul-Henning Kamp Cc: Poul-Henning Kamp , Nathan Lawson , freebsd-security@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> Make a public/private key version. > >Interesting possibilities.. ...Something likes PGP? What are you thinking about that? > >And on a related topic, is SHA-1 taboo for exporting (like most crypto), >or is it more open like MD5? []-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=--=-=-=-=-=[] | E-Mail : Luc Chamberland | Date: 07/29/96 | Time: 22:58:35 | Programmeur, Electro-Conception []-=-=-=-=-=-=-=-=--=-=-=-=--=-=-=-=-=-=-=-=-=[] Il n'y a pas de jours sans bonheur.... Il n'y a que des jours ou nous sommes aveugles! From owner-freebsd-security Mon Jul 29 22:36:25 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA20023 for security-outgoing; Mon, 29 Jul 1996 22:36:25 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.177]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA20014; Mon, 29 Jul 1996 22:36:19 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id HAA02152; Tue, 30 Jul 1996 07:36:40 +0200 (MET DST) To: Brandon Gillespie cc: Nathan Lawson , freebsd-security@freebsd.org Subject: Re: Crack 4.1 patches for FBSD In-reply-to: Your message of "Mon, 29 Jul 1996 16:56:30 MDT." Date: Tue, 30 Jul 1996 07:36:40 +0200 Message-ID: <2150.838705000@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Interesting possibilities.. Yes, I think so, and don't forget: You can play with it too :-) >And on a related topic, is SHA-1 taboo for exporting (like most crypto), >or is it more open like MD5? I don't know... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-security Mon Jul 29 22:44:31 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA21222 for security-outgoing; Mon, 29 Jul 1996 22:44:31 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.177]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA21217; Mon, 29 Jul 1996 22:44:26 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id HAA02264; Tue, 30 Jul 1996 07:43:32 +0200 (MET DST) To: Luc Chamberland cc: Brandon Gillespie , Nathan Lawson , freebsd-security@freebsd.org Subject: Re: Crack 4.1 patches for FBSD In-reply-to: Your message of "Mon, 29 Jul 1996 22:58:34 -0000." Date: Tue, 30 Jul 1996 07:43:31 +0200 Message-ID: <2262.838705411@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> >>> Make a public/private key version. >> >>Interesting possibilities.. > > ...Something likes PGP? What are you thinking about that? yes, "something like that". Remember that it doesn't have to be a two way algorithm, so we can be more creative than PGP. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-security Tue Jul 30 05:24:25 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA13169 for security-outgoing; Tue, 30 Jul 1996 05:24:25 -0700 (PDT) Received: from ec.camitel.com ([206.231.123.130]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA13162 for ; Tue, 30 Jul 1996 05:24:23 -0700 (PDT) Received: from jaba.ec.camitel.com (line99.megatoon.com [205.205.31.99]) by ec.camitel.com (8.7.5/8.7.3) with SMTP id IAA02573; Tue, 30 Jul 1996 08:21:35 GMT Message-ID: X-Mailer: XFMail 0.5-alpha [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <2262.838705411@critter.tfs.com> Date: Tue, 30 Jul 1996 08:19:46 -0000 () Organization: Labyrinthe Bbs 8-) From: Luc Chamberland To: Poul-Henning Kamp Subject: Re: Crack 4.1 patches for FBSD Cc: Brandon Gillespie Cc: Brandon Gillespie , Nathan Lawson , freebsd-security@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 30-Jul-96 Poul-Henning Kamp wrote: >> ...Something likes PGP? What are you thinking about that? > >yes, "something like that". Remember that it doesn't have to be a >two way algorithm, so we can be more creative than PGP. > >-- and PGP is less powerfull in this way? []-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=--=-=-=-=-=[] | E-Mail : Luc Chamberland | Date: 07/30/96 | Time: 08:19:46 | Programmeur, Electro-Conception []-=-=-=-=-=-=-=-=--=-=-=-=--=-=-=-=-=-=-=-=-=[] Il n'y a pas de jours sans bonheur.... Il n'y a que des jours ou nous sommes aveugles! From owner-freebsd-security Wed Jul 31 12:22:13 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA17955 for security-outgoing; Wed, 31 Jul 1996 12:22:13 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.177]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA17944; Wed, 31 Jul 1996 12:22:08 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id VAA02487; Tue, 30 Jul 1996 21:06:55 +0200 (MET DST) To: Luc Chamberland cc: Brandon Gillespie , Nathan Lawson , freebsd-security@freebsd.org Subject: Re: Crack 4.1 patches for FBSD In-reply-to: Your message of "Tue, 30 Jul 1996 08:19:46 -0000." Date: Tue, 30 Jul 1996 21:06:54 +0200 Message-ID: <2485.838753614@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message , Luc Chamberland write s: > >On 30-Jul-96 Poul-Henning Kamp wrote: > >>> ...Something likes PGP? What are you thinking about that? >> >>yes, "something like that". Remember that it doesn't have to be a >>two way algorithm, so we can be more creative than PGP. >> >>-- > > and PGP is less powerfull in this way? PGP is a rather large piece of code, and certain restrictions apply to the modification of it. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-security Wed Jul 31 23:26:38 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA00892 for security-outgoing; Wed, 31 Jul 1996 23:26:38 -0700 (PDT) Received: from darkwing.pacific.net.sg (darkwing.pacific.net.sg [203.120.89.89]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA00887 for ; Wed, 31 Jul 1996 23:26:33 -0700 (PDT) Received: (qmail-queue invoked from smtpd); 1 Aug 1996 06:25:03 -0000 Received: from darkwing.pacific.net.sg (203.120.89.89) by darkwing.pacific.net.sg with SMTP; 1 Aug 1996 06:25:03 -0000 Date: Thu, 1 Aug 1996 14:25:03 +0800 (SST) From: Ng Pheng Siong To: freebsd-security@freebsd.org Subject: [linux-security] Test squad results on group rights denial (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Got the following from linux-security. Just noted that FreeBSD (also Net and Open ;) aren't listed. Anyone know what this is? ---------- Forwarded message ---------- Date: Tue, 30 Jul 1996 09:27:53 +0200 (MET DST) From: Rogier Wolff To: linux-security@tarsier.cv.nrao.edu Subject: [linux-security] Test squad results on group rights denial I've got several replies back from the test squad now. The question was: Can we find OSes where you cannot get less rights than "other" if you're in the group..... The test squad so far has access to the following OSes: Linux (Slackware 3.0) 2.0.9 Linux (Slackware 2.0 w/mods) 1.2.13 Linux (Slackware 2.3) 2.0.8 Linux (Slackware 3.0) 2.0.7 Linux (Slackware ??) 1.2.8 Linux (Debian 1.1) 2.0.8 Linux (RedHat 3.0.3) 2.0.0 Linux (Redhat ??) ???? Linux (custom) 2.0.8 Linux (???) 1.3.80, ext2fs AIX 2.3 BSDI 2.0 HPUX 9.05 HPUX 10.10 HPUX 10.01 Irix 5.3 Irix 6.2 OSF1 3.2 OSF1 3.2d SunOS 4.1.3 SunOS 4.1.4 Solaris 2.3 (SunOS 5.3) Solaris 2.4 (SunOS 5.4) Solaris 2.5 (SunOS 5.5) VMS 5.5-1 On most OSes it seems that you are able to revoke rights by putting someone in a group, and revoking group rights. I got reports about NOT being able to revoke "other" rights using the group bits for the following OSes: HPUX 10.01, Irix 5.3 and Linux 1.2.8. I verified HPUX versions 9.05 and 10.10 myself, and WAS able to revoke rights. Others have been able to do that for Linux and Irix. For Linux it might be filesystem dependent. Ext2fs will handle this properly. The test squad ran 30 tests, of which 3 turned out questionable. The original report from Daniel Roedding (daniel@fiction.pb.owl.de) that it didn't work on an old dynix system still stands. Roger. -- /* EMail: R.E.Wolff@BitWizard.nl */ int main (int argc,char**argv){ /* Tel: +31-15-2137459 */ if (*++argv&&!strcmp(*argv,"-advice")) /* WWW: http://www.BitWizard.nl/ */ {printf("Don't Panic!\n");exit(42);}} From owner-freebsd-security Fri Aug 2 22:08:25 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA27071 for security-outgoing; Fri, 2 Aug 1996 22:08:25 -0700 (PDT) Received: from kdat.calpoly.edu (kdat.csc.calpoly.edu [129.65.54.101]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA27065 for ; Fri, 2 Aug 1996 22:08:23 -0700 (PDT) Received: (from nlawson@localhost) by kdat.calpoly.edu (8.6.12/N8) id WAA02355; Fri, 2 Aug 1996 22:08:23 -0700 From: Nathan Lawson Message-Id: <199608030508.WAA02355@kdat.calpoly.edu> Subject: Re: Crack 4.1 patches for FBSD To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Fri, 2 Aug 1996 22:08:23 -0700 (PDT) Cc: freebsd-security@freebsd.org In-Reply-To: <2150.838705000@critter.tfs.com> from "Poul-Henning Kamp" at Jul 30, 96 07:36:40 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >And on a related topic, is SHA-1 taboo for exporting (like most crypto), > >or is it more open like MD5? > > I don't know... >From what I've seen, the government of the US places no limits on hashing algorithms or any type of signature system. They WANT to be able to verify who you are; they just don't want you to be able to hide your information. :) -- Nate Lawson "There are a thousand hacking at the branches of CPE Senior evil to one who is striking at the root." CSL Admin -- Henry David Thoreau, 'Walden', 1854 From owner-freebsd-security Fri Aug 2 22:13:48 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA27453 for security-outgoing; Fri, 2 Aug 1996 22:13:48 -0700 (PDT) Received: from kdat.calpoly.edu (kdat.csc.calpoly.edu [129.65.54.101]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA27448 for ; Fri, 2 Aug 1996 22:13:47 -0700 (PDT) Received: (from nlawson@localhost) by kdat.calpoly.edu (8.6.12/N8) id WAA02366; Fri, 2 Aug 1996 22:13:34 -0700 From: Nathan Lawson Message-Id: <199608030513.WAA02366@kdat.calpoly.edu> Subject: Re: Crack 4.1 patches for FBSD To: brandon@tombstone.sunrem.com (Brandon Gillespie) Date: Fri, 2 Aug 1996 22:13:34 -0700 (PDT) Cc: freebsd-security@freebsd.org In-Reply-To: from "Brandon Gillespie" at Jul 29, 96 04:56:30 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Make a VERY slow crypt with very long output. Something > > in the order of 10s of seconds on a P6/200. It is of > > course annoying that things take that long, but dictionaries > > would be practically impossible. > > As long as the sleep is optional, and can be enabled/disabled with a > simple command (hooked into sysconfig). On some systems I would likely > enable it, but on most (like my workstation) I could frankly care less--I > feel secure enough in my local net from system to system (i.e. each system > is rather isolated), and the huge login times would simply get irritating > quickly. Unfortunately, a sleep would be inadequate against a dictionary attack. The actual algorithm (and hence the garbled password) would have to depend on a number of iterations sufficient to discourage this attack. Being able to disable it and still use the same crypt would add no additional security. I'm actually interested in a 'secure' release of FreeBSD, with daemons not running as root, no complicated mailers, few to no setuid binaries -- in essence, what I do to my FreeBSD systems as soon as I install them. Unfortunately, I have recently started a very demanding job and do not have the time to contribute to such a project. My apologies. -- Nate Lawson "There are a thousand hacking at the branches of CPE Senior evil to one who is striking at the root." CSL Admin -- Henry David Thoreau, 'Walden', 1854