Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 31 Oct 2002 20:29:02 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 31 Oct 2002 20:28:13 -0500 Received: from tmr-02.dsl.thebiz.net ([216.238.38.204]:22545 "EHLO gatekeeper.tmr.com") by vger.kernel.org with ESMTP id ; Thu, 31 Oct 2002 20:27:11 -0500 Date: Thu, 31 Oct 2002 20:32:36 -0500 (EST) From: Bill Davidsen To: Andreas Dilger cc: "Matthew J. Fanto" , linux-kernel@vger.kernel.org Subject: Re: The Ext3sj Filesystem In-Reply-To: <20021030200020.GV28982@clusterfs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1105 Lines: 25 On Wed, 30 Oct 2002, Andreas Dilger wrote: > Some notes: > 1) having so many encryption algorithms is a huge pain in the ass, and > it will never be accepted into the kernel like that. Pick some > "good" encryption algorithms (like those that will be supported as > part of IPSec and/or the encrypted loop devices: 3DES, AES, RC5 or > whatever) and then there can be some re-use with other parts of the kernel. You are more trusting than I that these things can't be broken or in the case of AES were not selected because they could. Your point is good, but I think the way to do it is to define a crypto module API, such that user could drop in his/her own, be it custom, something which pops up in a year, or whatever. -- bill davidsen CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/