From owner-linux-crypto@nl.linux.org Sun Oct 1 13:18:06 2000 Received: by humbolt.nl.linux.org id ; Sun, 1 Oct 2000 13:17:32 +0200 Received: from midten.fast.no ([213.188.8.11]:21005 "EHLO midten.fast.no") by humbolt.nl.linux.org with ESMTP id ; Sun, 1 Oct 2000 13:17:06 +0200 Received: (from astor@localhost) by midten.fast.no (8.9.3/8.9.3) id NAA23349; Sun, 1 Oct 2000 13:17:02 +0200 (CEST) Date: Sun, 1 Oct 2000 13:17:02 +0200 From: Alexander S A Kjeldaas To: Marc Mutz Cc: linux-crypto@nl.linux.org Subject: Re: [experimantal patch] show allowed keylengths in /proc/cipher/* Message-ID: <20001001131701.A23145@midten.fast.no> References: <39D4B197.CE21F30C@Mutz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <39D4B197.CE21F30C@Mutz.com>; from Marc Mutz on Fri, Sep 29, 2000 at 03:13:27PM +0000 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Fri, Sep 29, 2000 at 03:13:27PM +0000, Marc Mutz wrote: > Hi out there! > > This little patch allows /proc/cipher/* to show a bitmask of allowed > keysizes. Simple as it may ssem, it breaks the current jungle of > #define's quite thoroughly. Ciphers that want to take advantage of this > patch and actually _provide_ more than one keylength per cipher > implementation (and most ciphers could), will not be able to use the > DEFINE_CIPHER construct any more. > Why not just let all ciphers accept any key-length up to a maximum key length, and have the cipher internally treat shorter keys as a possible optimization opportunities. For example, the rijndael cipher could exploit that kind of stuff to select the correct number of rounds. So the user wouldn't really care about which intermediate keylengths a cipher was designed for, just the maximum keylength it was designed for. > So what now? I'd like to remove the DEFINE_CIPHER construct althogether. > It makes defining "dumb" ciphers easy, but it obfuscates the definition > of a cipher for unexperienced (w.r.t. cipherapi) coders and interested > eyes that read the source, since the meaning of the numbers and strings > appearing in DEFINE_CIPHER is not obvious. Even when you have read over > a few cipher sources you catch yourself going back to > include/linux/crypto.h to look up what each entry means. > > On the opposite, having the struct cipher_implementation populated > without the help of macros goes a long way towards transparency, because > the field identifiers show up alongside their values. Or not? > > Now my inexprience with C comes up again: Is there a C construct that > shows the field identifiers even in static const definitions? Like in > perl: > > %an_associative_array = { > field1 -> value1, > field2 -> value2, > : : > } > You are free to not use DEFINE_CIPHER if you want. There are two constructs that can be used to initialize C structs. One is a gcc extension and looks like this: struct foo bar = { membera: 1, memberb: 2 }; The other one is part of C99 and goes like this: struct foo bar = { .membera = 1, .memberb = 2 }; In the kernel, the first form is used since it is programmed in GNU C, and not standard C. astor -- Alexander Kjeldaas Mail: astor@fast.no finger astor@master.kernel.org for OpenPGP key. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Sun Oct 1 13:27:57 2000 Received: by humbolt.nl.linux.org id ; Sun, 1 Oct 2000 13:27:33 +0200 Received: from midten.fast.no ([213.188.8.11]:26381 "EHLO midten.fast.no") by humbolt.nl.linux.org with ESMTP id ; Sun, 1 Oct 2000 13:26:54 +0200 Received: (from astor@localhost) by midten.fast.no (8.9.3/8.9.3) id NAA23513; Sun, 1 Oct 2000 13:26:50 +0200 (CEST) Date: Sun, 1 Oct 2000 13:26:49 +0200 From: Alexander S A Kjeldaas To: Alexander S A Kjeldaas Cc: Marc Mutz , Gisle S{lensminde , linux-crypto@nl.linux.org Subject: Re: AES will be announced monday. Message-ID: <20001001132649.A23475@midten.fast.no> References: <39D50F01.7419EB7D@Mutz.com> <20000930104930.A285@midten.fast.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <20000930104930.A285@midten.fast.no>; from Alexander S A Kjeldaas on Sat, Sep 30, 2000 at 10:49:30AM +0200 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Sat, Sep 30, 2000 at 10:49:30AM +0200, Alexander S A Kjeldaas wrote: > > The newest implementation in the kerneli patch is almost twice as > fast as the previous one on Pentium III, and thus the fastest of all > the AES candicates in software too! Correction. It's not in the kerneli patch yet, it's in a separate tree of mine. astor -- Alexander Kjeldaas Mail: astor@fast.no finger astor@master.kernel.org for OpenPGP key. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Sun Oct 1 14:57:28 2000 Received: by humbolt.nl.linux.org id ; Sun, 1 Oct 2000 14:56:55 +0200 Received: from eik.ii.uib.no ([129.177.16.3]:4954 "EHLO ii.uib.no") by humbolt.nl.linux.org with ESMTP id convert rfc822-to-8bit; Sun, 1 Oct 2000 14:56:27 +0200 Received: from struts.ii.uib.no [129.177.17.22] by ii.uib.no with esmtp (Exim 3.03) id 13fifb-0007Z6-00 ; Sun, 01 Oct 2000 14:56:43 +0200 Received: (from gisle@localhost) by struts.ii.uib.no (8.9.3+Sun/8.9.3) id OAA00895; Sun, 1 Oct 2000 14:56:25 +0200 (MEST) Date: Sun, 1 Oct 2000 14:56:24 +0200 (MEST) From: Gisle S{lensminde To: Alexander S A Kjeldaas cc: linux-crypto@nl.linux.org Subject: Re: [experimantal patch] show allowed keylengths in /proc/cipher/* In-Reply-To: <20001001131701.A23145@midten.fast.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Sun, 1 Oct 2000, Alexander S A Kjeldaas wrote: > On Fri, Sep 29, 2000 at 03:13:27PM +0000, Marc Mutz wrote: > > Hi out there! > > > > This little patch allows /proc/cipher/* to show a bitmask of allowed > > keysizes. Simple as it may ssem, it breaks the current jungle of > > #define's quite thoroughly. Ciphers that want to take advantage of this > > patch and actually _provide_ more than one keylength per cipher > > implementation (and most ciphers could), will not be able to use the > > DEFINE_CIPHER construct any more. > > > > Why not just let all ciphers accept any key-length up to a maximum key > length, and have the cipher internally treat shorter keys as a > possible optimization opportunities. For example, the rijndael cipher > could exploit that kind of stuff to select the correct number of > rounds. So the user wouldn't really care about which intermediate > keylengths a cipher was designed for, just the maximum keylength it > was designed for. For some ciphers this may introduce security traps. The best example is 3DES. Now we accept 8, 16 or 24 bit keys and reject all other key lengths. This corresponds to DES compatibility, 2 key 3DES and 3 key 3DES respectivly. The parity bits are ignored. The problem is what we are going to do in the case where we have keylengths that don't fit into this. If we pad the key up to the nearest defined keylength we will get the possibility for meet-in-the-middle attacks against the cipher, which will reduce the complexity of an attack to around 2^56 work. If we on the other hand throw away bits to fit into a smaller key, we can also get in touble. The best example is when someone tries to use a keylength 14 or 15 bytes. then the security will be 2^56, since the lower key length is 56 bits. This will give the users a false imression of security. The worst case is maybe 14 bytes, since many people thinks that 14 bytes = 112 bits keylength, but miss the parity bits. They will belive they use a 112 bits key, while they only use a 56 bit key. Both of the strategies will introduce potential traps, and a more advanced scheme will give surprises to the users, since we must introduce such modes. This will not be compatible with anything else either. IMO here should be possible to restrict some ciphers to predefined keylengths. -- Gisle Sælensminde ( gisle@ii.uib.no ) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. (from RFC 1925) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Mon Oct 2 12:55:09 2000 Received: by humbolt.nl.linux.org id ; Mon, 2 Oct 2000 12:54:43 +0200 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:58972 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Mon, 2 Oct 2000 12:54:30 +0200 Received: from Mutz.com (emmy.Mathematik.Uni-Bielefeld.DE [129.70.24.21]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G1S00HBSUAHM0@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Mon, 2 Oct 2000 12:54:18 +0200 (MET DST) Date: Mon, 02 Oct 2000 12:53:58 +0200 From: Marc Mutz Subject: [Encryption-HOWTO] now on sourceforge! To: linux-crypto@nl.linux.org Message-id: <39D86946.4D309F27@Mutz.com> MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Hi out there! The old 486DX-40 (clocked at 20MHz due to hardware problems) was totally overloaded with accesses to the HOWTO after the posting to /. (not by me!). So I've taken the tast to move its homepage to sourceforge. I've succeeded, but currently there is no added value (no CVS, no FTP, only the web site as you know it). I will make at least CVS and anon-FTP available in a few days, meaning that anyone who feels he could contribute something "worthy" to the HOWTO will be able to do so. The new address is (surprisingly) http://EncryptionHOWTO.sourceforge.net/ and is up and running for a few minutes by now. If you see any dead links or the like, please let me know and I'll fix them ASAP. The old site remains existent, put points to the new one. Marc Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Mon Oct 2 15:34:41 2000 Received: by humbolt.nl.linux.org id ; Mon, 2 Oct 2000 15:34:10 +0200 Received: from midten.fast.no ([213.188.8.11]:20997 "EHLO midten.fast.no") by humbolt.nl.linux.org with ESMTP id ; Mon, 2 Oct 2000 15:33:43 +0200 Received: (from astor@localhost) by midten.fast.no (8.9.3/8.9.3) id PAA57132; Mon, 2 Oct 2000 15:33:34 +0200 (CEST) Date: Mon, 2 Oct 2000 15:33:33 +0200 From: Alexander S A Kjeldaas To: Gisle S{lensminde Cc: Alexander S A Kjeldaas , linux-crypto@nl.linux.org Subject: Re: [experimantal patch] show allowed keylengths in /proc/cipher/* Message-ID: <20001002153332.A56132@midten.fast.no> References: <20001001131701.A23145@midten.fast.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Gisle S{lensminde on Sun, Oct 01, 2000 at 02:56:24PM +0200 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Sun, Oct 01, 2000 at 02:56:24PM +0200, Gisle S{lensminde wrote: > On Sun, 1 Oct 2000, Alexander S A Kjeldaas wrote: > > > > Why not just let all ciphers accept any key-length up to a maximum key > > length, and have the cipher internally treat shorter keys as a > > possible optimization opportunities. For example, the rijndael cipher > > could exploit that kind of stuff to select the correct number of > > rounds. So the user wouldn't really care about which intermediate > > keylengths a cipher was designed for, just the maximum keylength it > > was designed for. > > For some ciphers this may introduce security traps. The best example > is 3DES. Now we accept 8, 16 or 24 bit keys and reject all other > key lengths. This corresponds to DES compatibility, 2 key 3DES and > 3 key 3DES respectivly. The parity bits are ignored. The problem > is what we are going to do in the case where we have keylengths that > don't fit into this. If we pad the key up to the nearest defined > keylength we will get the possibility for meet-in-the-middle attacks > against the cipher, which will reduce the complexity of an attack > to around 2^56 work. > > If we on the other hand throw away bits to fit into a smaller key, > we can also get in touble. The best example is when someone tries > to use a keylength 14 or 15 bytes. then the security will be 2^56, > since the lower key length is 56 bits. This will give the users a > false imression of security. The worst case is maybe 14 bytes, since > many people thinks that 14 bytes = 112 bits keylength, but miss > the parity bits. They will belive they use a 112 bits key, while > they only use a 56 bit key. > Third strategy. You don't need a "global" strategy for how you deal with keys. For 3DES you could remove bits from the three keys in a round-robin fashion so that none of the three keys are weaker than the others by more than 1 bit. I buy your argument that the very act of accepting a 112 bit key is a potential trap, since you might very well be looking at a software bug, and that returning an error would be a lot better. But what if the user of the library actually _has_ 80 random bits that he wants to use as a key. How should he be able to use 3DES? He queries the interface and finds out that he can give 3DES a key with 56, 112, or 168 random bits (if we ignore parity bits). What should the user do? The "obvious" tricks are dangerous to use for 3DES, as you demonstrate above, while a 3DES-specific function could help him get a key with as high security as possible from his 80 random bits. > Both of the strategies will introduce potential traps, and a more > advanced scheme will give surprises to the users, since we must > introduce such modes. This will not be compatible with anything > else either. If we construct a 3DES-specific key-munging algorithm, it will be "incompatible" with other software to a certain extent, and that's a bad thing. I'm just trying to show/make sure that all ciphers _can_ handle a keys of variable length, so that the user of a crypto library doesn't need to care about these issues. If the user doesn't need to care about these issues, the interface doesn't have to be more complex. I am no cryptographer so there might well be more traps with such an approach though, so do not expect something like this to appear right away. > IMO here should be possible to restrict some ciphers to > predefined keylengths. astor -- Alexander Kjeldaas Mail: astor@fast.no finger astor@master.kernel.org for OpenPGP key. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Mon Oct 2 17:25:40 2000 Received: by humbolt.nl.linux.org id ; Mon, 2 Oct 2000 17:24:54 +0200 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:19907 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Mon, 2 Oct 2000 17:24:28 +0200 Received: from Mutz.com (ppp36-191.hrz.uni-bielefeld.de [129.70.36.191]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G1T0044M6SP7H@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Mon, 2 Oct 2000 17:24:26 +0200 (MET DST) Date: Mon, 02 Oct 2000 15:05:29 +0000 From: Marc Mutz Subject: Using kerneli w/o compiling a kernel? To: linux-crypto@nl.linux.org Message-id: <39D8A439.BD141DDB@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Hi! I've run into the problem of explaining how to make an encrypted folder with kerneli to someone who merely survived a linux install. I kow that the answer to the following is NO, but does someone out there know of RPMs for the major dirtributions of both the kernel modules and the patched mount and losetup? Is anyone willing to do this or tell me how to? This would greatly simplify my task. However if - as is expected - the answer to the above question is NO, is there a way to completely module out the kerneli parts so that there is no need to recompile the kernel. I know that everything can be compiled as modules, but when I try this, I don't get a cryptoapi.o module. I've selected it as being a module, but is is compiled into the kernel nevertheless: Q> $ cat /proc/ksyms | grep cipher Q> c02462e8 cipher_group Marc -- Marc Mutz http://Encryption-HOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Mon Oct 2 17:26:51 2000 Received: by humbolt.nl.linux.org id ; Mon, 2 Oct 2000 17:25:11 +0200 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:21699 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Mon, 2 Oct 2000 17:24:30 +0200 Received: from Mutz.com (ppp36-191.hrz.uni-bielefeld.de [129.70.36.191]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G1T0044Y6SS7H@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Mon, 2 Oct 2000 17:24:29 +0200 (MET DST) Date: Mon, 02 Oct 2000 15:23:13 +0000 From: Marc Mutz Subject: [Fwd: AES for GnuPG, on Mon Oct 2?] To: linux-crypto@nl.linux.org Message-id: <39D8A861.E5E99C96@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Alex, it might be that we lose: "Michael H. Warfield" wrote on gnupg-devel: > > Serpent apparently is subject to a claim by Hitachi that it holds > a patent over some aspect of it. Rumor has it that it's out of the race. > That's based on a coderpunks posting which I have not been able to > independently verify. > Marc -- Marc Mutz http://marc.mutz.com/Encryption-HOWTO/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Mon Oct 2 17:27:46 2000 Received: by humbolt.nl.linux.org id ; Mon, 2 Oct 2000 17:25:34 +0200 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:20931 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Mon, 2 Oct 2000 17:24:29 +0200 Received: from Mutz.com (ppp36-191.hrz.uni-bielefeld.de [129.70.36.191]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G1T0044P6SQ7H@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Mon, 2 Oct 2000 17:24:28 +0200 (MET DST) Date: Mon, 02 Oct 2000 15:20:41 +0000 From: Marc Mutz Subject: Re: [experimantal patch] show allowed keylengths in /proc/cipher/* To: Alexander S A Kjeldaas Cc: Gisle S{lensminde , linux-crypto@nl.linux.org Message-id: <39D8A7C9.484C360F@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <20001001131701.A23145@midten.fast.no> <20001002153332.A56132@midten.fast.no> Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Alexander S A Kjeldaas wrote: > > > Third strategy. You don't need a "global" strategy for how you deal > with keys. For 3DES you could remove bits from the three keys in a > round-robin fashion so that none of the three keys are weaker than the > others by more than 1 bit. > > I buy your argument that the very act of accepting a 112 bit key is a > potential trap, since you might very well be looking at a software > bug, and that returning an error would be a lot better. > > But what if the user of the library actually _has_ 80 random bits that > he wants to use as a key. How should he be able to use 3DES? Hashing it or just using a cipher that can. > He > queries the interface and finds out that he can give 3DES a key with > 56, 112, or 168 random bits (if we ignore parity bits). What should > the user do? The "obvious" tricks are dangerous to use for 3DES, as > you demonstrate above, while a 3DES-specific function could help him > get a key with as high security as possible from his 80 random bits. > > > If we construct a 3DES-specific key-munging algorithm, it will be > "incompatible" with other software to a certain extent, and that's a > bad thing. I'm just trying to show/make sure that all ciphers _can_ > handle a keys of variable length, so that the user of a crypto library > doesn't need to care about these issues. If the user doesn't need to > care about these issues, the interface doesn't have to be more > complex. I am no cryptographer so there might well be more traps with > such an approach though, so do not expect something like this to > appear right away. > I'm sure there can be nasty consequences if you use a cipher that has a defined key length with another. It is true that most recently developed ciphers do in fact accept arbitrary length keys (up to a certain maximum), but they are _designed_ to do this. They have a matching key schedule algorithm that can cope with that. Blowfish accepts key lengths of up to 448 bits (being a _symmetric_ cipher) and Twofish up to 256. But doing some nasty things with the key bits before they are given to the key schedule will probably open the door for related-key attacks. It's the old tale: Use a cipher different than it was designed and you get into all sorts of troubles. Look at DES's S-Boxes. Change them in any way and you make DES weaker and sometimes trivial to break. Ciphers are fragile objects that should only be used "according to the book". Alex gave another reason: DES is a standard. You can't go and say. "Well, I have here these extra bits of entropy, lets throw them in somehow." How should this interoperate with other implementations. That's the way MS is using standards. Sorry. The main reason for the proposal of a keylength list in /proc/cipher/ was the need to have it in order for losetup to look it up. Currently there is no inexpensive way to gather allowed keysizes to present them in /proc/cipher/. losetup should be able to search that directoy and find the key length there. Marc -- Marc Mutz http://marc.mutz.com/Encryption-HOWTO/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Mon Oct 2 18:23:49 2000 Received: by humbolt.nl.linux.org id ; Mon, 2 Oct 2000 18:23:14 +0200 Received: from rf-mail1.echostar.com ([205.172.144.40]:4614 "EHLO rf-exch2.echostar.com") by humbolt.nl.linux.org with ESMTP id ; Mon, 2 Oct 2000 18:22:44 +0200 Received: from echostar.com (linux10.echostar.com [172.20.50.110]) by rf-exch2.echostar.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id SYW4H05D; Mon, 2 Oct 2000 10:22:32 -0600 Message-ID: <39D8B645.FA2F0368@echostar.com> Date: Mon, 02 Oct 2000 10:22:29 -0600 From: "Ian S. Nelson" Reply-To: ian.nelson@echostar.com Organization: Echostar X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.0-test6 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-crypto@nl.linux.org" Subject: Re: [Fwd: AES for GnuPG, on Mon Oct 2?] References: <39D8A861.E5E99C96@Mutz.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Wasn't DES covered by a patent? I know Lucifer was and DES is closely related. Patent or no patent, AES should be fairly liberal in terms of usage restrictions. I don't remember the rules but I thought that there was some provision for patents. Anyone know who won yet? The NIST webcast page doesn't work. Marc Mutz wrote: > Alex, it might be that we lose: > > "Michael H. Warfield" wrote on gnupg-devel: > > > > > Serpent apparently is subject to a claim by Hitachi that it holds > > a patent over some aspect of it. Rumor has it that it's out of the race. > > That's based on a coderpunks posting which I have not been able to > > independently verify. > > > > > Marc > Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Mon Oct 2 18:27:58 2000 Received: by humbolt.nl.linux.org id ; Mon, 2 Oct 2000 18:27:24 +0200 Received: from mx2out.umbc.edu ([130.85.253.52]:7297 "EHLO mx2out.umbc.edu") by humbolt.nl.linux.org with ESMTP id ; Mon, 2 Oct 2000 18:26:49 +0200 Received: from gl.umbc.edu (mmundy1@ecs005sgi13.gl.umbc.edu [130.85.60.63]) by mx2out.umbc.edu (8.9.3/8.9.3) with ESMTP id MAA06711; Mon, 2 Oct 2000 12:26:44 -0400 (EDT) Received: from localhost (mmundy1@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id MAA11159; Mon, 2 Oct 2000 12:26:43 -0400 (EDT) X-Authentication-Warning: ecs005sgi13.gl.umbc.edu: mmundy1 owned process doing -bs Date: Mon, 2 Oct 2000 12:26:42 -0400 From: Matthew Mundy To: "Ian S. Nelson" cc: "linux-crypto@nl.linux.org" Subject: Re: [Fwd: AES for GnuPG, on Mon Oct 2?] In-Reply-To: <39D8B645.FA2F0368@echostar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list According to sci.crypt it's rijndael. ---Matt On Mon, 2 Oct 2000, Ian S. Nelson wrote: > Wasn't DES covered by a patent? I know Lucifer was and DES is closely > related. Patent or no patent, AES should be fairly liberal in terms of usage > restrictions. I don't remember the rules but I thought that there was some > provision for patents. > > Anyone know who won yet? The NIST webcast page doesn't work. > > > Marc Mutz wrote: > > > Alex, it might be that we lose: > > > > "Michael H. Warfield" wrote on gnupg-devel: > > > > > > > > Serpent apparently is subject to a claim by Hitachi that it holds > > > a patent over some aspect of it. Rumor has it that it's out of the race. > > > That's based on a coderpunks posting which I have not been able to > > > independently verify. > > > > > > > > > Marc > > > > > Linux-crypto: cryptography in and on the Linux system > Archive: http://mail.nl.linux.org/linux-crypto/ > Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Mon Oct 2 18:31:18 2000 Received: by humbolt.nl.linux.org id ; Mon, 2 Oct 2000 18:30:44 +0200 Received: from cpu2747.adsl.bellglobal.com ([207.236.55.216]:34301 "EHLO grendel.conscoop.ottawa.on.ca") by humbolt.nl.linux.org with ESMTP id ; Mon, 2 Oct 2000 18:30:24 +0200 Received: (from rgb@localhost) by grendel.conscoop.ottawa.on.ca (8.9.0/8.9.0) id MAA29481; Mon, 2 Oct 2000 12:26:50 -0400 Date: Mon, 2 Oct 2000 12:26:49 -0400 From: Richard Guy Briggs To: "Ian S. Nelson" Cc: "linux-crypto@nl.linux.org" Subject: Re: [Fwd: AES for GnuPG, on Mon Oct 2?] Message-ID: <20001002122649.L22289@grendel.conscoop.ottawa.on.ca> References: <39D8A861.E5E99C96@Mutz.com> <39D8B645.FA2F0368@echostar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <39D8B645.FA2F0368@echostar.com>; from ian.nelson@echostar.com on Mon, Oct 02, 2000 at 10:22:29AM -0600 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list -----BEGIN PGP SIGNED MESSAGE----- On Mon, Oct 02, 2000 at 10:22:29AM -0600, Ian S. Nelson wrote: > Wasn't DES covered by a patent? I know Lucifer was and DES is closely > related. Patent or no patent, AES should be fairly liberal in terms of usage > restrictions. I don't remember the rules but I thought that there was some > provision for patents. The AES rules stipulated that it must be unencumbered by patents if it won and that entries that were patent encumbered before hand would be looked upon less favourably. > Anyone know who won yet? The NIST webcast page doesn't work. Rijndael. > Marc Mutz wrote: > > > Alex, it might be that we lose: > > > > "Michael H. Warfield" wrote on gnupg-devel: > > > > > > > > Serpent apparently is subject to a claim by Hitachi that it holds > > > a patent over some aspect of it. Rumor has it that it's out of the race. > > > That's based on a coderpunks posting which I have not been able to > > > independently verify. > > > > > > > > Marc slainte mhath, RGB - -- Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada Prevent Internet Wiretapping! -- FreeS/WAN: Thanks for voting Green! -- Marillion: -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBOdi3R9+sBuIhFagtAQGWggP/fwGm+9i7bsp9y+7DxOt3P/5Du601LWyT FR7IEA7XefayidWr9eNUASzBK6dJIj7cNG8hDjExbRJKiyD4DrkBmgcZsNnNxJNI pcs1IlmxkT1mri+N6MA0qnjxI1tpKlCigNd1h2ubskOk9xSPMhIhk4XavzBrLFjq ThUeEdikY/Y= =8hlS -----END PGP SIGNATURE----- Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Mon Oct 2 18:32:48 2000 Received: by humbolt.nl.linux.org id ; Mon, 2 Oct 2000 18:32:02 +0200 Received: from pc96.ma.rhbnc.ac.uk ([134.219.28.91]:50694 "EHLO pc96.ma.rhbnc.ac.uk") by humbolt.nl.linux.org with ESMTP id ; Mon, 2 Oct 2000 18:31:36 +0200 Received: from localhost (simos@localhost) by pc96.ma.rhbnc.ac.uk (8.9.3/8.9.3) with ESMTP id RAA02823; Mon, 2 Oct 2000 17:30:17 GMT Date: Mon, 2 Oct 2000 17:30:17 +0000 (GMT) From: Simos Xenitellis X-Sender: simos@pc96.ma.rhbnc.ac.uk Reply-To: Simos Xenitellis To: "Ian S. Nelson" cc: "linux-crypto@nl.linux.org" Subject: Re: [Fwd: AES for GnuPG, on Mon Oct 2?] In-Reply-To: <39D8B645.FA2F0368@echostar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Mon, 2 Oct 2000, Ian S. Nelson wrote: > Wasn't DES covered by a patent? I know Lucifer was and DES is closely > related. Patent or no patent, AES should be fairly liberal in terms of usage > restrictions. I don't remember the rules but I thought that there was some > provision for patents. At the NIST AES WWW site (http://csrc.nist.gov/encryption/aes/) it says: === SPECIAL NOTE - Intellectual Property NIST reminds all interested parties that the adoption of AES is being conducted as an open standards-setting activity. Specifically, NIST has requested that all interested parties identify to NIST any patents or inventions that may be required for the use of AES. NIST hereby gives public notice that it may seek redress under the antitrust laws of the United States against any party in the future who might seek to exercise patent rights against any user of AES that have not been disclosed to NIST in response to this request for information. === So, there is no worry. > > Anyone know who won yet? The NIST webcast page doesn't work. It is supposed to be announce on http://csrc.nist.gov/encryption/aes/, just keep refreshing the page. simos Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Mon Oct 2 18:42:09 2000 Received: by humbolt.nl.linux.org id ; Mon, 2 Oct 2000 18:41:43 +0200 Received: from pc96.ma.rhbnc.ac.uk ([134.219.28.91]:56838 "EHLO pc96.ma.rhbnc.ac.uk") by humbolt.nl.linux.org with ESMTP id ; Mon, 2 Oct 2000 18:41:13 +0200 Received: from localhost (simos@localhost) by pc96.ma.rhbnc.ac.uk (8.9.3/8.9.3) with ESMTP id RAA02849 for ; Mon, 2 Oct 2000 17:40:01 GMT Date: Mon, 2 Oct 2000 17:40:01 +0000 (GMT) From: Simos Xenitellis X-Sender: simos@pc96.ma.rhbnc.ac.uk Reply-To: Simos Xenitellis To: "linux-crypto@nl.linux.org" Subject: Semi-official announcement: Rijndael In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list From: Quisquater on USENET, sci.crypt, http://www.esat.kuleuven.ac.be/cosic/#press simos Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Mon Oct 2 18:49:47 2000 Received: by humbolt.nl.linux.org id ; Mon, 2 Oct 2000 18:49:06 +0200 Received: from eik.ii.uib.no ([129.177.16.3]:53136 "EHLO ii.uib.no") by humbolt.nl.linux.org with ESMTP id convert rfc822-to-8bit; Mon, 2 Oct 2000 18:48:35 +0200 Received: from kolibri.ii.uib.no [129.177.17.33] by ii.uib.no with esmtp (Exim 3.03) id 13g8lo-0000ro-00 for ; Mon, 02 Oct 2000 18:48:52 +0200 Received: (from gisle@localhost) by kolibri.ii.uib.no (8.9.3+Sun/8.9.3) id SAA23948; Mon, 2 Oct 2000 18:48:33 +0200 (MEST) Date: Mon, 2 Oct 2000 18:48:33 +0200 (MEST) From: Gisle S{lensminde To: linux-crypto@nl.linux.org Subject: Rijndael In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Is Rijndael working, now when it seems to have become AES? In changelog: * rijndael3.c updates from Marc Mutz should get this cipher working again. But in config.in you will find: +# Rijndael isn't working +# dep_tristate 'Rijndael cipher (EXPERIMENTAL)'\ CONFIG_CIPHER_RIJNDAEL $CONFIG_CIPHERS -- Gisle Sælensminde ( gisle@ii.uib.no ) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. (from RFC 1925) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Mon Oct 2 19:01:28 2000 Received: by humbolt.nl.linux.org id ; Mon, 2 Oct 2000 19:00:19 +0200 Received: from terra.geo.uu.nl ([131.211.29.16]:43220 "EHLO terra.geo.uu.nl") by humbolt.nl.linux.org with ESMTP id ; Mon, 2 Oct 2000 18:59:55 +0200 Received: from mail.uni-bielefeld.de (IDENT:72@mail2.uni-bielefeld.de [129.70.4.90]) by terra.geo.uu.nl (8.9.3/8.9.3/TvZ) with ESMTP id SAA24859 for ; Mon, 2 Oct 2000 18:59:54 +0200 (MET DST) Received: from Mutz.com (ppp36-352.hrz.uni-bielefeld.de [129.70.37.96]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G1T00695B48VI@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Mon, 2 Oct 2000 18:57:45 +0200 (MET DST) Date: Mon, 02 Oct 2000 16:56:40 +0000 From: Marc Mutz Subject: Re: Rijndael To: Gisle S{lensminde Cc: linux-crypto@nl.linux.org Message-id: <39D8BE48.70D064F3@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Gisle S{lensminde wrote: > > Is Rijndael working, now when it seems to have become AES? > No. > In changelog: > > * rijndael3.c updates from Marc Mutz should get > this cipher working again. > This was for people to play with and test. > But in config.in you will find: > > +# Rijndael isn't working > +# dep_tristate 'Rijndael cipher (EXPERIMENTAL)'\ > CONFIG_CIPHER_RIJNDAEL $CONFIG_CIPHERS > That is correct. It loads, registers, but on use it crashes the machine hard. Someone should look into it in userspace. I'm currently busy (it's not weekend, you know). Marc -- Marc Mutz http://marc.mutz.com/Encryption-HOWTO/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Tue Oct 3 12:35:24 2000 Received: by humbolt.nl.linux.org id ; Tue, 3 Oct 2000 12:34:59 +0200 Received: from midten.fast.no ([213.188.8.11]:24851 "EHLO midten.fast.no") by humbolt.nl.linux.org with ESMTP id ; Tue, 3 Oct 2000 12:34:40 +0200 Received: (from astor@localhost) by midten.fast.no (8.9.3/8.9.3) id MAA01581 for linux-crypto@nl.linux.org; Tue, 3 Oct 2000 12:34:34 +0200 (CEST) Date: Tue, 3 Oct 2000 12:34:33 +0200 From: Alexander S A Kjeldaas To: linux-crypto@nl.linux.org Subject: 2.2.17.7 Message-ID: <20001003123433.A98524@midten.fast.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list 2.2.17.7 is released with the AES cipher integrated. 2000-10-03 Alexander Kjeldaas * International kernel patch 2.2.17.7 released. * speed.c cleanups. * The crypto API now compiles when proc support has been disabled. * AES cipher added. The AES cipher is implemented by the rijndael module, but with a separate cipher id/name. * Updated Rijndael implementation from Brian Gladman merged. * ECB testvectors for rijndael from the AES submission added. This patch is available from: ftp.*.kernel.org:/pub/linux/kernel/crypto/v2.2/ astor -- Alexander Kjeldaas Mail: astor@fast.no finger astor@master.kernel.org for OpenPGP key. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Tue Oct 3 16:39:33 2000 Received: by humbolt.nl.linux.org id ; Tue, 3 Oct 2000 16:38:51 +0200 Received: from midten.fast.no ([213.188.8.11]:61456 "EHLO midten.fast.no") by humbolt.nl.linux.org with ESMTP id ; Tue, 3 Oct 2000 16:38:17 +0200 Received: (from astor@localhost) by midten.fast.no (8.9.3/8.9.3) id QAA11535; Tue, 3 Oct 2000 16:38:07 +0200 (CEST) Date: Tue, 3 Oct 2000 16:38:07 +0200 From: Alexander S A Kjeldaas To: Marc Mutz Cc: Gisle S{lensminde , linux-crypto@nl.linux.org Subject: Re: Rijndael Message-ID: <20001003163807.A11357@midten.fast.no> References: <39D8BE48.70D064F3@Mutz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <39D8BE48.70D064F3@Mutz.com>; from Marc Mutz on Mon, Oct 02, 2000 at 04:56:40PM +0000 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Mon, Oct 02, 2000 at 04:56:40PM +0000, Marc Mutz wrote: > That is correct. It loads, registers, but on use it crashes the > machine hard. Someone should look into it in userspace. I'm > currently busy (it's not weekend, you know). The current version works and passes the AES test vectors. astor -- Alexander Kjeldaas Mail: astor@fast.no finger astor@master.kernel.org for OpenPGP key. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Tue Oct 3 18:41:08 2000 Received: by humbolt.nl.linux.org id ; Tue, 3 Oct 2000 18:40:32 +0200 Received: from midten.fast.no ([213.188.8.11]:24583 "EHLO midten.fast.no") by humbolt.nl.linux.org with ESMTP id ; Tue, 3 Oct 2000 18:39:59 +0200 Received: (from astor@localhost) by midten.fast.no (8.9.3/8.9.3) id SAA16278; Tue, 3 Oct 2000 18:39:27 +0200 (CEST) Date: Tue, 3 Oct 2000 18:39:27 +0200 From: Alexander S A Kjeldaas To: Marc Mutz Cc: Alexander S A Kjeldaas , Gisle S{lensminde , linux-crypto@nl.linux.org Subject: Re: [experimantal patch] show allowed keylengths in /proc/cipher/* Message-ID: <20001003183926.A15764@midten.fast.no> References: <20001001131701.A23145@midten.fast.no> <20001002153332.A56132@midten.fast.no> <39D8A7C9.484C360F@Mutz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <39D8A7C9.484C360F@Mutz.com>; from Marc Mutz on Mon, Oct 02, 2000 at 03:20:41PM +0000 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Mon, Oct 02, 2000 at 03:20:41PM +0000, Marc Mutz wrote: [...] I buy the arguments. Having ciphers accept all kinds of keysizes will inevitably cause problems. astor -- Alexander Kjeldaas Mail: astor@fast.no finger astor@master.kernel.org for OpenPGP key. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Wed Oct 4 16:19:08 2000 Received: by humbolt.nl.linux.org id ; Wed, 4 Oct 2000 16:18:12 +0200 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:30943 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Wed, 4 Oct 2000 16:17:52 +0200 Received: from Mutz.com (ppp36-127.hrz.uni-bielefeld.de [129.70.36.127]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G1W00MAGT1P28@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Wed, 4 Oct 2000 16:17:50 +0200 (MET DST) Date: Wed, 04 Oct 2000 14:16:30 +0000 From: Marc Mutz Subject: [PATCH] crypto/Config.in reorganization To: linux-crypto@nl.linux.org Message-id: <39DB3BBE.C0F06E4@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586) Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_wwNkPZ1wv0O0WC39XR5bBA)" X-Accept-Language: en Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list This is a multi-part message in MIME format. --Boundary_(ID_wwNkPZ1wv0O0WC39XR5bBA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi! I've shuffled the entries in crypto/Config.in around a bit, grouping similar ciphers together and adding section titles. We now have: < > AES --- AES Finalists: ... Twofish, RC6, Serpent, MARS --- Other submissions to AES: < > DFC --- Other ciphers (64 bit blocksize): ... rest with DES being marked as deprecated. Please consider applying. Marc -- Marc Mutz http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) --Boundary_(ID_wwNkPZ1wv0O0WC39XR5bBA) Content-type: text/plain; name=Config.in-reorg-2.2.17.7.patch; charset=us-ascii Content-disposition: inline; filename=Config.in-reorg-2.2.17.7.patch Content-transfer-encoding: 7BIT --- i7/crypto/Config.in Tue Oct 3 19:55:10 2000 +++ i7-raidA0-raid1rb15.B2-ext0.0.3a/crypto/Config.in Wed Oct 4 16:10:56 2000 @@ -6,20 +6,23 @@ bool 'Crypto support' CONFIG_CRYPTO dep_tristate 'Crypto ciphers' CONFIG_CIPHERS $CONFIG_CRYPTO if [ "$CONFIG_CIPHERS" != "n" ]; then - dep_tristate 'Blowfish cipher (EXPERIMENTAL)' CONFIG_CIPHER_BLOWFISH $CONFIG_CIPHERS - dep_tristate 'Twofish cipher (EXPERIMENTAL)' CONFIG_CIPHER_TWOFISH $CONFIG_CIPHERS - dep_tristate 'DES cipher (EXPERIMENTAL)' CONFIG_CIPHER_DES $CONFIG_CIPHERS - dep_tristate 'DES EDE3 cipher (3DES, EXPERIMENTAL)' CONFIG_CIPHER_DES_EDE3 $CONFIG_CIPHERS - dep_tristate 'DFC cipher (EXPERIMENTAL)' CONFIG_CIPHER_DFC $CONFIG_CIPHERS - dep_tristate 'IDEA cipher (EXPERIMENTAL)' CONFIG_CIPHER_IDEA $CONFIG_CIPHERS - dep_tristate 'MARS cipher (EXPERIMENTAL)' CONFIG_CIPHER_MARS $CONFIG_CIPHERS - dep_tristate 'RC5 cipher (EXPERIMENTAL)' CONFIG_CIPHER_RC5 $CONFIG_CIPHERS - dep_tristate 'RC6 cipher (EXPERIMENTAL)' CONFIG_CIPHER_RC6 $CONFIG_CIPHERS dep_tristate 'AES cipher (EXPERIMENTAL)' CONFIG_CIPHER_AES $CONFIG_CIPHERS if [ "$CONFIG_CIPHER_AES" != "n" ]; then bool 'AES available under the Rijndael name' CONFIG_CIPHER_RIJNDAEL fi + comment 'AES Finalist Ciphers:' + dep_tristate 'Twofish cipher (EXPERIMENTAL)' CONFIG_CIPHER_TWOFISH $CONFIG_CIPHERS + dep_tristate 'MARS cipher (EXPERIMENTAL)' CONFIG_CIPHER_MARS $CONFIG_CIPHERS + dep_tristate 'RC6 cipher (EXPERIMENTAL)' CONFIG_CIPHER_RC6 $CONFIG_CIPHERS dep_tristate 'Serpent cipher (EXPERIMENTAL)' CONFIG_CIPHER_SERPENT $CONFIG_CIPHERS + comment 'Other Ciphers submitted as AES Candidates:' + dep_tristate 'DFC cipher (EXPERIMENTAL)' CONFIG_CIPHER_DFC $CONFIG_CIPHERS + comment 'Other ciphers (64 bit blocksize)' + dep_tristate 'Blowfish cipher (EXPERIMENTAL)' CONFIG_CIPHER_BLOWFISH $CONFIG_CIPHERS + dep_tristate 'IDEA cipher (EXPERIMENTAL)' CONFIG_CIPHER_IDEA $CONFIG_CIPHERS + dep_tristate 'RC5 cipher (EXPERIMENTAL)' CONFIG_CIPHER_RC5 $CONFIG_CIPHERS + dep_tristate 'DES EDE3 cipher (3DES, EXPERIMENTAL)' CONFIG_CIPHER_DES_EDE3 $CONFIG_CIPHERS + dep_tristate 'DES cipher (DEPRECATED)' CONFIG_CIPHER_DES $CONFIG_CIPHERS fi dep_tristate 'Digest algorithms' CONFIG_DIGEST $CONFIG_CRYPTO if [ "$CONFIG_DIGEST" != "n" ]; then --Boundary_(ID_wwNkPZ1wv0O0WC39XR5bBA)-- Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Wed Oct 4 16:19:27 2000 Received: by humbolt.nl.linux.org id ; Wed, 4 Oct 2000 16:18:32 +0200 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:30175 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Wed, 4 Oct 2000 16:17:53 +0200 Received: from Mutz.com (ppp36-127.hrz.uni-bielefeld.de [129.70.36.127]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G1W00M18T1LV0@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Wed, 4 Oct 2000 16:17:48 +0200 (MET DST) Date: Wed, 04 Oct 2000 14:01:55 +0000 From: Marc Mutz Subject: [PATCH] Configure.help updates for AES. To: linux-crypto@nl.linux.org Message-id: <39DB3853.2C6BAFC3@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586) Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_j1CyrzqPKb+Cul7zxa1Xjw)" X-Accept-Language: en Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list This is a multi-part message in MIME format. --Boundary_(ID_j1CyrzqPKb+Cul7zxa1Xjw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi! Subject says it all. Please check and consider applying. Marc -- Marc Mutz http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) --Boundary_(ID_j1CyrzqPKb+Cul7zxa1Xjw) Content-type: text/plain; name=Configure.help-2.2.17.7.patch; charset=us-ascii Content-disposition: inline; filename=Configure.help-2.2.17.7.patch Content-transfer-encoding: 7BIT --- Configure.help~ Tue Oct 3 20:03:06 2000 +++ Configure.help Wed Oct 4 15:28:53 2000 @@ -365,6 +365,54 @@ If unsure, say 'N'. +AES cipher (EXPERIMENTAL - Read Help) +CONFIG_CIPHER_AES + [2000-10-04] + DESCRIPTION: + AES (Advanced Encryption Standard) is a proposed Federal Information + Processing Standard (FIPS) of the USA. Nevertheless, it was + conceived by Joan Daemon and Vincent Rijmen, two Belgians, under the + name Rijndael and submitted to the AES selection process in 1997 + (http://www.nist.gov/aes). On Oct 2, 2000 it was announced as being + the selected algorithm for the AES. + + Rijndael is a variable-round iterated block cipher that supports + block and key sizes each ranging from 128 to 256 bits, in steps of + 64. The number of rounds is dependant on the block and key sizes and + varies from 10 for 128/128 to 14 for 256/256 block/key sizes. + + SPPED: N/A + + PATENTS and LICENSING: + Rijndeal/AES is free of patents. As beign AES, NIST will ensure that + this will stay so. + + KNOWN ATTACKS: + None of the following attacks is able to undermine the security of + AES, when used with the round numbers specified by the authors. + + The original Rijndael specification contains a truncated + differential attack on 4,5 resp. 6 round versions ("Square attack") + requiring 2^9, 2^11 resp. 2^32 plaintexts and 2^9, 2^40 resp. 2^72 + work. There is another truncated differential attack that leads to a + collision attack on 7 round 192 and 256 bit keysize Rijndael + requiring 2^32 plaintext encryptions and 2^140 work. Other authors + extend the original Square attack to 7 rounds of 192 and 256 bit + keysize, both with more that 2^184 work. Further improvements of + these techniques result in attacks against 7 and 8 round + variants. But the latter require almost all of the codebook. At + last, there is a related key attack against 9 round, 256 bit keysize + Rijndael that requires 2^77 chosen plaintexts and 2^224 work. + +AES available under the Rijndael name +CONFIG_CIPHER_RIJNDAEL + If you say 'Y' here, AES will be also accessible through its + original name Rijndael. This is mostly for backwards compatibilty. + If you use kernel modules that use Rijndael, but do not know that it + is now called AES, say 'Y' here. + + If unsure, say 'N'. + DFC encryption (EXPERIMENTAL - Read Help) CONFIG_CIPHER_DFC [2000-09-13] @@ -390,7 +438,7 @@ CONFIG_CIPHER_MARS [2000-09-13] DESCRIPTION: - MARS is IBM's candidate algorithm for the Advanded Encryption + MARS was IBM's candidate algorithm for the Advanded Encryption Standard (AES). It consists of 16 core rounds and eight pre-mixing as well as eight post-mixing rounds. @@ -417,7 +465,7 @@ CONFIG_CIPHER_RC6 [2000-09-13] DESCRIPTION: - RC6 is invented by Ron Rivest and RSA Labs. It is one of the five + RC6 is invented by Ron Rivest and RSA Labs. It was one of the five candidates in round two for the Advanced Encryption Standard (AES). PATENTS and LICENSING: @@ -446,7 +494,7 @@ DESCRIPTION: Serpent is a 128-bit block cipher designed by Ross Anderson, Eli Biham and Lars Knudsen as a candidate for the Advanced Encryption - Standard (AES, see http://www.nist.gov/aes). It is one of the five + Standard (AES, see http://www.nist.gov/aes). It was one of the five finalists after round two of the AES candidate search. Serpent provides users with the highest practical level of assurance that no shortcut attack will be found. To achieve this, the algorithm uses --Boundary_(ID_j1CyrzqPKb+Cul7zxa1Xjw)-- Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Wed Oct 4 16:37:45 2000 Received: by humbolt.nl.linux.org id ; Wed, 4 Oct 2000 16:36:55 +0200 Received: from midten.fast.no ([213.188.8.11]:31749 "EHLO midten.fast.no") by humbolt.nl.linux.org with ESMTP id ; Wed, 4 Oct 2000 16:36:36 +0200 Received: (from astor@localhost) by midten.fast.no (8.9.3/8.9.3) id QAA57644; Wed, 4 Oct 2000 16:36:32 +0200 (CEST) Date: Wed, 4 Oct 2000 16:36:32 +0200 From: Alexander S A Kjeldaas To: Marc Mutz Cc: linux-crypto@nl.linux.org Subject: Re: Using kerneli w/o compiling a kernel? Message-ID: <20001004163632.C52432@midten.fast.no> References: <39D8A439.BD141DDB@Mutz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <39D8A439.BD141DDB@Mutz.com>; from Marc Mutz on Mon, Oct 02, 2000 at 03:05:29PM +0000 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Mon, Oct 02, 2000 at 03:05:29PM +0000, Marc Mutz wrote: > Hi! > > I've run into the problem of explaining how to make an encrypted folder > with kerneli to someone who merely survived a linux install. I kow that > the answer to the following is NO, but does someone out there know of > RPMs for the major dirtributions of both the kernel modules and the > patched mount and losetup? Is anyone willing to do this or tell me how > to? This would greatly simplify my task. > > However if - as is expected - the answer to the above question is NO, is > there a way to completely module out the kerneli parts so that there is > no need to recompile the kernel. I know that everything can be compiled > as modules, but when I try this, I don't get a cryptoapi.o module. I've > selected it as being a module, but is is compiled into the kernel > nevertheless: > Could you try 2.2.17.8.pre1 available from ftp.*.kernel.org:/pub/linux/kernel/people/astor/v2.2/. It includes quite a few other changes as well. For example, DEFINE_CIPHER et.al is gone. astor -- Alexander Kjeldaas Mail: astor@fast.no finger astor@master.kernel.org for OpenPGP key. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Wed Oct 4 20:56:07 2000 Received: by humbolt.nl.linux.org id ; Wed, 4 Oct 2000 20:55:32 +0200 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:45379 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Wed, 4 Oct 2000 20:54:58 +0200 Received: from Mutz.com (ppp36-382.hrz.uni-bielefeld.de [129.70.37.126]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G1X007OT5VEBS@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Wed, 4 Oct 2000 20:54:56 +0200 (MET DST) Date: Wed, 04 Oct 2000 18:54:08 +0000 From: Marc Mutz Subject: Re: Using kerneli w/o compiling a kernel? To: Alexander S A Kjeldaas Cc: linux-crypto@nl.linux.org Message-id: <39DB7CD0.421C5A7F@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <39D8A439.BD141DDB@Mutz.com> <20001004163632.C52432@midten.fast.no> Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Alexander S A Kjeldaas wrote: > > Could you try 2.2.17.8.pre1 available from > ftp.*.kernel.org:/pub/linux/kernel/people/astor/v2.2/. It includes > quite a few other changes as well. For example, DEFINE_CIPHER et.al > is gone. This change breaks my blowfish crypted fs. Initially, I thought it was due to the restriction of blowfish to 128 192 and 256 bits, but after adding 160, which is what losetup uses, things stayed broken. I also tried loading blowish.o from i7, but that had unresolved dependencies on depmod -a. I havn't looked further into this as blowfish.c and there seems to be nothing unusual there. Also, when loading blowfish (or rijndael), they don't show up in /proc/cipher/. However, the directory is there. The issues might well be in cryptoapi.c Marc PS: Now that I need a devel machine, 50% of your laptops are broken :-( -- Marc Mutz http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Wed Oct 4 21:27:27 2000 Received: by humbolt.nl.linux.org id ; Wed, 4 Oct 2000 21:26:53 +0200 Received: from [216.168.105.33] ([216.168.105.33]:14587 "HELO mail.fibrespeed.net") by humbolt.nl.linux.org with SMTP id ; Wed, 4 Oct 2000 21:26:16 +0200 Received: (qmail 25365 invoked from network); 4 Oct 2000 19:26:12 -0000 Received: from unknown (508@216.168.105.34) by 216.168.105.35 with QMQP; 4 Oct 2000 19:26:12 -0000 Received: from mike.hosted.fibrespeed.net (HELO scanner) (192.168.10.12) by 216.168.105.33 with SMTP; 4 Oct 2000 19:26:11 -0000 Message-ID: <011b01c02e39$41324140$0c0aa8c0@hosted.fibrespeed.net> From: "Michael T. Babcock" To: "Alexander S A Kjeldaas" , "Gisle S{lensminde" Cc: "Alexander S A Kjeldaas" , References: <20001001131701.A23145@midten.fast.no> <20001002153332.A56132@midten.fast.no> Subject: Re: [experimantal patch] show allowed keylengths in /proc/cipher/* Date: Wed, 4 Oct 2000 15:28:19 -0400 Organization: FibreSpeed MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list > If we construct a 3DES-specific key-munging algorithm, it will be > "incompatible" with other software to a certain extent, and that's a > bad thing. I'm just trying to show/make sure that all ciphers _can_ > handle a keys of variable length, so that the user of a crypto library > doesn't need to care about these issues. If the user doesn't need to > care about these issues, the interface doesn't have to be more > complex. I am no cryptographer so there might well be more traps with > such an approach though, so do not expect something like this to > appear right away. I think it would be most beneficial here to definately consult with a real cryptographer if 'we' want to know how to handle this correctly. There may or may not be a paper written somewhere on the issue too. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Wed Oct 4 22:02:58 2000 Received: by humbolt.nl.linux.org id ; Wed, 4 Oct 2000 22:02:10 +0200 Received: from midten.fast.no ([213.188.8.11]:27411 "EHLO midten.fast.no") by humbolt.nl.linux.org with ESMTP id ; Wed, 4 Oct 2000 22:01:42 +0200 Received: (from astor@localhost) by midten.fast.no (8.9.3/8.9.3) id WAA69989; Wed, 4 Oct 2000 22:01:38 +0200 (CEST) Date: Wed, 4 Oct 2000 22:01:38 +0200 From: Alexander S A Kjeldaas To: Marc Mutz Cc: Alexander S A Kjeldaas , linux-crypto@nl.linux.org Subject: Re: Using kerneli w/o compiling a kernel? Message-ID: <20001004220138.A69211@midten.fast.no> References: <39D8A439.BD141DDB@Mutz.com> <20001004163632.C52432@midten.fast.no> <39DB7CD0.421C5A7F@Mutz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <39DB7CD0.421C5A7F@Mutz.com>; from Marc Mutz on Wed, Oct 04, 2000 at 06:54:08PM +0000 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Wed, Oct 04, 2000 at 06:54:08PM +0000, Marc Mutz wrote: > > This change breaks my blowfish crypted fs. > Initially, I thought it was due to the restriction of blowfish to 128 > 192 and 256 bits, but after adding 160, which is what losetup uses, > things stayed broken. I also tried loading blowish.o from i7, but that > had unresolved dependencies on depmod -a. > I havn't looked further into this as blowfish.c and there seems to be > nothing unusual there. > > Also, when loading blowfish (or rijndael), they don't show up in > /proc/cipher/. However, the directory is there. > > The issues might well be in cryptoapi.c > Expect some blow-ups from a pre-patch ;-). I'll look at it tomorrow. cryptoapi.c was pretty much rewritten, so yes, it is most probably buggy. Did the ciphers register on bootup/insmod? astor -- Alexander Kjeldaas Mail: astor@fast.no finger astor@master.kernel.org for OpenPGP key. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Wed Oct 4 23:04:18 2000 Received: by humbolt.nl.linux.org id ; Wed, 4 Oct 2000 23:03:42 +0200 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:37207 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Wed, 4 Oct 2000 23:03:11 +0200 Received: from Mutz.com (ppp36-226.hrz.uni-bielefeld.de [129.70.36.226]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G1X00BH8BT9C0@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Wed, 4 Oct 2000 23:03:09 +0200 (MET DST) Date: Wed, 04 Oct 2000 20:56:23 +0000 From: Marc Mutz Subject: [Encryption-HOWTO] v0.2.2 released To: linux-crypto@nl.linux.org Message-id: <39DB9977.A160609F@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list ChangeLog: - Small updates because of AES. - Encryption-HOWTO now on sourceforge.net - Updates to the Journalling Q. - Updates from Sandy Harris regarding FreeS/WAN. Release Notes: Maintainance version only. Needed because of the advent of AES in kerneli-2.2.17.7. Marc -- Marc Mutz http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Wed Oct 4 23:08:25 2000 Received: by humbolt.nl.linux.org id ; Wed, 4 Oct 2000 23:07:50 +0200 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:8280 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Wed, 4 Oct 2000 23:07:22 +0200 Received: from Mutz.com (ppp36-283.hrz.uni-bielefeld.de [129.70.37.27]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G1X00C1JC08TK@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Wed, 4 Oct 2000 23:07:21 +0200 (MET DST) Date: Wed, 04 Oct 2000 21:06:26 +0000 From: Marc Mutz Subject: Re: Using kerneli w/o compiling a kernel? To: Alexander S A Kjeldaas Cc: linux-crypto@nl.linux.org Message-id: <39DB9BD2.A020C08@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <39D8A439.BD141DDB@Mutz.com> <20001004163632.C52432@midten.fast.no> <39DB7CD0.421C5A7F@Mutz.com> <20001004220138.A69211@midten.fast.no> Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Alexander S A Kjeldaas wrote: > > Did the ciphers register on bootup/insmod? > Yes. Marc -- Marc Mutz http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Thu Oct 5 10:47:06 2000 Received: by humbolt.nl.linux.org id ; Thu, 5 Oct 2000 10:46:29 +0200 Received: from midten.fast.no ([213.188.8.11]:34824 "EHLO midten.fast.no") by humbolt.nl.linux.org with ESMTP id ; Thu, 5 Oct 2000 10:46:04 +0200 Received: (from astor@localhost) by midten.fast.no (8.9.3/8.9.3) id KAA88163; Thu, 5 Oct 2000 10:45:56 +0200 (CEST) Date: Thu, 5 Oct 2000 10:45:55 +0200 From: Alexander S A Kjeldaas To: Marc Mutz Cc: Alexander S A Kjeldaas , linux-crypto@nl.linux.org Subject: Re: Using kerneli w/o compiling a kernel? Message-ID: <20001005104554.A88082@midten.fast.no> References: <39D8A439.BD141DDB@Mutz.com> <20001004163632.C52432@midten.fast.no> <39DB7CD0.421C5A7F@Mutz.com> <20001004220138.A69211@midten.fast.no> <39DB9BD2.A020C08@Mutz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <39DB9BD2.A020C08@Mutz.com>; from Marc Mutz on Wed, Oct 04, 2000 at 09:06:26PM +0000 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Wed, Oct 04, 2000 at 09:06:26PM +0000, Marc Mutz wrote: > Alexander S A Kjeldaas wrote: > > > > > Did the ciphers register on bootup/insmod? > > > > Yes. > Try 2.2.17.8.pre2. The /proc/cipher and /proc/digest entries were switched. astor -- Alexander Kjeldaas Mail: astor@fast.no finger astor@master.kernel.org for OpenPGP key. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Thu Oct 5 18:04:54 2000 Received: by humbolt.nl.linux.org id ; Thu, 5 Oct 2000 18:04:21 +0200 Received: from storm.ca ([209.87.239.69]:55539 "EHLO mail.storm.ca") by humbolt.nl.linux.org with ESMTP id ; Thu, 5 Oct 2000 18:03:54 +0200 Received: from storm.ca (ppp072.ottawa.storm.ca [209.87.255.72]) by mail.storm.ca (8.9.3+Sun/8.9.3) with ESMTP id MAA04032; Thu, 5 Oct 2000 12:03:45 -0400 (EDT) Message-ID: <39DCA699.2F1FA02A@storm.ca> Date: Thu, 05 Oct 2000 12:04:41 -0400 From: Sandy Harris X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 Followup-To: linux-crypto@nl.linux.org To: Crispin Cowan CC: Marc Mutz , linux-ipsec@clinet.fi, linux-crypto@nl.linux.org Subject: Re: linux-ipsec: freeswan .... using OpenSSL ? References: <39DB7F0F.A96F2092@Mutz.com> <39DC357D.1A18F242@wirex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Crispin Cowan wrote: > > Marc Mutz wrote: > > > > > > Oh yes, it would be nice if the library didn't insist on inventing its own > > > big-number support, but used the existing GMP library. > > > > > > You won't ever be able to get public-key encryption into the kernel > > proper (and there is no reason to try), so what do you want big number > > support for? > > Actually, we already have both bignum support and public key crypto in the > kernel for this project http://immunix.org/cryptomark.html > > We use it to do crypto certification of executables, so as to prevent trojan > horse attacks. > > It will be released under the GPL, as it is a union of the Linux kernel and the > GPG code body. Unfortunately for freeswan, it has American taint. Methinks this is no longer FreeS/WAN-specific and should continue on the linux-crypto@nl.linux.org list. We need quite a lot of crypto in the kernel: FreeS/WAN currently has 3DES, and HMAC authentication based on SHA and MD5. It is almost certain to add Rijndael at some point and likely any successor to SHA that NIST standardises as well. The RFCs allow other algorithms for both authentication and encryption, and some IPSEC implementations support them (e.g. PGPnet uses CAST-128) but FreeS/WAN is unlikely to use those. Note that IPv6 requires IPSEC, so at some point this all needs to be in the standard kernel. Last I looked, /dev/random could use SHA or MD5 for the main stuff, but for some reason also had MD4 included in the TCP nonce code. Your stuff needs bignums and public key operations. Methinks these are necessary for any signature scheme. Will DNS security require similar things, or is all its key validation done in user space? Do the encrypting file systems require anything besides a good block cipher? So what does it take to get a library into the kernel that does at least: 3DES Rijndael SHA hash (initialise with fixed constants) SHA HMAC (initialise with secret key material) public key primitives (probably signature only) What else is necessary or desirable? Would the maintainers of the various packages use such a library? Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Thu Oct 5 18:13:04 2000 Received: by humbolt.nl.linux.org id ; Thu, 5 Oct 2000 18:12:07 +0200 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:31156 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Thu, 5 Oct 2000 18:11:34 +0200 Received: from Mutz.com (ppp36-172.hrz.uni-bielefeld.de [129.70.36.172]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G1Y007KISZ87Q@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Thu, 5 Oct 2000 18:11:33 +0200 (MET DST) Date: Thu, 05 Oct 2000 13:50:51 +0000 From: Marc Mutz Subject: Re: [experimantal patch] show allowed keylengths in /proc/cipher/* To: "Michael T. Babcock" Cc: linux-crypto@nl.linux.org Message-id: <39DC873B.B5A9C5DA@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <20001001131701.A23145@midten.fast.no> <20001002153332.A56132@midten.fast.no> <011b01c02e39$41324140$0c0aa8c0@hosted.fibrespeed.net> Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list "Michael T. Babcock" wrote: > > > I think it would be most beneficial here to definately consult with a real > cryptographer if 'we' want to know how to handle this correctly. There may > or may not be a paper written somewhere on the issue too. > You don't need a 'real' cryptographer (better. cryptanalyst or cryptologist) to understand that Rijndael was defined for key lengths of 128 to 256 bits in steps of 32 bits. Look at it's structure and you'll understand why. Twofish was defined for 128, 192 and 256 bits, but with a description of how to handle key lengths that don't match the defined ones. The point here is that if you leave the path that the authors of the algorithm have drawn or that is described in a standard somewhere, you'll lose all cryptanalytic results obtained for that cipher. So you should simply stay with the definition of the cipher. The AES committee has refused to alter the definitions of the finalist ciphers precisely because adding or subtracting rounds would invalidate all or most of the cryptanalysis obtained in the review period. This was although the common feeling after AES3 was that Rijndael should be elected with added rounds. Marc -- Marc Mutz http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Thu Oct 5 18:14:28 2000 Received: by humbolt.nl.linux.org id ; Thu, 5 Oct 2000 18:12:39 +0200 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:35764 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Thu, 5 Oct 2000 18:11:49 +0200 Received: from Mutz.com (ppp36-172.hrz.uni-bielefeld.de [129.70.36.172]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G1Y007G7SZG9I@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Thu, 5 Oct 2000 18:11:48 +0200 (MET DST) Date: Thu, 05 Oct 2000 16:11:12 +0000 From: Marc Mutz Subject: Re: Using kerneli w/o compiling a kernel? To: Alexander S A Kjeldaas Cc: linux-crypto@nl.linux.org Message-id: <39DCA820.D47A97D3@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <39D8A439.BD141DDB@Mutz.com> <20001004163632.C52432@midten.fast.no> <39DB7CD0.421C5A7F@Mutz.com> <20001004220138.A69211@midten.fast.no> <39DB9BD2.A020C08@Mutz.com> <20001005104554.A88082@midten.fast.no> Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Alexander S A Kjeldaas wrote: > > Try 2.2.17.8.pre2. The /proc/cipher and /proc/digest entries were > switched. > Now the ciphers show up in /proc/ciphers. But losetup or mount on my blowfish fs gives me an invalid argument on the LOOP_SET_STATUS ioctl. I wonder where this stems from. There are no changes in loop_gen.c or loop.c that could do this, also the introduction of the keysize_mask does not contribute because it is currently purely cosmetic. On the other hand, the changes in cryptoapi.c are so complex that looking at a unified diff makes one lose grip on the context, primarily because I have not yet dug into this too deep. LOOP_SET_STATUS can return EINVAL on: loop.c:557: if lo_encrypt_key_size > LO_KEY_SIZE loop.c:486: if type >= MAX_LO_CRYPT and if xfer_funcs[type] is 0 and a module load fails. also, if xfer->release(lo) or xfer->init(lo,i) return EINVAL. loop_gen_release: always return 0; loop_gen_init2: returns EINVAL if - find_cipher_by_id fails - ci->set_key() fails (i.e. does not return 0). So I suspect the error to be in find_cipher_by_id(), which is now defined a find_transform_by_id(id, TRANSFORM_CIPHER). Here I don't understand why you treat tg different from the way you did before. Prior, it was defined as a pointer to struct transform_group, just like now. The difference being that it is now a local variable where it was a function argument before. Yet, you now write Q> read_lock(&tg->tg_lock) where you wrote Q> read_lock(tg-tg_lock) before? Marc -- Marc Mutz http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Thu Oct 5 18:40:55 2000 Received: by humbolt.nl.linux.org id ; Thu, 5 Oct 2000 18:40:23 +0200 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:33724 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Thu, 5 Oct 2000 18:39:53 +0200 Received: from Mutz.com (ppp36-342.hrz.uni-bielefeld.de [129.70.37.86]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G1Y008KFUAFBP@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Thu, 5 Oct 2000 18:39:52 +0200 (MET DST) Date: Thu, 05 Oct 2000 16:32:24 +0000 From: Marc Mutz Subject: Re: linux-ipsec: freeswan .... using OpenSSL ? To: Sandy Harris Cc: Crispin Cowan , linux-crypto@nl.linux.org Message-id: <39DCAD18.80F51650@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <39DB7F0F.A96F2092@Mutz.com> <39DC357D.1A18F242@wirex.com> <39DCA699.2F1FA02A@storm.ca> Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Sandy Harris wrote: > > Do the encrypting file systems require anything besides a good block cipher? > No. > So what does it take to get a library into the kernel that does at least: > > 3DES > Rijndael > SHA hash (initialise with fixed constants) We have all that already in kerneli. > SHA HMAC (initialise with secret key material) probably trivial to add. > public key primitives (probably signature only) > I thought that Pk encryption was only used for key exchange. That could happily live in userspace. However, I now wonder how authentication is done? Is is done via symmetric enciphering of the hash value or using PK? If it's the latter, does all and every IPv6 packet require a PK run? Good bye performance. I should look at the RFC's But it's so _much_ stuff. There is shorter treatment by TimeStep and I'll look at it _now_. .... OK, apparently AH consists of a MAC, and that should be SHA HMAC, no? So where is the need for PK in IPSec other than probably for key exchange? > What else is necessary or desirable? Would the maintainers of the various > packages use such a library? Apparently not. The kerneli patch is out there since 1998 and the only user of this is still loopback crypto. I have not heard of a reason for why it is not used, except maybe from the FreeS/WAN people: It's not free of US hands. Hmm, maybe it is? Most cipher implementations are taken from Brian Gladman, according to his homepage location he's a UK citizen. Alex, Gisle and myself from Norway (?) and Germany, resp. Sorry for the train of toughts running over you all... marc -- Marc Mutz http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Thu Oct 5 19:06:24 2000 Received: by humbolt.nl.linux.org id ; Thu, 5 Oct 2000 19:05:50 +0200 Received: from storm.ca ([209.87.239.69]:12674 "EHLO mail.storm.ca") by humbolt.nl.linux.org with ESMTP id ; Thu, 5 Oct 2000 19:05:07 +0200 Received: from storm.ca (ppp072.ottawa.storm.ca [209.87.255.72]) by mail.storm.ca (8.9.3+Sun/8.9.3) with ESMTP id NAA13188 for ; Thu, 5 Oct 2000 13:05:04 -0400 (EDT) Message-ID: <39DCB4F9.47EEFE3B@storm.ca> Date: Thu, 05 Oct 2000 13:06:01 -0400 From: Sandy Harris X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: linux-crypto@nl.linux.org Subject: Re: linux-ipsec: freeswan .... using OpenSSL ? References: <39DB7F0F.A96F2092@Mutz.com> <39DC357D.1A18F242@wirex.com> <39DCA699.2F1FA02A@storm.ca> <39DCAD18.80F51650@Mutz.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Marc Mutz wrote: > > Sandy Harris wrote: > > > > > Do the encrypting file systems require anything besides a good block cipher? > > > > No. > > > So what does it take to get a library into the kernel that does at least: > > > > 3DES > > Rijndael > > SHA hash (initialise with fixed constants) > > We have all that already in kerneli. > > > SHA HMAC (initialise with secret key material) > > probably trivial to add. > > > public key primitives (probably signature only) > > > I thought that Pk encryption was only used for key exchange. That could > happily live in userspace. Yes, for IPSEC. But if you want the kernel to authenticate binaries before loading them, then you may need public key stuff in the kernel. > However, I now wonder how authentication is > done? Is is done via symmetric enciphering of the hash value or using > PK? If it's the latter, does all and every IPv6 packet require a PK run? > Good bye performance. For IPSEC, you use the public key stuff to authenticate a key negotiation, preventing a man-in-the-middle from posing as either player and subverting the negotiation. The negotiation produces an encryption key and an HMAC key. Packet authentication is done with the HMAC. This is an SHA or MD5 hash of the packet data, except with the registers in the hashing code initialised from the HMAC key rather than from standard constants. It therefore does more than a simple hash would, authenticating not just that the packet data was not changed in transit but also that the sender knew the HMAC key. > I should look at the RFC's But it's so _much_ stuff. There is shorter > treatment by TimeStep and I'll look at it _now_. > .... > OK, apparently AH consists of a MAC, and that should be SHA HMAC, no? So > where is the need for PK in IPSec other than probably for key exchange? For IPSEC, there's no need I can see. To secure program loads, though, you appear to need some variant of PK to sign the executables. I wonder if that could be in a user-space loader though, rather than the kernel. Or would some variant of the HMAC scheme be enough to control loading? Instead of a signature on each file, just store an HMAC? Checking it shows both that the file is uncorrupted and that the storer had the required key. Overheads are essentially identical to calculating a hash. Methinks you need the hash anyway to verify non-corruption. For a public key signature you need both the hash and the public key operations, so this is much cheaper. Of course this can be subverted by an attacker who has root on the machine, but so can the public key scheme, I think. > > What else is necessary or desirable? Would the maintainers of the various > > packages use such a library? > > Apparently not. The kerneli patch is out there since 1998 and the only > user of this is still loopback crypto. I have not heard of a reason for > why it is not used, except maybe from the FreeS/WAN people: It's not > free of US hands. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Thu Oct 5 21:50:30 2000 Received: by humbolt.nl.linux.org id ; Thu, 5 Oct 2000 21:49:55 +0200 Received: from eik.ii.uib.no ([129.177.16.3]:36961 "EHLO ii.uib.no") by humbolt.nl.linux.org with ESMTP id convert rfc822-to-8bit; Thu, 5 Oct 2000 21:49:18 +0200 Received: from apal.ii.uib.no [129.177.16.7] by ii.uib.no with esmtp (Exim 3.03) id 13hH1O-0004W8-00 ; Thu, 05 Oct 2000 21:49:38 +0200 Received: (from gisle@localhost) by apal.ii.uib.no (8.8.8+Sun/8.8.7) id VAA04824; Thu, 5 Oct 2000 21:49:15 +0200 (MET DST) Date: Thu, 5 Oct 2000 21:49:15 +0200 (MET DST) From: Gisle S{lensminde To: Sandy Harris cc: Crispin Cowan , Marc Mutz , linux-ipsec@clinet.fi, linux-crypto@nl.linux.org Subject: Re: linux-ipsec: freeswan .... using OpenSSL ? In-Reply-To: <39DCA699.2F1FA02A@storm.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Thu, 5 Oct 2000, Sandy Harris wrote: > > So what does it take to get a library into the kernel that does at least: > > 3DES > Rijndael > SHA hash (initialise with fixed constants) > SHA HMAC (initialise with secret key material) > public key primitives (probably signature only) Marc has told what things that is found in kerneli. Now Freeswan/ipsec uses Eric Young's libdes, which both has a fast C implementation and a fast x86 implementation. Unfortunatly it is specially stated in the library source that the code is not GPL, and cannot be changed to GPL either. this code cannot simply be copied and put under another distrubution license [including the GNU Public License.] AFAIK, this means that the code cannot simply be put into the crypto- API without permission. Do you think it's possible to get the necessary permission to insert the the libdes 3DES implementation into the kernel. -- Gisle Sælensminde ( gisle@ii.uib.no ) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. (from RFC 1925) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Thu Oct 5 23:08:11 2000 Received: by humbolt.nl.linux.org id ; Thu, 5 Oct 2000 23:07:35 +0200 Received: from [195.84.105.112] ([195.84.105.112]:7868 "EHLO petrus.schuldei.org") by humbolt.nl.linux.org with ESMTP id ; Thu, 5 Oct 2000 23:07:01 +0200 Received: from gabriel.schuldei.com (gabriel.schuldei.com [192.168.1.1]) by petrus.schuldei.org (Postfix) with ESMTP id 59C404CEB0 for ; Thu, 5 Oct 2000 23:10:13 +0200 (CEST) Received: from sigrid.schuldei.com (sigrid.schuldei.com [192.168.1.11]) by gabriel.schuldei.com (Postfix) with ESMTP id 6D44D17553 for ; Thu, 5 Oct 2000 23:10:13 +0200 (CEST) Received: by sigrid.schuldei.com (Postfix, from userid 1000) id DA5D365736; Thu, 5 Oct 2000 23:07:52 +0200 (CEST) Date: Thu, 5 Oct 2000 23:07:52 +0200 From: Andreas Schuldei To: linux-crypto@nl.linux.org Subject: fast encryption of large files with asymetric keys Message-ID: <20001005230752.A6092@sigrid.schuldei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Is there a program/lib/... for fast encryption of large files with asymetric keys? gpg would do, but the minimal keylegth is 768 and with that key it is to slow. In fact a much smaller key would do. 60-200 Bits should be enough. Is there such a beast? Where? Please cc me, i am not on this list. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Thu Oct 5 23:29:30 2000 Received: by humbolt.nl.linux.org id ; Thu, 5 Oct 2000 23:28:44 +0200 Received: from spsystems.net ([209.47.149.227]:18963 "EHLO spsystems.net") by humbolt.nl.linux.org with ESMTP id ; Thu, 5 Oct 2000 23:28:15 +0200 Received: (from henry@localhost) by spsystems.net (8.9.3/8.9.3) id RAA22626; Thu, 5 Oct 2000 17:27:59 -0400 (EDT) Date: Thu, 5 Oct 2000 17:27:59 -0400 (EDT) From: Henry Spencer To: Sandy Harris cc: Crispin Cowan , Marc Mutz , linux-ipsec@clinet.fi, linux-crypto@nl.linux.org Subject: Re: linux-ipsec: freeswan .... using OpenSSL ? In-Reply-To: <39DCA699.2F1FA02A@storm.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Thu, 5 Oct 2000, Sandy Harris wrote: > Will DNS security require similar things, or is all its key validation > done in user space? With the usual implementation approach, at least, DNSsec should be entirely user-space. > So what does it take to get a library into the kernel that does at least: >... > public key primitives (probably signature only) It is conceivable that one might want public-key encryption as well, and if RSA is being used, that's a trivial addition. Henry Spencer henry@spsystems.net Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Fri Oct 6 00:24:22 2000 Received: by humbolt.nl.linux.org id ; Fri, 6 Oct 2000 00:23:48 +0200 Received: from [216.168.105.33] ([216.168.105.33]:44022 "HELO mail.fibrespeed.net") by humbolt.nl.linux.org with SMTP id ; Fri, 6 Oct 2000 00:23:19 +0200 Received: (qmail 14622 invoked from network); 5 Oct 2000 22:23:11 -0000 Received: from unknown (508@216.168.105.34) by 216.168.105.35 with QMQP; 5 Oct 2000 22:23:11 -0000 Received: from mike.hosted.fibrespeed.net (HELO scanner) (192.168.10.12) by 216.168.105.33 with SMTP; 5 Oct 2000 22:23:11 -0000 Message-ID: <006901c02f1b$1f911c40$0c0aa8c0@hosted.fibrespeed.net> From: "Michael T. Babcock" To: "Gisle S{lensminde" , "Sandy Harris" Cc: "Crispin Cowan" , "Marc Mutz" , , References: Subject: Re: linux-ipsec: freeswan .... using OpenSSL ? Date: Thu, 5 Oct 2000 18:25:09 -0400 Organization: FibreSpeed MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list > Marc has told what things that is found in kerneli. Now Freeswan/ipsec > uses Eric Young's libdes, which both has a fast C implementation and > a fast x86 implementation. Unfortunatly it is specially stated in the > library source that the code is not GPL, and cannot be changed to GPL > either. > > > this code cannot simply be copied and put under another distrubution > license [including the GNU Public License.] > > > AFAIK, this means that the code cannot simply be put into the crypto- > API without permission. Do you think it's possible to get the > necessary permission to insert the the libdes 3DES implementation into > the kernel. In those cases, its often smart to offer the compiling user the option of linking against it and creating your own library to do it thats slower as well. ./configure --with-lib3des ... they'll have to acquire lib3des on their own. This is done with lots of other large packages. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Fri Oct 6 01:09:43 2000 Received: by humbolt.nl.linux.org id ; Fri, 6 Oct 2000 01:09:09 +0200 Received: from eik.ii.uib.no ([129.177.16.3]:9376 "EHLO ii.uib.no") by humbolt.nl.linux.org with ESMTP id convert rfc822-to-8bit; Fri, 6 Oct 2000 01:08:43 +0200 Received: from apal.ii.uib.no [129.177.16.7] by ii.uib.no with esmtp (Exim 3.03) id 13hK8N-0002v9-00 ; Fri, 06 Oct 2000 01:09:03 +0200 Received: (from gisle@localhost) by apal.ii.uib.no (8.8.8+Sun/8.8.7) id BAA07454; Fri, 6 Oct 2000 01:08:37 +0200 (MET DST) Date: Fri, 6 Oct 2000 01:08:37 +0200 (MET DST) From: Gisle S{lensminde To: "Michael T. Babcock" cc: Sandy Harris , Crispin Cowan , Marc Mutz , linux-ipsec@clinet.fi, linux-crypto@nl.linux.org Subject: Re: linux-ipsec: freeswan .... using OpenSSL ? In-Reply-To: <006901c02f1b$1f911c40$0c0aa8c0@hosted.fibrespeed.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Thu, 5 Oct 2000, Michael T. Babcock wrote: > > Marc has told what things that is found in kerneli. Now Freeswan/ipsec > > uses Eric Young's libdes, which both has a fast C implementation and > > a fast x86 implementation. Unfortunatly it is specially stated in the > > library source that the code is not GPL, and cannot be changed to GPL > > either. > > > > > > this code cannot simply be copied and put under another distrubution > > license [including the GNU Public License.] > > > > > > AFAIK, this means that the code cannot simply be put into the crypto- > > API without permission. Do you think it's possible to get the > > necessary permission to insert the the libdes 3DES implementation into > > the kernel. > > In those cases, its often smart to offer the compiling user the option of > linking against it and creating your own library to do it thats slower as > well. ./configure --with-lib3des ... they'll have to acquire lib3des on > their own. This is done with lots of other large packages. The code wil be put inside the kernel, and 3DES is already there. The point is to get a faster version in. I don't think the idea relying on people puting there own libraries into the kernel is a particularly good idea. The best idea would probably be to ask Eric Young for permission for insering the relevant parts of his library into the linux crypto API. Does anyone have his email adress, or know what he thinks about such usage. (other than the licence text) -- Gisle Sælensminde ( gisle@ii.uib.no ) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. (from RFC 1925) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Fri Oct 6 02:45:23 2000 Received: by humbolt.nl.linux.org id ; Fri, 6 Oct 2000 02:44:48 +0200 Received: from cpu2747.adsl.bellglobal.com ([207.236.55.216]:63736 "EHLO grendel.conscoop.ottawa.on.ca") by humbolt.nl.linux.org with ESMTP id ; Fri, 6 Oct 2000 02:44:23 +0200 Received: (from rgb@localhost) by grendel.conscoop.ottawa.on.ca (8.9.0/8.9.0) id UAA03113; Thu, 5 Oct 2000 20:40:09 -0400 Date: Thu, 5 Oct 2000 20:40:08 -0400 From: Richard Guy Briggs To: Gisle Cc: "Michael T. Babcock" , Sandy Harris , Crispin Cowan , Marc Mutz , linux-ipsec@clinet.fi, linux-crypto@nl.linux.org Subject: Re: linux-ipsec: freeswan .... using OpenSSL ? Message-ID: <20001005204008.E991@grendel.conscoop.ottawa.on.ca> References: <006901c02f1b$1f911c40$0c0aa8c0@hosted.fibrespeed.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from gisle@ii.uib.no on Fri, Oct 06, 2000 at 01:08:37AM +0200 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list -----BEGIN PGP SIGNED MESSAGE----- On Fri, Oct 06, 2000 at 01:08:37AM +0200, Gisle wrote: > On Thu, 5 Oct 2000, Michael T. Babcock wrote: > > In those cases, its often smart to offer the compiling user the option of > > linking against it and creating your own library to do it thats slower as > > well. ./configure --with-lib3des ... they'll have to acquire lib3des on > > their own. This is done with lots of other large packages. > > The code wil be put inside the kernel, and 3DES is already there. Eventually, but that does not help us for 2.0, 2.2 and 2.4 kernels, so it would be easier to include it with the distribution of FreeS/WAN and only use the built-in one if it exists. Eventually, we can ditch it when we stop supporting 2.0, 2.2 and 2.4. > The point is to get a faster version in. I don't think the idea relying > on people puting there own libraries into the kernel is a particularly > good idea. Agreed. > Gisle slainte mhath, RGB - -- Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada Prevent Internet Wiretapping! -- FreeS/WAN: Thanks for voting Green! -- Marillion: -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBOd0fZt+sBuIhFagtAQGeYgQAkjK1gnWBLr6BHWhW6kuTo1OdWtwDpiXt okAt/gJtfhwTIZqyFDh9olt+/XyBkflHF9XHZwzM1yFCRMy5VpJefcapk/JYxQcJ OfNyr9Uw+RFC1h3i5fNjMp9WJG+/4hR+9Wk53jg8mK1/9sw3ZSiebY2QU5aAFlmE KnGJn270Uso= =dcyI -----END PGP SIGNATURE----- Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Fri Oct 6 05:36:58 2000 Received: by humbolt.nl.linux.org id ; Fri, 6 Oct 2000 05:36:25 +0200 Received: from [216.168.105.33] ([216.168.105.33]:39677 "HELO mail.fibrespeed.net") by humbolt.nl.linux.org with SMTP id ; Fri, 6 Oct 2000 05:35:46 +0200 Received: (qmail 4654 invoked from network); 6 Oct 2000 03:35:39 -0000 Received: from unknown (508@216.168.105.34) by 216.168.105.35 with QMQP; 6 Oct 2000 03:35:39 -0000 Received: from mike.hosted.fibrespeed.net (HELO scanner) (192.168.10.12) by 216.168.105.33 with SMTP; 6 Oct 2000 03:35:38 -0000 Message-ID: <004801c02f46$cd7b4d00$0c0aa8c0@hosted.fibrespeed.net> From: "Michael T. Babcock" To: "Richard Guy Briggs" , "Gisle" Cc: "Sandy Harris" , "Crispin Cowan" , "Marc Mutz" , , References: <006901c02f1b$1f911c40$0c0aa8c0@hosted.fibrespeed.net> <20001005204008.E991@grendel.conscoop.ottawa.on.ca> Subject: Re: linux-ipsec: freeswan .... using OpenSSL ? Date: Thu, 5 Oct 2000 23:37:50 -0400 Organization: FibreSpeed MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list > On Fri, Oct 06, 2000 at 01:08:37AM +0200, Gisle wrote: > > On Thu, 5 Oct 2000, Michael T. Babcock wrote: > > > In those cases, its often smart to offer the compiling user the option of > > > linking against it and creating your own library to do it thats slower as > > > well. ./configure --with-lib3des ... they'll have to acquire lib3des on > > > their own. This is done with lots of other large packages. > > > > The point is to get a faster version in. I don't think the idea relying > > on people puting there own libraries into the kernel is a particularly > > good idea. > > Agreed. My comment was to have the option available sooner than later to use external 3DES, etc. libraries that are known to be more optimised. This can be replaced down the road with built-in libraries. That said, installing FreeS/WAN currently requires patching the kernel, etc. so why would you be hesitant about someone who wanted to use another library for better 3DES support? Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Fri Oct 6 10:43:06 2000 Received: by humbolt.nl.linux.org id ; Fri, 6 Oct 2000 10:42:21 +0200 Received: from midten.fast.no ([213.188.8.11]:32016 "EHLO midten.fast.no") by humbolt.nl.linux.org with ESMTP id ; Fri, 6 Oct 2000 10:41:45 +0200 Received: (from astor@localhost) by midten.fast.no (8.9.3/8.9.3) id KAA36144; Fri, 6 Oct 2000 10:41:37 +0200 (CEST) Date: Fri, 6 Oct 2000 10:41:36 +0200 From: Alexander S A Kjeldaas To: Sandy Harris Cc: linux-crypto@nl.linux.org Subject: Re: linux-ipsec: freeswan .... using OpenSSL ? Message-ID: <20001006104136.A4361@midten.fast.no> References: <39DB7F0F.A96F2092@Mutz.com> <39DC357D.1A18F242@wirex.com> <39DCA699.2F1FA02A@storm.ca> <39DCAD18.80F51650@Mutz.com> <39DCB4F9.47EEFE3B@storm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <39DCB4F9.47EEFE3B@storm.ca>; from Sandy Harris on Thu, Oct 05, 2000 at 01:06:01PM -0400 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Thu, Oct 05, 2000 at 01:06:01PM -0400, Sandy Harris wrote: > Marc Mutz wrote: > > I thought that Pk encryption was only used for key exchange. That could > > happily live in userspace. > > Yes, for IPSEC. But if you want the kernel to authenticate binaries before > loading them, then you may need public key stuff in the kernel. > Until someone can show that this is needed, I do not see the point in having the kernel authenticate binaries. We have a file-system, and if we accept that the file-system is secure, we can put the public-key crypto in the tools that are given the privilege of introducing a new executable program in the file-system. If you say that we can not trust the file-system, then I say that you can encrypt the file-system. Then you are back to the point where you have a user-level tool that does the public-key crypto when you mount the file-system. Even if you want to authenticate binaries, you can register "authorities" with the kernel so that the kernel only authenticates binaries with a HMAC. You can _still_ have a user-level tool that introduces those authorities into the kernel and does the necessary public-key crypto. I have a hard time imagining a system where: - There is _a lot_ of users able to introduce new binaries in the system so that registering them all in the kernel is awkward. - For some weird reason, you can not trust the filesystem. - There is no user-land workaround. All in all, I still do not understand why public-key crypto should be used in the kernel. I do not see a place for it until there comes an application where there are big _performance_ advantages of having it there. Few such applications exists because one generally tries to keep public-key crypto out of performance-critical areas. astor -- Alexander Kjeldaas Mail: astor@fast.no finger astor@master.kernel.org for OpenPGP key. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Fri Oct 6 10:49:46 2000 Received: by humbolt.nl.linux.org id ; Fri, 6 Oct 2000 10:49:10 +0200 Received: from midten.fast.no ([213.188.8.11]:54544 "EHLO midten.fast.no") by humbolt.nl.linux.org with ESMTP id ; Fri, 6 Oct 2000 10:48:37 +0200 Received: (from astor@localhost) by midten.fast.no (8.9.3/8.9.3) id KAA36438; Fri, 6 Oct 2000 10:48:09 +0200 (CEST) Date: Fri, 6 Oct 2000 10:48:07 +0200 From: Alexander S A Kjeldaas To: Andreas Schuldei Cc: linux-crypto@nl.linux.org Subject: Re: fast encryption of large files with asymetric keys Message-ID: <20001006104807.B4361@midten.fast.no> References: <20001005230752.A6092@sigrid.schuldei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <20001005230752.A6092@sigrid.schuldei.com>; from Andreas Schuldei on Thu, Oct 05, 2000 at 11:07:52PM +0200 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Thu, Oct 05, 2000 at 11:07:52PM +0200, Andreas Schuldei wrote: > Is there a program/lib/... for fast encryption of large files with > asymetric keys? gpg would do, but the minimal keylegth is 768 and > with that key it is to slow. In fact a much smaller key would > do. 60-200 Bits should be enough. > > Is there such a beast? Where? > > Please cc me, i am not on this list. > gpg encrypts your large file with a normal symetric cipher. This cipher is given a secret key, and this _key_ is encrypted using an asymetric key. So as the size of the file you encrypt with gpg increases, the number of bits in your asymetric key becomes more and more irrelevant, and the choice of cipher becomes your main concern. astor -- Alexander Kjeldaas Mail: astor@fast.no finger astor@master.kernel.org for OpenPGP key. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Fri Oct 6 15:30:25 2000 Received: by humbolt.nl.linux.org id ; Fri, 6 Oct 2000 15:29:51 +0200 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:52695 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Fri, 6 Oct 2000 15:29:28 +0200 Received: from Mutz.com (ppp36-374.hrz.uni-bielefeld.de [129.70.37.118]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G2000MGCG4SGT@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Fri, 6 Oct 2000 15:29:18 +0200 (MET DST) Date: Fri, 06 Oct 2000 13:03:41 +0000 From: Marc Mutz Subject: Q: Can in and out buffers of xxx_encrypt() be the same? To: linux-crypto@nl.linux.org Message-id: <39DDCDAC.360571A0@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Hi! We should clarify the issues: Must cipher implementations 1) expect that *in and *out may be the same buffer? 2) use no additional memory for operation after set_key() is called? Point (1) is not that terribly importatnt. It's just that such things should be defined somewhere. ad (2): I'm particularly thinking of encrypting swap here. There was a thread[1] about this about a year ago or so on lkml where it was said that it was necessary that encrypt() and decrypt() don't use additional memory for their run. However, whether this includes local variables placed on the stack I don't know. Maybe there is a limitation on the overall size of local variables so that it is not neccessay to claim a new page for the stack. Marc [1] message-id of the stating post was: <1E7F3E867C2DD3119D7F00A0C9D858639AC087@excnlle001.wang.nl> -- Marc Mutz http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Fri Oct 6 16:07:26 2000 Received: by humbolt.nl.linux.org id ; Fri, 6 Oct 2000 16:06:51 +0200 Received: from midten.fast.no ([213.188.8.11]:2065 "EHLO midten.fast.no") by humbolt.nl.linux.org with ESMTP id ; Fri, 6 Oct 2000 16:06:22 +0200 Received: (from astor@localhost) by midten.fast.no (8.9.3/8.9.3) id QAA48033; Fri, 6 Oct 2000 16:06:13 +0200 (CEST) Date: Fri, 6 Oct 2000 16:06:12 +0200 From: Alexander S A Kjeldaas To: Marc Mutz Cc: linux-crypto@nl.linux.org Subject: Re: Q: Can in and out buffers of xxx_encrypt() be the same? Message-ID: <20001006160611.A47357@midten.fast.no> References: <39DDCDAC.360571A0@Mutz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <39DDCDAC.360571A0@Mutz.com>; from Marc Mutz on Fri, Oct 06, 2000 at 01:03:41PM +0000 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Fri, Oct 06, 2000 at 01:03:41PM +0000, Marc Mutz wrote: > Hi! > > We should clarify the issues: > > Must cipher implementations > > 1) expect that *in and *out may be the same buffer? Yes I think they should. I can think of some ciphers where being able to use the output buffer as temporary space might be practical. For example a bitslice implementation of 3des which wants to transpose a 64x32 bit matrix needs a temporary storage area. Creating a 256 byte array on the stack might be questionable, but the memory could also be put at the end of the key_schedule, so this could be worked around. > 2) use no additional memory for operation after set_key() is called? > I think they should not. > Point (1) is not that terribly importatnt. It's just that such things > should be defined somewhere. > Agreed. > ad (2): I'm particularly thinking of encrypting swap here. There was a > thread[1] about this about a year ago or so on lkml where it was said > that it was necessary that encrypt() and decrypt() don't use additional > memory for their run. If the kernel is low on memory and wants to swap something out, the subsystem responsible for that (including the crypto API used in the loopback system) can not allocate memory. I do not know of any cipher that does, so this should not be an issue. I think the issue of using loopback for swap lies outside of the crypto API. > However, whether this includes local variables placed on the stack I > don't know. Maybe there is a limitation on the overall size of local > variables so that it is not neccessay to claim a new page for the stack. > It does not include local variables. There is an upper bound on the stack space that can be used in the kernel for a process, and that is sizeof(PAGE)-sizeof(task_struct) on most architectures AFAIK. This memory is allocated during fork(). Exceeding that stack-space is considered a bug in the kernel, so you have to be careful about recursion and having large objects on the stack. astor -- Alexander Kjeldaas Mail: astor@fast.no finger astor@master.kernel.org for OpenPGP key. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Fri Oct 6 16:14:34 2000 Received: by humbolt.nl.linux.org id ; Fri, 6 Oct 2000 16:13:52 +0200 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:18150 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Fri, 6 Oct 2000 16:13:23 +0200 Received: from Mutz.com (ppp36-166.hrz.uni-bielefeld.de [129.70.36.166]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G200037KI63RH@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Fri, 6 Oct 2000 16:13:22 +0200 (MET DST) Date: Fri, 06 Oct 2000 13:52:15 +0000 From: Marc Mutz Subject: Re: encrypting large files To: Andreas Schuldei Cc: linux-crypto@nl.linux.org Message-id: <39DDD90F.66170F2C@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <20001005191215.A5873@sigrid.schuldei.com> Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Andreas Schuldei wrote: > > I used ssh exactly in the (just now shown) insecure way: I transfered big files over an encrypted scp tunnel to my computer at home using cron. > > Now I need an other way to shovel my 20-30Mbyte per night over the net. > Why not use the way that was proposed as the alternative: ssh peer "tar cfz - files" > files.tar.gz tar tfz files.tar | grep for unusual files if nothing is found, untar and rm the tar.gz file. Or use ssh2. Marc -- Marc Mutz http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Sat Oct 7 02:28:03 2000 Received: by humbolt.nl.linux.org id ; Sat, 7 Oct 2000 02:27:28 +0200 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:25961 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Sat, 7 Oct 2000 02:27:00 +0200 Received: from Mutz.com (ppp36-357.hrz.uni-bielefeld.de [129.70.37.101]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G2100036AKW6B@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Sat, 7 Oct 2000 02:26:58 +0200 (MET DST) Date: Sat, 07 Oct 2000 00:06:27 +0000 From: Marc Mutz Subject: Re: linux-ipsec: freeswan .... using OpenSSL ? To: Sandy Harris Cc: linux-crypto@nl.linux.org Message-id: <39DE6903.C1B28F@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <39DB7F0F.A96F2092@Mutz.com> <39DC357D.1A18F242@wirex.com> <39DCA699.2F1FA02A@storm.ca> <39DCAD18.80F51650@Mutz.com> <39DCB4F9.47EEFE3B@storm.ca> Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Sandy Harris wrote: > > > > SHA HMAC (initialise with secret key material) > > > > probably trivial to add. > > > > Packet authentication is done with the HMAC. This is an SHA or MD5 hash of > the packet data, except with the registers in the hashing code initialised > from the HMAC key rather than from standard constants. I've read both rfc2104 and pluto/crypto.c. Looking at crypto.c:hmac_*() I reckon you use HMAC in the mode H(K XOR opad, H(K XOR ipad, text)) therefore requiring no chosen-IV for the hash, no? So either this could be added to the CryptoAPI or implemented as it is now inside freeswan. Alex Kjeldaas - if I understood him correctly - has a long-term goal of being able to combine several cryptographic primitives to new ones at runtime. > It therefore does > more than a simple hash would, authenticating not just that the packet data > was not changed in transit but also that the sender knew the HMAC key. Marc -- Marc Mutz http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Tue Oct 10 12:51:32 2000 Received: by humbolt.nl.linux.org id ; Tue, 10 Oct 2000 12:50:58 +0200 Received: from smtp11.singnet.com.sg ([165.21.6.31]:41368 "EHLO smtp11.singnet.com.sg") by humbolt.nl.linux.org with ESMTP id ; Tue, 10 Oct 2000 12:50:47 +0200 Received: from singnet.com.sg (qtns01758.singnet.com.sg [165.21.164.68]) by smtp11.singnet.com.sg (8.11.0/8.11.0) with ESMTP id e9AAoXR11330 for ; Tue, 10 Oct 2000 18:50:33 +0800 (SGT) Message-ID: <39E2F3E3.163FEBA5@singnet.com.sg> Date: Tue, 10 Oct 2000 18:48:03 +0800 From: Terrapin Station X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-crypto@nl.linux.org Subject: Secure File System Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Hello everyone, Eh...I'm quite new to this list and towards this subject. First question I'd like to ask is: Has anyone here tried out the "Secure File System" created by Michal Svec and Vaclav Petricek? I know are quite a few file crypto system called "SFS" but this is the one found at this website: http://atrey.karlin.mff.cuni.cz/~rebel/sfs/ Any comments? I managed to compile and got it to run (on kernel 2.0.x). I was able to read an encrypted file with "cat" or "less" but wasn't able to edit it using "vi". Actually, I can't save what I have edited. Has anyone encountered this problem before? Thanks Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Wed Oct 11 17:44:38 2000 Received: by humbolt.nl.linux.org id ; Wed, 11 Oct 2000 17:44:05 +0200 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:1141 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Wed, 11 Oct 2000 17:43:46 +0200 Received: from Mutz.com (ppp36-30.hrz.uni-bielefeld.de [129.70.36.30]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G290062KVOR37@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Wed, 11 Oct 2000 17:43:41 +0200 (MET DST) Date: Wed, 11 Oct 2000 15:41:41 +0000 From: Marc Mutz Subject: Re: A patch to loop.c for better cryption support To: Ingo Rohloff Cc: linux-kernel@vger.kernel.org, linux-crypto@nl.linux.org Message-id: <39E48A35.ADB955A7@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <20001010161439.A265@flashline.chipnet> Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list [added cc: linux-crypto] Ingo Rohloff wrote: > > Hi, > > First some explanation. Most cryption algorithms initialize > the cryption process with some init values, called IV (by me :-). > This means that two identical clear messages will give > different encrypted messages, if different IVs are used. > > The loop device supports different IVs; > the IVs are initilized with the requested block > number. > > I believe a better way is to use the requested > sector number from CURRENT->sector. > Using this value should make the encryption and decryption > process completely independent from the underlying device. > Two times no. First: This breaks backward-compatibility. Second: I don't know much of the block device handling in Linux, but what you produced seems like a quick shot. I can see this e.g. at the point where you declare 'sector' to be 'int' (7th hunk), whereas in include/linux/blkdev.h request.sector is declared _unsigned_ int. I don't know what request.sector is for loop devices (The block number of the underlying filesystem, if any? The hard sector number of the underlying blockdevice? Always the 512-byte-blocks number?), but if it is not the latter, i.e. always "position >> 9", you have just shifted the issue from one level (the fs block size) to another (whatever units sector is in). The better solution (for 2.2. and 2.4; in 2.5 Andries Brouwer has something more clean in his mind, IIUHC) is to add a new field to struct loop_info to indicate the encryption chunk size and patch losetup/mount to set this to 512 by default and to the filesystem block size if asked to by some command line switch. This allows people to convert their stuff. You may want to join linux-crypto@nl.linux.org (majordomo) if you want to work on this. Marc -- Marc Mutz http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Wed Oct 11 20:01:24 2000 Received: by humbolt.nl.linux.org id ; Wed, 11 Oct 2000 20:00:49 +0200 Received: from mout0.freenet.de ([194.97.50.131]:63153 "EHLO mout0.freenet.de") by humbolt.nl.linux.org with ESMTP id ; Wed, 11 Oct 2000 20:00:14 +0200 Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout0.freenet.de with esmtp (Exim 3.16 #20) id 13jQAm-0006qC-00 for linux-crypto@nl.linux.org; Wed, 11 Oct 2000 20:00:12 +0200 Received: from a7881.pppool.de ([213.6.120.129] helo=rohloff.modem.informatik.tu-muenchen.de) by mx2.freenet.de with smtp (Exim 3.16 #20) id 13jQAl-00087I-00 for linux-crypto@nl.linux.org; Wed, 11 Oct 2000 20:00:11 +0200 Received: (qmail 1187 invoked by uid 1000); 11 Oct 2000 20:04:05 -0000 Date: Wed, 11 Oct 2000 20:04:05 +0000 From: Ingo Rohloff To: linux-crypto@nl.linux.org Cc: linux-kernel@vger.linux.org, Marc@Mutz.com Subject: Re: A patch to loop.c for better cryption support Message-ID: <20001011200405.A1114@flashline.chipnet> Mail-Followup-To: linux-crypto@nl.linux.org, linux-kernel@vger.linux.org, Marc@Mutz.com References: <20001010161439.A265@flashline.chipnet> <39E48A35.ADB955A7@Mutz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <39E48A35.ADB955A7@Mutz.com>; from Marc Mutz on Wed, Oct 11, 2000 at 03:41:41PM +0000 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Hi again, > > The loop device supports different IVs; > > the IVs are initilized with the requested block > > number. > > I believe a better way is to use the requested > > sector number from CURRENT->sector. > > Using this value should make the encryption and decryption > > process completely independent from the underlying device. > Two times no. > > First: This breaks backward-compatibility. Right, (I mentioned this), but the backward-compatible way means: You might get problems over NFS using a backing file. You get problems if you burn a backing file to a CD (at least that's what it says in the FAQ), or if you copy it to another partition with a different file system (which handles blocks differently) or ... Has anyone tried to use an encrypted backing file on ReiserFS. I would be interested if it works with the old patch set. I even created an encrypted ReiserFS in a backing file, which was hosted on an uncrypted ReiserFS. (ReiserFS doesn't care about sector boundries, so it is especially useful for testing in this case.) I bet that this won't work with the old approach. (Even if this might be, because the cryption algorithms don't care about block boundries too :-( ) I know it works with my approach because I tried (even over NFS). > Second: I don't know much of the block device handling > in Linux, but what you produced seems like a quick > shot. I can see this e.g. at the point where you > declare 'sector' to be 'int' (7th hunk), whereas in > include/linux/blkdev.h request.sector is declared > _unsigned_ int. Well ok, my fault. BUT: "unsigned int" and "int" have the same bit size right ? The crypto algorithms only care about the bits not the signedness (and if they do, they only have to interpret the IV as signed... no problem...) > I don't know what request.sector is for loop > devices (The block number of the unde