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?