From owner-linux-crypto@nl.linux.org Thu Nov 2 23:41:26 2000 Received: by humbolt.nl.linux.org id ; Thu, 2 Nov 2000 23:40:42 +0100 Received: from eik.ii.uib.no ([129.177.16.3]:4286 "EHLO ii.uib.no") by humbolt.nl.linux.org with ESMTP id convert rfc822-to-8bit; Thu, 2 Nov 2000 23:40:08 +0100 Received: from apal.ii.uib.no [129.177.16.7] by ii.uib.no with esmtp (Exim 3.03) id 13rT1s-0007lN-00 ; Thu, 02 Nov 2000 23:40:17 +0100 Received: (from gisle@localhost) by apal.ii.uib.no (8.8.8+Sun/8.8.7) id XAA28023; Thu, 2 Nov 2000 23:40:06 +0100 (MET) Date: Thu, 2 Nov 2000 23:40:06 +0100 (MET) From: Gisle S{lensminde To: William Ahern cc: linux-crypto@nl.linux.org Subject: Re: Int Crypto Patch and FreeS/Wan In-Reply-To: <00102711314802.13159@bill> 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 Fri, 27 Oct 2000, William Ahern wrote: > On Friday 27 October 2000 00:56, you wrote: > > On Thu, 26 Oct 2000, William Ahern wrote: > > > I have the 2.2.17 kernel, 2.2.17.9 international kernel patch and > > > frees/wan 1.6. any tips on how to get it to compile? DES, MD5 and SHA1 > > > routines seems to be conflicting. everything compiles fine until it hits > > > these.... > > > > > > i ran the freeswan-import script.... no beans.... > > > > Could you please tell which symboles that are conflicting. It > > would make it easier to find the problem and/or fix problems > > in kerneli. > > I've compiled w/ freeswan and the crypto patch, seperately. freeswan won't > patch w/ the crypto patch already in, but the crypto patch will take after > the freeswan patch. here are the compile errors: I think the problem simply is that freeswan and kerneli use the same names of functions and types. This is not surprising, since both have used the most obvious names. This could be solved by one or both the following ways: 1. Kerneli stops exporting these symbols, and let all export happen through the cipher_implementation struct. This is allerady discussed on this list, and will not break any existing code AFAIK. There are already a patch for this submitted to this list, but is not in the kerneli patch yet. 2. Modify freeswan to use the crypto API. 1. is the quick soulution, while 2. is a more long-term goal IMHO. They don't exclude each other, so both can be applied. We could of cause start that process right now, but the problem is that freeswan have faster implementations of 3DES, which is used for encryption, and that implementation has a licence that is problemetic for kerneli. A faster 3DES should therefore be implemented first. -- 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 Nov 6 10:34:42 2000 Received: by humbolt.nl.linux.org id ; Mon, 6 Nov 2000 10:34:00 +0100 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:38019 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Mon, 6 Nov 2000 10:33:33 +0100 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 <0G3L00EESJVVT8@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Mon, 6 Nov 2000 10:33:31 +0100 (MET) Date: Mon, 06 Nov 2000 10:34:54 +0100 From: Marc Mutz Subject: Re: AES To: emil@la.mine.nu Cc: linux-crypto@nl.linux.org Message-id: <3A067B3E.AB32FB54@Mutz.com> Organization: Bielefeld University - Dep. of Mathematics / Dep. of Physics 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 References: <20001104225500.8890010030@hal.haln> Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Emil wrote: > > util-linux-2.10o.int.patch still doesn't include the AES encryption > Anyone plans to do it ? > > -- > Regards, > Emil You can easily add it to the list of known ciphers in util-linux/mount/lomount.c Then re-compile both mount and losetup. 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 Nov 6 10:41:24 2000 Received: by humbolt.nl.linux.org id ; Mon, 6 Nov 2000 10:40:52 +0100 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:38535 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Mon, 6 Nov 2000 10:40:38 +0100 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 <0G3L00EDIK7PWN@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Mon, 6 Nov 2000 10:40:37 +0100 (MET) Date: Mon, 06 Nov 2000 10:42:01 +0100 From: Marc Mutz Subject: Fwd: Problems regarding loopback-crypto (was: Re: ) To: david@anvil.com, dave@damiel.freeserv.co.uk Cc: linux-crypto@nl.linux.org Message-id: <3A067CE9.AFE46884@Mutz.com> Organization: Bielefeld University - Dep. of Mathematics / Dep. of Physics 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 References: Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Hi Dave! The first thing I would look into would be to use 2.2.17.10. Then, if you have configured as modules, make sure you have them loaded. Also, make sure the cryptoapi is functioning (look at /proc/crypto/ciphers/; the cipher you want to use should be listed there.) If these do not help, please send a complete command history of what you did. Marc dave@damiel.freeserve.co.uk wrote: > > Hi Marc, > > I've been trying to get loopback encryption working. Details: > > kernel: 2.2.17 > international patch: 2.2.17.9 > util-linux: 2.10p > > I've followed the instructions as follows: > > - patch kernel source > - configure and build kernel > - reboot with new kernel > - patch util-linux > - build and install mount, umount, losetup > > However, when I try to do losetup I get one of the errors reported in > the 'frequently asked questions' section of your Encryption HOWTO: > > ioctl: LOOP_SET_STATUS: Invalid argument > > I've checked that this happens with each of the following ciphers: > > idea, DES, blowfish, twofish, cast128, serpent, mars > > which suggests its something fundamental. > > I've tried searching for a solution on the web, but have found nothing > particularly clear. There are a lot of posts about DES doing something > funny with getpass, but no indication that this would cause a problem > with the other ciphers. There were some posts in 1999 about there > being a fundamental incompatibility between the kernel and libc-2.0 > regarding the definition of dev_t, which could cause problems with > loopback mounts. (My libc is at version 2.0.7.) > > Any ideas? > > Thanks, > Dave. 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 Nov 13 11:23:59 2000 Received: by humbolt.nl.linux.org id ; Mon, 13 Nov 2000 11:23:11 +0100 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:41283 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Mon, 13 Nov 2000 11:22:37 +0100 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 <0G3Y00A0SKTF30@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Mon, 13 Nov 2000 11:22:27 +0100 (MET) Date: Mon, 13 Nov 2000 11:22:23 +0100 From: Marc Mutz Subject: Concerning AES and -p option support in util-linux.patch To: astor@fast.no Cc: linux-crypto@nl.linux.org Message-id: <3A0FC0DF.40F291A@Mutz.com> Organization: Bielefeld University - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.76 [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 Alex! There are currently many mails reaching me that claim that AES is not supported and that there is no -p option in losetup, like I said in the howto. The latter stems from the fact that aeb has not included the correspondig patch I sent to him. A reason he did not give to me. The former is just a slip in the util-linux.patch: The obvious line for AES is missing from the list of known ciphers in lomount.c. I think, it would be a good idea to add that line and make a 17.11, even if that remains the only change. If you like, you can include the patch I sent to you some time ago that adds support for a -p option to losetup (for reading the passphrase from a given file descriptor). You then said that this does not belong to the realm of the international util-linux patch, but I think aeb waits for that patch to be submitted for inclusion in the mainstream util-linux, or so I understood him, though he didn't say it openly. So we may as well collect the changes to util-linux in the patch and then submit it together to aeb. I don't think we should do that at this point, because we would still need to release a patch along with any changes (e.g. addition of a new cipher) to the ioctls. It would be best if we'd make losetup/mount completely independent of the details of the cryptoapi, e.g. using the information from the /proc files to determine available ciphers and their key parameters. 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 Nov 13 12:42:41 2000 Received: by humbolt.nl.linux.org id ; Mon, 13 Nov 2000 12:41:57 +0100 Received: from terra.geo.uu.nl ([131.211.29.16]:14073 "EHLO terra.geo.uu.nl") by humbolt.nl.linux.org with ESMTP id ; Mon, 13 Nov 2000 12:41:35 +0100 Received: from smtp22.singnet.com.sg (smtp22.singnet.com.sg [165.21.101.202]) by terra.geo.uu.nl (8.9.3/8.9.3/TvZ) with ESMTP id MAA28306 for ; Mon, 13 Nov 2000 12:41:33 +0100 (MET) Received: from singnet.com.sg (qtns00107.singnet.com.sg [165.21.160.17]) by smtp22.singnet.com.sg (8.11.0/8.11.0) with ESMTP id eADBfUg09499 for ; Mon, 13 Nov 2000 19:41:30 +0800 (SGT) Message-ID: <3A0FD30E.D0958665@singnet.com.sg> Date: Mon, 13 Nov 2000 19:39:59 +0800 From: Terrapin Station X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-crypto@nl.linux.org Subject: File Encryption 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 hi all, I was wondering if anybody has come across an open source implementation for Linux that does the following: 1. Encrypt files based on individual users' keys (similar to that of TCFS) 2. There is no need to mount with a particular file system like TCFS and CryptFS does. The user is able to create files ANYWHERE (where permission is allowed) and the file will be encrypted with his/her key. 3. The operation of encryption and decryption should be transparent to the user. User should be able to work with the file(s) with any application. 4. Any temporary files , like ".filename.swp' created by "vi" should also be encrypted. Well, maybe that was just a wish list, but if there is one, that will be very nice indeed. Otherwise, I was thinking about writing one. In that case, where do I start? Perhaps by working on the existing VFS? Any suggestions? Thank You 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 Nov 13 12:51:51 2000 Received: by humbolt.nl.linux.org id ; Mon, 13 Nov 2000 12:51:16 +0100 Received: from ausmtp02.au.ibm.COM ([202.135.136.105]:13579 "EHLO ausmtp02.au.ibm.com") by humbolt.nl.linux.org with ESMTP id ; Mon, 13 Nov 2000 12:50:48 +0100 Received: from f03n07e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id WAA209094 for ; Mon, 13 Nov 2000 22:43:02 +1100 From: gshekar@in.ibm.com Received: from d73mta03.au.ibm.com (f06n03s [9.185.166.97]) by f03n07e.au.ibm.com (8.8.8m3/NCO v4.95) with SMTP id WAA83026 for ; Mon, 13 Nov 2000 22:50:40 +1100 Received: by d73mta03.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256996.004111B6 ; Mon, 13 Nov 2000 22:50:43 +1100 X-Lotus-FromDomain: IBMIN@IBMAU To: Terrapin Station cc: linux-crypto@nl.linux.org Message-ID: Date: Mon, 13 Nov 2000 17:14:39 +0530 Subject: Re: File Encryption Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list >2. There is no need to mount with a particular file system like TCFS >and CryptFS does. The user is able to create files ANYWHERE (where >permission is allowed) and the file will be encrypted with his/her key. >3. The operation of encryption and decryption should be transparent >to the user. User should be able to work with the file(s) with any >application. How do you distinguish between ordinary files and encrypted files Thanks and regards Girish.c 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 Nov 13 14:40:54 2000 Received: by humbolt.nl.linux.org id ; Mon, 13 Nov 2000 14:40:09 +0100 Received: from midten.fast.no ([213.188.8.11]:17420 "EHLO midten.fast.no") by humbolt.nl.linux.org with ESMTP id ; Mon, 13 Nov 2000 14:39:48 +0100 Received: (from astor@localhost) by midten.fast.no (8.9.3/8.9.3) id OAA64792; Mon, 13 Nov 2000 14:39:39 +0100 (CET) Date: Mon, 13 Nov 2000 14:39:38 +0100 From: Alexander S A Kjeldaas To: Marc Mutz Cc: Alexander.Kjeldaas@fast.no, linux-crypto@nl.linux.org Subject: Re: Concerning AES and -p option support in util-linux.patch Message-ID: <20001113143937.A64699@midten.fast.no> References: <3A0FC0DF.40F291A@Mutz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <3A0FC0DF.40F291A@Mutz.com>; from Marc Mutz on Mon, Nov 13, 2000 at 11:22:23AM +0100 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Mon, Nov 13, 2000 at 11:22:23AM +0100, Marc Mutz wrote: > Hi Alex! > > There are currently many mails reaching me that claim that AES is not > supported and that there is no -p option in losetup, like I said in the > howto. The latter stems from the fact that aeb has not included the > correspondig patch I sent to him. A reason he did not give to me. The > former is just a slip in the util-linux.patch: The obvious line for AES > is missing from the list of known ciphers in lomount.c. > > I think, it would be a good idea to add that line and make a 17.11, even > if that remains the only change. > If you like, you can include the patch I sent to you some time ago that > adds support for a -p option to losetup (for reading the passphrase from > a given file descriptor). You then said that this does not belong to the > realm of the international util-linux patch, but I think aeb waits for > that patch to be submitted for inclusion in the mainstream util-linux, > or so I understood him, though he didn't say it openly. So we may as > well collect the changes to util-linux in the patch and then submit it > together to aeb. > Could you send me that patch again? I can't find it. 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 Nov 13 18:58:27 2000 Received: by humbolt.nl.linux.org id ; Mon, 13 Nov 2000 18:57:42 +0100 Received: from hermes.mixx.net ([212.84.196.2]:51719 "EHLO hermes.mixx.net") by humbolt.nl.linux.org with ESMTP id ; Mon, 13 Nov 2000 18:57:08 +0100 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 81B39F803 for ; Mon, 13 Nov 2000 18:57:03 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 1688A2CA6E; Mon, 13 Nov 2000 18:57:03 +0100 (CET) From: stephan.eckner@innominate.de X-Newsgroups: innominate.list.linux.crypto Subject: Kein Krypto Vortrag am 14.11 (morgen) Date: 13 Nov 2000 17:57:02 GMT Organization: innominate AG, Berlin, Germany Lines: 19 Distribution: local Message-ID: X-Trace: mate.bln.innominate.de 974138222 19570 10.0.0.20 (13 Nov 2000 17:57:02 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/pre-1.4-19990805 ("Preacher Man") (UNIX) (Linux/2.2.10 (i686)) To: linux-crypto@nl.linux.org Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Hi bin gerade ein bischen angeschlagen (Erkaeltung) Deshalb kein Vortrag Morgen :( Aber naechste Woche bestimmt :)) Gruss Stephan -- stephan.eckner@innominate.com dipl.-math. innominate AG system engineer the linux architects tel: +49.30.308806-354 fax: -77 http://www.innominate.com 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 Nov 13 19:33:47 2000 Received: by humbolt.nl.linux.org id ; Mon, 13 Nov 2000 19:33:11 +0100 Received: from bbm.ca ([206.116.211.2]:15755 "HELO bbmfw.bbm.ca") by humbolt.nl.linux.org with SMTP id ; Mon, 13 Nov 2000 19:32:38 +0100 Received: id NAA06363; Mon, 13 Nov 2000 13:24:00 -0500 Received: by gateway ??? Received: by gateway id ; Mon, 13 Nov 2000 13:21:07 -0500 Message-ID: <8366512BA71AD2119FAE00A0C9D634FAFE35D2@torex1.tor.bbm.ca> From: Ahmed Warsame To: "'linux-crypto@nl.linux.org'" Subject: Linuxconfig Date: Mon, 13 Nov 2000 13:21:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Whenever I run Linuxconf form the console and try to change something it will disconnect all networks I don not understand why. Using any other alternative is not interrupting my network. FYI am using netemulator. 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 Nov 14 00:17:15 2000 Received: by humbolt.nl.linux.org id ; Tue, 14 Nov 2000 00:16:41 +0100 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:53429 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Tue, 14 Nov 2000 00:16:14 +0100 Received: from Mutz.com (ppp36-236.hrz.uni-bielefeld.de [129.70.36.236]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G3Z00E2BKMZPC@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Tue, 14 Nov 2000 00:16:12 +0100 (MET) Date: Mon, 13 Nov 2000 22:57:47 +0000 From: Marc Mutz Subject: Re: File Encryption To: Terrapin Station Cc: linux-crypto@nl.linux.org Message-id: <3A1071EB.1ED569E@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17i10-0001 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <3A0FD30E.D0958665@singnet.com.sg> Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Terrapin Station wrote: > > hi all, > > I was wondering if anybody has come across an open source > implementation for Linux that does the following: > > 1. Encrypt files based on individual users' keys (similar to that of > TCFS) > > 2. There is no need to mount with a particular file system like TCFS > and CryptFS does. The user is able to create files ANYWHERE (where > permission is allowed) and the file will be encrypted with his/her key. > > 3. The operation of encryption and decryption should be transparent > to the user. User should be able to work with the file(s) with any > application. > You could code up such a thing with podfuk a.k.a. userfs and gnupg, I guess. > 4. Any temporary files , like ".filename.swp' created by "vi" should > also be encrypted. > A loopback encrypted /tmp would be the only thing I can think of. > Well, maybe that was just a wish list, but if there is one, that > will be very nice indeed. Otherwise, I was thinking about writing one. > In that case, where do I start? Perhaps by working on the existing VFS? > Any suggestions? > There is said userfs. It can be used like the following, IIRC: user$ ls /path/to/file.tar.gz#. file1 file2 file3 You shoud be able to extend that to encryption via gnupg. 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 Nov 14 00:38:11 2000 Received: by humbolt.nl.linux.org id ; Tue, 14 Nov 2000 00:37:22 +0100 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:57528 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Tue, 14 Nov 2000 00:37:02 +0100 Received: from Mutz.com (ppp36-323.hrz.uni-bielefeld.de [129.70.37.67]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G3Z00CKHLLOTQ@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Tue, 14 Nov 2000 00:37:01 +0100 (MET) Date: Mon, 13 Nov 2000 23:24:59 +0000 From: Marc Mutz Subject: Re: Linuxconfig To: Ahmed Warsame Cc: "'linux-crypto@nl.linux.org'" Message-id: <3A10784B.7C79EB21@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17i10-0001 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <8366512BA71AD2119FAE00A0C9D634FAFE35D2@torex1.tor.bbm.ca> Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Ahmed Warsame wrote: > > Whenever I run Linuxconf form the console and try to change something it > will disconnect all networks I don not understand why. > > Using any other alternative is not interrupting my network. > > FYI am using netemulator. > Either a) You posted to the wrong list b) I don't know netemulator. Maybe it has to do with crypto. c) You gave too few details. or any subset thereof. 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 Nov 14 00:39:39 2000 Received: by humbolt.nl.linux.org id ; Tue, 14 Nov 2000 00:37:44 +0100 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:58296 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Tue, 14 Nov 2000 00:37:06 +0100 Received: from Mutz.com (ppp36-323.hrz.uni-bielefeld.de [129.70.37.67]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G3Z00DFBLLPIJ@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Tue, 14 Nov 2000 00:37:05 +0100 (MET) Date: Mon, 13 Nov 2000 23:29:07 +0000 From: Marc Mutz Subject: [RESENT][PATCH] A better util-linux.getpass.patch To: astor@fast.no Cc: linux-crypto@nl.linux.org Message-id: <3A107943.B98CBD83@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17i10-0001 i586) Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_/hyJj3Pvrl4hOzs0Qz908A)" 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_/hyJj3Pvrl4hOzs0Qz908A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Alex! I've implemented the Q> --pass-fd alias Q> -p option for both mount(8) and losetup(8). It expects a number () as argument and instructs mount/losetup to read the passphrase from file descriptor instead of from the terminal. man pages have been updated, too. I have tested the xgetpass() routine both with a passphrase below 128 bytes and with the to-do-list I sent you some days ago with every newline removed, like Q> cat my-ikp-todo.txt | tr -d $'\n' | \ Q> losetup -e blowfish -p 0 /dev/loop0 crypto-file It works! Also, it teaches losetup long options, see losetup.8 for more. The patch applies to util-linux-2.10o, patched with the patch from 2.2.17.3. It will conflict with Gisle's and my previous stuff, no doubt. but AFAICS, only in the switch statement, where my patch is trivial: Just Q> getpass("...")->xgetpass(pfd,"...") everywhere. Please consider applying. if it makes too much noise when patching, I'll rediff against 17.4 when that is out. Marc PS: I have also fixed the loop vs. remount bug described in my todo list. A patch to Andries has been sent and he applied it. It is a two-liner in mount.c:try_mount_one() and thus will not collide with the kerneli-util-linux patches. But the difference in remount loop semantics is _great_. -- 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) --Boundary_(ID_/hyJj3Pvrl4hOzs0Qz908A) Content-type: text/plain; name=util-linux-2.10o-passfd.patch; charset=us-ascii Content-disposition: inline; filename=util-linux-2.10o-passfd.patch Content-transfer-encoding: 7BIT diff -urN util-linux-2.10o.i3/mount/lomount.c util-linux-2.10o.i3-getpass/mount/lomount.c --- util-linux-2.10o.i3/mount/lomount.c Sun Sep 24 16:46:02 2000 +++ util-linux-2.10o.i3-getpass/mount/lomount.c Sun Sep 24 23:26:00 2000 @@ -6,6 +6,11 @@ * - added Native Language Support * Sun Mar 21 1999 - Arnaldo Carvalho de Melo * - fixed strerr(errno) in gettext calls + * 2000-09-24 Marc Mutz + * - added long option names and the --pass-fd option to pass + * passphrases via fd's to losetup/mount. Used for encryption in + * non-interactive environments. The idea behind xgetpass() is stolen + * from GnuPG, v.1.0.3 (http://www.gnupg.org/). */ #define PROC_DEVICES "/proc/devices" @@ -176,9 +181,47 @@ return 0; } +/* A function to read the passphrase either from the terminal or from + * an open file descriptor */ +static char * +xgetpass (int pfd, const char *prompt) +{ + if (pfd < 0) /* terminal */ + return (getpass(prompt)); + else { /* file descriptor */ + char *pass = NULL; + int buflen, i; + + buflen=0; + for (i=0; ; i++) { + if (i >= buflen-1) { + /* we're running out of space in the buffer. + * Make it bigger: */ + char *tmppass = pass; + buflen += 128; + pass = realloc(tmppass,buflen); + if (pass == NULL) { + /* realloc failed. Stop reading _now_. */ + error("not enough memory while reading passphrase"); + pass = tmppass; /* the old buffer hasn't changed */ + break; + } + }; + if ( read(pfd,pass+i, 1) != 1 || pass[i] == '\n' ) + break; + } + if (pass == NULL) + return ""; + else { + pass[i] = 0; + return pass; + } + } +} + int set_loop (const char *device, const char *file, int offset, - const char *encryption, int *loopro) { + const char *encryption, int pfd, int *loopro) { struct loop_info loopinfo; int fd, ffd, mode, i; char *pass; @@ -227,14 +270,16 @@ loopinfo.lo_encrypt_key_size = 0; break; case LO_CRYPT_XOR: - pass = getpass (_("Password: ")); + /* WARNING: xgetpass() can return massive amounts of data, + * not only 128 bytes like the original getpass(3) */ + pass = xgetpass (pfd,_("Password: ")); strncpy (loopinfo.lo_encrypt_key, pass, LO_KEY_SIZE); loopinfo.lo_encrypt_key[LO_KEY_SIZE - 1] = 0; loopinfo.lo_encrypt_key_size = strlen(loopinfo.lo_encrypt_key); break; case LO_CRYPT_DES: printf(_("WARNING: Use of DES is depreciated.\n")); - pass = getpass (_("Password: ")); + pass = xgetpass (pfd,_("Password: ")); strncpy (loopinfo.lo_encrypt_key, pass, 8); loopinfo.lo_encrypt_key[8] = 0; loopinfo.lo_encrypt_key_size = 8; @@ -252,7 +297,7 @@ break; case LO_CRYPT_FISH2: case LO_CRYPT_BLOW: - pass = getpass("Password :"); + pass = xgetpass(pfd,_("Password :")); MDcalc((byte *)loopinfo.lo_encrypt_key,pass,strlen(pass)); loopinfo.lo_encrypt_key_size=20; /* 160 Bit key */ break; @@ -262,7 +307,7 @@ case LO_CRYPT_MARS: case LO_CRYPT_RC6: case LO_CRYPT_DFC: - pass = getpass("Password :"); + pass = xgetpass(pfd,_("Password :")); MDcalc((byte *)loopinfo.lo_encrypt_key,pass,strlen(pass)); loopinfo.lo_encrypt_key_size=16; /* 128 Bit key */ break; @@ -319,7 +364,7 @@ int set_loop (const char *device, const char *file, int offset, - const char *encryption, int *loopro) { + const char *encryption, int pfd, int *loopro) { mutter(); return 1; } @@ -348,20 +393,34 @@ int verbose = 0; static char *progname; +static struct option longopts[] = { + { "delete", 0, 0, 'd' }, + { "detach", 0, 0, 'd' }, + { "encryption", 1, 0, 'e' }, + { "help", 0, 0, 'h' }, + { "offset", 1, 0, 'o' }, + { "pass-fd", 1, 0, 'p' }, + { "verbose", 0, 0, 'v' }, + { NULL, 0, 0, 0 } +}; + + static void usage(void) { - struct crypt_type_struct *c; fprintf(stderr, _("usage:\n\ %s loop_device # give info\n\ %s -d loop_device # delete\n\ - %s [ -e encryption ] [ -o offset ] loop_device file # setup\n"), + %s [ options ] loop_device file # setup\n\ + where options include\n\ + --offset , -o \n\ + start at offset into file.\n\ + --pass-fd , -p \n\ + read passphrase from file descriptor \n\ + instead of the terminal.\n\ + --encryption , -e \n\ + encrypt with .\n\ + Check /proc/cipher for available ciphers."), progname, progname, progname); - fprintf(stderr, " where encryption is one of:\n"); - c = &crypt_type_tbl[0]; - while(c->name) { - fprintf(stderr, " %s\n", c->name); - c++; - } exit(1); } @@ -394,8 +453,9 @@ int main(int argc, char **argv) { - char *offset, *encryption; + char *offset, *encryption, *passfd; int delete,off,c; + int pfd = -1; int res = 0; int ro = 0; @@ -404,9 +464,10 @@ textdomain(PACKAGE); delete = off = 0; - offset = encryption = NULL; + offset = encryption = passfd = NULL; progname = argv[0]; - while ((c = getopt(argc,argv,"de:o:v")) != EOF) { + while ((c = getopt_long(argc,argv,"de:ho:p:v", + longopts, NULL)) != EOF) { switch (c) { case 'd': delete = 1; @@ -417,6 +478,9 @@ case 'o': offset = optarg; break; + case 'p': + passfd = optarg; + break; case 'v': verbose = 1; break; @@ -425,7 +489,7 @@ } } if (argc == 1) usage(); - if ((delete && (argc != optind+1 || encryption || offset)) || + if ((delete && (argc != optind+1 || encryption || offset || passfd)) || (!delete && (argc < optind+1 || argc > optind+2))) usage(); if (argc == optind+1) { @@ -436,7 +500,9 @@ } else { if (offset && sscanf(offset,"%d",&off) != 1) usage(); - res = set_loop(argv[optind],argv[optind+1],off,encryption,&ro); + if (passfd && sscanf(passfd,"%d",&pfd) != 1) + usage(); + res = set_loop(argv[optind],argv[optind+1],off,encryption,pfd,&ro); } return res; } diff -urN util-linux-2.10o.i3/mount/lomount.h util-linux-2.10o.i3-getpass/mount/lomount.h --- util-linux-2.10o.i3/mount/lomount.h Fri Jul 9 04:56:39 1999 +++ util-linux-2.10o.i3-getpass/mount/lomount.h Sun Sep 24 17:20:01 2000 @@ -1,4 +1,4 @@ extern int verbose; -extern int set_loop (const char *, const char *, int, const char *, int *); +extern int set_loop (const char *, const char *, int, const char *, int, int *); extern int del_loop (const char *); extern char * find_unused_loop_device (void); diff -urN util-linux-2.10o.i3/mount/losetup.8 util-linux-2.10o.i3-getpass/mount/losetup.8 --- util-linux-2.10o.i3/mount/losetup.8 Sun Sep 24 16:46:02 2000 +++ util-linux-2.10o.i3-getpass/mount/losetup.8 Sun Sep 24 23:01:14 2000 @@ -10,6 +10,9 @@ ] [ .B \-o .I offset +] [ +.B \-p +.I num ] .I loop_device file .br @@ -26,9 +29,9 @@ \fIloop_device\fP argument is given, the status of the corresponding loop device is shown. .SH OPTIONS -.IP \fB\-d\fP +.IP "\fB\-\-delete, \-\-detach, \-d\fP" detach the file or device associated with the specified loop device. -.IP "\fB\-e \fIencryption\fP" +.IP "\fB\-\-encryption, \-e \fIencryption\fP" .RS enable data encryption. The following keywords are recognized: .IP \fBNONE\fP @@ -79,9 +82,12 @@ enabled in the Crypto API. .PD .RE -.IP "\fB\-o \fIoffset\fP" +.IP "\fB\-\-offset, \-o \fIoffset\fP" the data start is moved \fIoffset\fP bytes into the specified file or device. +.IP "\fB\-\-pass-fd, \-p \fInum\fP" +read the passphrase from file descriptor \fInum\fP instead of the +terminal. .SH RETURN VALUE .B losetup returns 0 on success, nonzero on failure. When diff -urN util-linux-2.10o.i3/mount/mount.8 util-linux-2.10o.i3-getpass/mount/mount.8 --- util-linux-2.10o.i3/mount/mount.8 Sun Jul 30 22:26:41 2000 +++ util-linux-2.10o.i3-getpass/mount/mount.8 Sun Sep 24 23:19:47 2000 @@ -252,6 +252,12 @@ .B \-v Verbose mode. .TP +.B \-p "\fInum\fP" +If the mount requires a passphrase to be entered, read it from file +descriptor +.IR num\fP +instead of from the terminal. +.TP .B \-a Mount all filesystems (of the given types) mentioned in .IR fstab . @@ -1240,7 +1246,10 @@ .BR loop ", " offset " and " encryption , that are really options to .BR losetup (8). -If no explicit loop device is mentioned +If the mount requires a passphrase, you will be prompted for one unless +you specify a file descriptor to read from instead with the +.BR \-\-pass-fd +option. If no explicit loop device is mentioned (but just an option `\fB\-o loop\fP' is given), then .B mount will try to find some unused loop device and use that. diff -urN util-linux-2.10o.i3/mount/mount.c util-linux-2.10o.i3-getpass/mount/mount.c --- util-linux-2.10o.i3/mount/mount.c Fri Aug 11 14:50:10 2000 +++ util-linux-2.10o.i3-getpass/mount/mount.c Sun Sep 24 23:24:09 2000 @@ -105,6 +105,9 @@ /* True if ruid != euid. */ static int suid = 0; +/* Contains the fd no. to read the passphrase from, if any */ +static int pfd = -1; + /* Map from -o and fstab option strings to the flag argument to mount(2). */ struct opt_map { const char *opt; /* option name */ @@ -536,7 +539,7 @@ if (verbose) printf(_("mount: going to use the loop device %s\n"), *loopdev); offset = opt_offset ? strtoul(opt_offset, NULL, 0) : 0; - if (set_loop (*loopdev, *loopfile, offset, opt_encryption, &loopro)) { + if (set_loop (*loopdev, *loopfile, offset, opt_encryption, pfd, &loopro)) { if (verbose) printf(_("mount: failed setting up loop device\n")); return EX_FAIL; @@ -1226,6 +1229,7 @@ { "read-write", 0, 0, 'w' }, { "rw", 0, 0, 'w' }, { "options", 1, 0, 'o' }, + { "pass-fd", 1, 0, 'p' }, { "types", 1, 0, 't' }, { "bind", 0, 0, 128 }, { "replace", 0, 0, 129 }, @@ -1259,7 +1263,7 @@ "or by label, using -L label or by uuid, using -U uuid .\n" "Union or stack mounts are specified using one of\n" " --replace, --after, --before, --over\n" - "Other options: [-nfFrsvw] [-o options].\n" + "Other options: [-nfFrsvw] [-o options] [-p num].\n" "For many more details, say man 8 mount .\n" )); unlock_mtab(); @@ -1271,6 +1275,7 @@ int c, result = 0, specseen; char *options = NULL, *spec, *node; char *volumelabel = NULL; + char *passfd = NULL; char *uuid = NULL; string_list types = NULL; struct mntentchn *mc; @@ -1291,7 +1296,7 @@ initproctitle(argc, argv); #endif - while ((c = getopt_long (argc, argv, "afFhlL:no:rsU:vVwt:", + while ((c = getopt_long (argc, argv, "afFhlL:no:p:rsU:vVwt:", longopts, NULL)) != EOF) { switch (c) { case 'a': /* mount everything in fstab */ @@ -1321,6 +1326,9 @@ else options = xstrdup(optarg); break; + case 'p': /* read passphrase from given fd */ + passfd = optarg; + break; case 'r': /* mount readonly */ readonly = 1; readwrite = 0; @@ -1405,6 +1413,9 @@ printf(_("mount: mounting %s\n"), spec); } else spec = NULL; /* just for gcc */ + + if (passfd && sscanf(passfd,"%d",&pfd) != 1) + die (EX_USAGE, _("mount: argument to --pass-fd or -p must be a number")); switch (argc+specseen) { case 0: --Boundary_(ID_/hyJj3Pvrl4hOzs0Qz908A)-- 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 Nov 23 13:46:57 2000 Received: by humbolt.nl.linux.org id ; Thu, 23 Nov 2000 13:46:19 +0100 Received: from f121.law11.hotmail.com ([64.4.17.121]:37138 "EHLO hotmail.com") by humbolt.nl.linux.org with ESMTP id ; Thu, 23 Nov 2000 13:45:59 +0100 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 23 Nov 2000 04:45:49 -0800 Received: from 165.21.83.159 by lw11fd.law11.hotmail.msn.com with HTTP; Thu, 23 Nov 2000 12:45:49 GMT X-Originating-IP: [165.21.83.159] From: "Louis Lam" To: linux-crypto@nl.linux.org Subject: ppdd Date: Thu, 23 Nov 2000 20:45:49 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Nov 2000 12:45:49.0381 (UTC) FILETIME=[4E789F50:01C0554B] Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list hi, I was able to use ppdd to get an encrypted root file system and swap partition. Both the root file system and the swap were formatted with a blocksize of 1024 as suggested. Is there anyone in this list who is able to get encrypted root and swap that are based on blocksize of 4096? I am still trying to do that but so far I wasn't able to do so. I understand that using the blocksize of 4096 may not be so efficient for random access. More will have to be decrypted before u can get to the part of the block that U want. The reason I want to do this is just for seeing the difference, and maybe able to encrypt some existing data which is actually a linux installation from redhat 6.2 which by default formats the partition with a blocksize of 4096. Thanks & Happy Thanksgiving Louis _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com 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 Nov 23 15:47:51 2000 Received: by humbolt.nl.linux.org id ; Thu, 23 Nov 2000 15:47:17 +0100 Received: from north.net.CSUChico.EDU ([132.241.66.18]:45063 "EHLO north.net.csuchico.edu") by humbolt.nl.linux.org with ESMTP id ; Thu, 23 Nov 2000 15:46:44 +0100 Received: (from warlock@localhost) by north.net.csuchico.edu (8.11.0.Beta1/8.11.0.Beta0) id eANEkae15131; Thu, 23 Nov 2000 06:46:36 -0800 Date: Thu, 23 Nov 2000 06:46:36 -0800 From: John Kennedy To: Louis Lam Cc: linux-crypto@nl.linux.org Subject: Re: ppdd Message-ID: <20001123064636.A14860@north.csuchico.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from lsauchun@hotmail.com on Thu, Nov 23, 2000 at 08:45:49PM +0800 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Thu, Nov 23, 2000 at 08:45:49PM +0800, Louis Lam wrote: > I was able to use ppdd to get an encrypted root file system and swap > partition. Both the root file system and the swap were formatted > with a blocksize of 1024 as suggested. > > Is there anyone in this list who is able to get encrypted root and > swap that are based on blocksize of 4096? I'm just using the regular kernel API, not ppdd. Using ext2/ext3, you tend to end up with 4K blocks by default and left them that way. > I am still trying to do that but so far I wasn't able to do so. I > understand that using the blocksize of 4096 may not be so efficient > for random access. More will have to be decrypted before u can get > to the part of the block that U want. The reason I want to do this > is just for seeing the difference, and maybe able to encrypt some > existing data which is actually a linux installation from redhat > 6.2 which by default formats the partition with a blocksize of 4096. You'll have to decrypt the entire block before you get to play with any part of it, yes. For user home directories, I would think that smaller block-sizes would be a plus (you're not dealing with horribly large files as a general case, for example). For encrypting an entire filesystem, I would think you would get into the same kinds of efficiency issues that made 4K blocks attractive in the first place. I tend to think of encryption as more of a latency issue. All else being equal, I've added encryption latency to my reads and writes, but the underlying issues should all be the same. You could probably benchmark it. The added latency might be so great that it makes the raw 1K/4K blocksize issue moot. 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 Nov 23 15:56:41 2000 Received: by humbolt.nl.linux.org id ; Thu, 23 Nov 2000 15:56:06 +0100 Received: from north.net.CSUChico.EDU ([132.241.66.18]:47879 "EHLO north.net.csuchico.edu") by humbolt.nl.linux.org with ESMTP id ; Thu, 23 Nov 2000 15:55:36 +0100 Received: (from warlock@localhost) by north.net.csuchico.edu (8.11.0.Beta1/8.11.0.Beta0) id eANEtPV15275; Thu, 23 Nov 2000 06:55:25 -0800 Date: Thu, 23 Nov 2000 06:55:24 -0800 From: John Kennedy To: Marc Mutz Cc: emil@la.mine.nu, linux-crypto@nl.linux.org Subject: Re: AES Message-ID: <20001123065524.B14860@north.csuchico.edu> References: <20001104225500.8890010030@hal.haln> <3A067B3E.AB32FB54@Mutz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3A067B3E.AB32FB54@Mutz.com>; from Marc@Mutz.com on Mon, Nov 06, 2000 at 10:34:54AM +0100 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Mon, Nov 06, 2000 at 10:34:54AM +0100, Marc Mutz wrote: > Emil wrote: > > util-linux-2.10o.int.patch still doesn't include the AES encryption > > Anyone plans to do it ? > > You can easily add it to the list of known ciphers in > util-linux/mount/lomount.c > Then re-compile both mount and losetup. I've been looking into what I would have to do to try and enable that. Right now I'm using serpent (in the readme and in the source, plus it works), but AES is supposed to be much faster (looking at NIST's benchmarks). You should need to fix it in two places. crypt_type_tbl which has the number, text-name and keylength (which I don't know for AES) and lower for the big switch on lo_encrypt_type, where it would presumably be included with LO_CRYPT_SERPENT and the rest. I've been saving this particular hack for a rainy day, but I think that is correct. Most of my losetup-like hacking has been done in my own personal bootloader and outside of the normal utilities. 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 Nov 23 20:59:45 2000 Received: by humbolt.nl.linux.org id ; Thu, 23 Nov 2000 20:59:00 +0100 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:63323 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Thu, 23 Nov 2000 20:58:37 +0100 Received: from Mutz.com (ppp36-360.hrz.uni-bielefeld.de [129.70.37.104]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G4H00KLPU4U0K@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Thu, 23 Nov 2000 20:58:08 +0100 (MET) Date: Thu, 23 Nov 2000 19:15:18 +0000 From: Marc Mutz Subject: Re: ppdd To: Louis Lam Cc: linux-crypto@nl.linux.org Message-id: <3A1D6CC6.94C9CB30@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17i10-0001 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 Louis Lam wrote: > > hi, > > I was able to use ppdd to get an encrypted root file system and swap > partition. Both the root file system and the swap were formatted with a > blocksize of 1024 as suggested. > > Is there anyone in this list who is able to get encrypted root and swap that > are based on blocksize of 4096? I hope this message from the ppdd mailing list answers your question, but probably not as you wished: "Michael H. Warfield" wrote: > > On Fri, Jun 02, 2000 at 09:29:32AM +1000, Bob Hepple wrote: > > Nathaniel Daw wrote: > > > > hey, > > > > I'm new to the list but have been watching several days for the answer > > > to this probably common question: I'm thinking of bumping my kernel up > > > to a 2.3/2.4 prerelease & I want to bring my encrypted disks with > > > me. I was planning on seeing if I could get the old ppdd patches to > > > apply, but I wonder if (a) anyone has already done this work, or (b) > > > anyone knows of any major gotchas that will bite me if I try to do > > > this. Should it go smoothly? > > > For what it's worth, I did 2.2.14 with no problems - except I can't > > mount partitions greater than 500Mb - is this a known problem. > > It's probably an RTFM, but it's not obvious. Partitions greater > than about 500Meg are going to get build with a block size other then > 1024. They will most likely end with with a block size of 4096 or 8192. > The doco's are pretty clear that ppdd is busted for anything other than > block size of 1024 (THIS NEEDS TO BE FIXED!). You have to rebuild the > filesystem (mke2fs) with a block size of 1024. WARNING - this WILL destroy > everything on the filesystem! > > My laptop is even worse. The 12Gig drive insists on a transfer > size of 4096 to and from the IDE drive. That means I have to rebuild ALL > of my partitions for 1024 block size, but the drive itself is NOT 1024, > it's 4096. Then I have to specify a transfer block size of 4096 when > initializing and starting ppdd. Sigh... > > If you are going to use the block size option to the ppdd utilities > be forewarned that there are parsing bugs. The utilities expect exact > parameter counts and that screws up depending on whether or not you combine > parameters in the way the program expects. > > > I also used the USB patches from www.linux-usb.org with no conflict, so > > if you only want 2.3/4 for USB you might be able to scrape by. > > > > Bob > > > > -- > > Bob Hepple > > mailto:bhepple@bit.net.au > > Mike > -- > Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com > (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ > NIC whois: MHW9 | An optimist believes we live in the best of all > PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! 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 Fri Nov 24 12:36:14 2000 Received: by humbolt.nl.linux.org id ; Fri, 24 Nov 2000 12:35:29 +0100 Received: from eik.ii.uib.no ([129.177.16.3]:41091 "EHLO ii.uib.no") by humbolt.nl.linux.org with ESMTP id convert rfc822-to-8bit; Fri, 24 Nov 2000 12:35:01 +0100 Received: from apal.ii.uib.no [129.177.16.7] by ii.uib.no with esmtp (Exim 3.03) id 13zH8E-0001Pt-00 ; Fri, 24 Nov 2000 12:35:06 +0100 Received: (from gisle@localhost) by apal.ii.uib.no (8.8.8+Sun/8.8.7) id MAA14541; Fri, 24 Nov 2000 12:34:52 +0100 (MET) Date: Fri, 24 Nov 2000 12:34:52 +0100 (MET) From: Gisle S{lensminde To: John Kennedy cc: Marc Mutz , , Subject: Re: AES In-Reply-To: <20001123065524.B14860@north.csuchico.edu> 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, 23 Nov 2000, John Kennedy wrote: > On Mon, Nov 06, 2000 at 10:34:54AM +0100, Marc Mutz wrote: > > Emil wrote: > > > util-linux-2.10o.int.patch still doesn't include the AES encryption > > > Anyone plans to do it ? > > > > You can easily add it to the list of known ciphers in > > util-linux/mount/lomount.c > > Then re-compile both mount and losetup. > > I've been looking into what I would have to do to try and enable that. > Right now I'm using serpent (in the readme and in the source, plus > it works), but AES is supposed to be much faster (looking at NIST's > benchmarks). Well, not much in kerneli. The reason for that is that serpent is very well optimised, but rijndael is not that well optimised. The reason for that is that serpent is more "compiler frendly" than rijndael. To get a really fast rijndael implementation, we must implement one in assembly. -- 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 Sat Nov 25 17:52:34 2000 Received: by humbolt.nl.linux.org id ; Sat, 25 Nov 2000 17:51:42 +0100 Received: from north.net.CSUChico.EDU ([132.241.66.18]:65036 "EHLO north.net.csuchico.edu") by humbolt.nl.linux.org with ESMTP id ; Sat, 25 Nov 2000 17:51:11 +0100 Received: (from warlock@localhost) by north.net.csuchico.edu (8.11.0.Beta1/8.11.0.Beta0) id eAPGp1917136 for linux-crypto@nl.linux.org; Sat, 25 Nov 2000 08:51:02 -0800 Date: Sat, 25 Nov 2000 08:51:01 -0800 From: John Kennedy To: linux-crypto@nl.linux.org Subject: block ciphers & plaintext attacks Message-ID: <20001125085101.A16657@north.csuchico.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Ok, I've made a little proof-of-concept system that seems to be working, but I'm wondering how effective it will be over the long run. I've made a bootable CD-ROM with an initrd losetup-like bootstrap. The only unencrypted data will be on the boot floppy/cdrom which can be removed after bootup. That leaves me with about 8GB of serpent-encrypted filesystems on the harddrive. This has some different issues than I normally think about. The box is designed to be shut-down-secure (to the point of using an ext3 journalled filesystem for abrupt powerdowns), which is fine since getting caught with the filesystems mounted makes the encryption issues moot. In theory, you could send me something like known-plaintext-email or something, but then you would still need before-and-after access to my harddrive to compare. If anything, I'm wondering about its security in the face of someone having possession of the computer and trying to decrypt it. Right now, worst offense, I have a 1K bit of (fixed) random garbage on the front of my filesystem that I use to identify my filesystems before I try to mount them. Right now, that is a kludge (mostly because I didn't feel like trying to validate the superblock and I thought I might have to store some information). There are all kinds of ways I could take the curse off of it, but just how bad is that? Once you get past that, look at the filesystem superblocks. You get a lot more variables in it which would make it harder to bruteforce, but a *lot* of them are based on filesystem size and be a lot more predictable that you might think. How secure is that, really? At what point is someone going to get burned? I started out looking into it as a security and anti-tampering system -- even if someone did have physical possession or access to the hardware, it wouldn't do them a lot of good without a LOT (hopefully horribly prohibitive) of work. How many bits do I have to give them before my effort is all for naught? 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 Nov 26 17:46:23 2000 Received: by humbolt.nl.linux.org id ; Sun, 26 Nov 2000 17:45:41 +0100 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:13159 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Sun, 26 Nov 2000 17:45:13 +0100 Received: from Mutz.com (ppp36-141.hrz.uni-bielefeld.de [129.70.36.141]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G4N00493575FR@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Sun, 26 Nov 2000 17:45:06 +0100 (MET) Date: Sun, 26 Nov 2000 15:57:45 +0000 From: Marc Mutz Subject: Re: block ciphers & plaintext attacks To: John Kennedy Cc: linux-crypto@nl.linux.org Message-id: <3A2132F9.6C0ECCA0@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17i10-0001 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <20001125085101.A16657@north.csuchico.edu> Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list John Kennedy wrote: > > At what point is someone going to get burned? I started out looking > into it as a security and anti-tampering system -- even if someone did > have physical possession or access to the hardware, it wouldn't do them > a lot of good without a LOT (hopefully horribly prohibitive) of work. > How many bits do I have to give them before my effort is all for naught? In short: None. Long version: That is because you make the common mistake of Q> encryption == integrety. That is not so! The right equality is: Q> encryption == confidelity. You said, you wanted security and tamper-proofness. You got nothing of that, since anyone could substitute blocks. If you want a system that is tamper-proof, start by installing tripwire on that floppy disk and run it daily (YMMV). It is of course right that given an encrypted disk it is computationally infeasible (at least to the extent known to the public) to make a _subtle_ change. Poking around encrypted blocks and changing some of them will in general yield garbage. But the point is that, given that garbage, you cannot deduce from that whether the ciphertext has been tampered with or the garbage was there before encryption took place. So, I _guess_ that you want not only integrety-checking, but also confidelity. Serpent-encryption will buy you that. It is probably the most secure cipher known to the public at this point. But if you want integrety, then you should additionally install tripwire, read the Security-HOWTO and B. Schneier's Applied Cryptography. 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 Sun Nov 26 20:46:22 2000 Received: by humbolt.nl.linux.org id ; Sun, 26 Nov 2000 20:45:29 +0100 Received: from north.net.CSUChico.EDU ([132.241.66.18]:27151 "EHLO north.net.csuchico.edu") by humbolt.nl.linux.org with ESMTP id ; Sun, 26 Nov 2000 20:45:00 +0100 Received: (from warlock@localhost) by north.net.csuchico.edu (8.11.0.Beta1/8.11.0.Beta0) id eAQJioZ02797; Sun, 26 Nov 2000 11:44:50 -0800 Date: Sun, 26 Nov 2000 11:44:50 -0800 From: John Kennedy To: Marc Mutz Cc: linux-crypto@nl.linux.org Subject: Re: block ciphers & plaintext attacks Message-ID: <20001126114450.A1454@north.csuchico.edu> References: <20001125085101.A16657@north.csuchico.edu> <3A2132F9.6C0ECCA0@Mutz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3A2132F9.6C0ECCA0@Mutz.com>; from Marc@Mutz.com on Sun, Nov 26, 2000 at 03:57:45PM +0000 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Sun, Nov 26, 2000 at 03:57:45PM +0000, Marc Mutz wrote: > John Kennedy wrote: > > > At what point is someone going to get burned? I started out looking > > into it as a security and anti-tampering system -- even if someone did > > have physical possession or access to the hardware, it wouldn't do them > > a lot of good without a LOT (hopefully horribly prohibitive) of work. > > How many bits do I have to give them before my effort is all for naught? > > > In short: None. I think you're missing my point, but you come around to it, below. > Long version: That is because you make the common mistake of > Q> encryption == integrety. > That is not so! The right equality is: > Q> encryption == confidelity. Well, no I didn't but I didn't say that in the email. It isn't like we're talking digital signatures here, but the inability to change blocks on the disk without garbaging it comes close. I do get your "encryption == confidentiality" point though. > You said, you wanted security and tamper-proofness. You got nothing of > that, since anyone could substitute blocks. If you want a system that is > tamper-proof, start by installing tripwire ... I'm looking at AUGMENTING tripwire-like security, not replacing it. I'm exploiting the encryption, taking advantage of the fact that improperly encrypted blocks will yield garbage instead of compromised data. Yes, I'm sort of abusing the cryptography to achieve this goal. It is a whole lot easier dealing with garbaged data than tampered data. > It is of course right that given an encrypted disk it is computationally > infeasible (at least to the extent known to the public) to make a > _subtle_ change. Poking around encrypted blocks and changing some of > them will in general yield garbage. But the point is that, given that > garbage, you cannot deduce from that whether the ciphertext has been > tampered with or the garbage was there before encryption took place. Yes, this is what I'm exploiting. I'm looking at potential garbage as a denial-of-service. Tampering can be far worse, but I'm digressing again. > So, I _guess_ that you want not only integrety-checking, but also > confidelity. Serpent-encryption will buy you that. It is probably the > most secure cipher known to the public at this point. But if you want > integrety, then you should additionally install tripwire, read the > Security-HOWTO and B. Schneier's Applied Cryptography. Bingo, exactly. Using tripwire or equivalent to augment. I think this negates your short answer though. Which sort of gets us back to my original question. I have an encrypted filesystem that an attacker will have to get through before they can get at the data that is on it. They don't know the password, but they have a statisticly good idea of what some of it is (primarily the superblock, with a lot of the information contained in it being based on the partition size, etc). I'm sort of looking for an experience-based answer off of the top of your (or anyone's) head, but we're mixing generalities with math and crypto (not a good combo). I'm wanting to know how much encrypted- knowntext you would need to really compromise the serpent password, which would let you turn around and compromise the rest of the disk. 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 Nov 27 07:17:22 2000 Received: by humbolt.nl.linux.org id ; Mon, 27 Nov 2000 07:16:50 +0100 Received: from f125.law11.hotmail.com ([64.4.17.125]:42505 "EHLO hotmail.com") by humbolt.nl.linux.org with ESMTP id ; Mon, 27 Nov 2000 07:16:16 +0100 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 26 Nov 2000 22:16:14 -0800 Received: from 202.42.198.18 by lw11fd.law11.hotmail.msn.com with HTTP; Mon, 27 Nov 2000 06:16:14 GMT X-Originating-IP: [202.42.198.18] From: "Louis Lam" To: linux-crypto@nl.linux.org, ppdd@linux01.gwdg.de Subject: Where is the ppdd mailing list archive? Date: Mon, 27 Nov 2000 14:16:14 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Nov 2000 06:16:14.0291 (UTC) FILETIME=[8B7BF230:01C05839] Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Hi, Just like to know where is the PPDD mailing list archive where previous messages from the mailing list are stored. Thanks Louis _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com 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 Nov 27 09:10:43 2000 Received: by humbolt.nl.linux.org id ; Mon, 27 Nov 2000 09:10:11 +0100 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:60116 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Mon, 27 Nov 2000 09:09:35 +0100 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 <0G4O0039TBZXZN@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Mon, 27 Nov 2000 09:09:33 +0100 (MET) Date: Mon, 27 Nov 2000 09:09:39 +0100 From: Marc Mutz Subject: Re: block ciphers & plaintext attacks To: John Kennedy Cc: linux-crypto@nl.linux.org Message-id: <3A2216C3.519BFB6@Mutz.com> Organization: Bielefeld University - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17-21mdk i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <20001125085101.A16657@north.csuchico.edu> <3A2132F9.6C0ECCA0@Mutz.com> <20001126114450.A1454@north.csuchico.edu> Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list John Kennedy wrote: > > I'm sort of looking for an experience-based answer off of the top of > your (or anyone's) head, but we're mixing generalities with math and > crypto (not a good combo). I'm wanting to know how much encrypted- > knowntext you would need to really compromise the serpent password, > which would let you turn around and compromise the rest of the disk. > For what is publicly nown, serpent is secure, no matter what. There are academic attacks against reduced-round versions, but the cipher as defined in the AES paper is secure. Yet that is no guarantee. Tomorrow may see a complete break of serpent, but that is unlikely, of course. Serpent is a 128 bit blockcipher, meaning, you can encrypt many, _many_ Gigabytes with it before you get equal ciphertext blocks, which would give an attacker some hints. So no problems from that front, too. The most probable point of attack is your passphrase. I'd almost bet that it does not contain 128 bits of entropy. and if it is just an English sentence, it would only contain 1.3 bits/char of entropy. If you want to know about the feasibilty of a known-plaintext attack: No such attack is known that is faster than brute force. Yet brute-forcing your passphrase may be well feasible. Does that answer your question? 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 Nov 27 18:48:18 2000 Received: by humbolt.nl.linux.org id ; Mon, 27 Nov 2000 18:47:12 +0100 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:51583 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Mon, 27 Nov 2000 18:46:45 +0100 Received: from Mutz.com (ppp36-199.hrz.uni-bielefeld.de [129.70.36.199]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G4P002PY2PN93@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Mon, 27 Nov 2000 18:46:39 +0100 (MET) Date: Mon, 27 Nov 2000 15:00:44 +0000 From: Marc Mutz Subject: Re: [PPDD] Where is the ppdd mailing list archive? To: ppdd@linux01.gwdg.de Cc: linux-crypto@nl.linux.org Message-id: <3A22771C.A5B43610@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17i10-0001 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 Louis Lam wrote: > > Hi, > > Just like to know where is the PPDD mailing list archive where previous > messages from the mailing list are stored. > http://marc.theaimsgroup.com should have them. 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 Mon Nov 27 20:30:36 2000 Received: by humbolt.nl.linux.org id ; Mon, 27 Nov 2000 20:29:52 +0100 Received: from north.net.CSUChico.EDU ([132.241.66.18]:19474 "EHLO north.net.csuchico.edu") by humbolt.nl.linux.org with ESMTP id ; Mon, 27 Nov 2000 20:29:23 +0100 Received: (from warlock@localhost) by north.net.csuchico.edu (8.11.0.Beta1/8.11.0.Beta0) id eARJTFp19277; Mon, 27 Nov 2000 11:29:15 -0800 Date: Mon, 27 Nov 2000 11:29:15 -0800 From: John Kennedy To: Marc Mutz Cc: linux-crypto@nl.linux.org Subject: Re: block ciphers & plaintext attacks Message-ID: <20001127112915.C17826@north.csuchico.edu> References: <20001125085101.A16657@north.csuchico.edu> <3A2132F9.6C0ECCA0@Mutz.com> <20001126114450.A1454@north.csuchico.edu> <3A2216C3.519BFB6@Mutz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3A2216C3.519BFB6@Mutz.com>; from Marc@Mutz.com on Mon, Nov 27, 2000 at 09:09:39AM +0100 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Mon, Nov 27, 2000 at 09:09:39AM +0100, Marc Mutz wrote: > John Kennedy wrote: > > > I'm sort of looking for an experience-based answer off of the top of > > your (or anyone's) head, but we're mixing generalities with math and > > crypto (not a good combo). I'm wanting to know how much encrypted- > > knowntext you would need to really compromise the serpent password, > > which would let you turn around and compromise the rest of the disk. > > For what is publicly nown, serpent is secure, no matter what. There are > academic attacks against reduced-round versions, but the cipher as > defined in the AES paper is secure. Yet that is no guarantee. Tomorrow > may see a complete break of serpent, but that is unlikely, of course. > Serpent is a 128 bit blockcipher, meaning, you can encrypt many, _many_ > Gigabytes with it before you get equal ciphertext blocks, which would > give an attacker some hints. So no problems from that front, too. The > most probable point of attack is your passphrase. I'd almost bet that it > does not contain 128 bits of entropy. and if it is just an English > sentence, it would only contain 1.3 bits/char of entropy. As I understand them so far, those are the words I wanted to hear. I was actually assuming that my passphrase was what was going to be attacked (I expected that it would be the easier of the two). As far as passphrase entropy, I'm a bit ignorant at the moment. I initially coded to be compatible with losetup, presuming that it would be coded in a secure fashion. Without a lot more reading, I can't say if that is true or not though. I'm under the impression that the 1.3 bits/char problem is pretty common and that one of the first things you do is run it through a one-way hash, generating something that looks far more like random bits. I see the two calls to rmd160_hash_buffer(), but I haven't confirmed that what they're actually doing is something like what I've been told. > If you want to know about the feasibilty of a known-plaintext attack: No > such attack is known that is faster than brute force. Yet brute-forcing > your passphrase may be well feasible. > > Does that answer your question? Enough to spend my time productively on the passphrase, yes. (: Either the current losetup code will be secure or not and, if not, I'll just add another layer with a passphrase protecting an encrypted passphrase to the real data on the disk. (Yes, you could still try to brute-force the first passphrase, but it and the encrypted 2nd passphrase can easily be kept apart from the hard-drive encrypted with the 2nd passphrase. If rmd160_hash_buffer() doesn't introduce enough entropy, that ought to help a lot.) 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 Nov 28 15:49:11 2000 Received: by humbolt.nl.linux.org id ; Tue, 28 Nov 2000 15:48:36 +0100 Received: from midten.fast.no ([213.188.8.11]:59152 "EHLO midten.fast.no") by humbolt.nl.linux.org with ESMTP id ; Tue, 28 Nov 2000 15:48:01 +0100 Received: (from astor@localhost) by midten.fast.no (8.9.3/8.9.3) id PAA02848 for linux-crypto@nl.linux.org; Tue, 28 Nov 2000 15:47:59 +0100 (CET) Date: Tue, 28 Nov 2000 15:47:58 +0100 From: Alexander S A Kjeldaas To: linux-crypto@nl.linux.org Subject: Intl. patch 2.2.17.11pre1 Message-ID: <20001128154758.A94834@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 A new prepatch is out. I have made it a prepatch because it includes more changes than normal, and also because some more changes are needed before a new stable patch can be released. Short list of changes: o New util-linux patch (util-linux-2.10o.int2). You need to recompile util-linux using this patch! o key schedule size and declarations for ciphers/digests moved out of crypto.h o New functions in cipher_implementation - realloc_context - to (re)allocate a cipher_context - wipe_context - to wipe a cipher_context - free_context - to free a cipher_context Cipher-implementations with fixed size key schedules don't have to provide any of the above, and default implementation will be provided. o find_transfer_by_name now tries to load missing ciphers/digests. o ECB ciphers now called -ecb, not just . o Lots of functions that should be static are now static. No more conflicts with freeswan over the SHA/MD5. o loop_gen.c is no more. Integrated loop_gen.c with loop.c. Reverted a lot of changes to loop.{c,h} - It is now pretty much like vanilla linux 2.2.x. ----- Based on some feedback I got from people trying to write plugins to the cryptoapi, it became evident that the current scheme for finding ciphers is inadequate. We now have two ways of finding ciphers/digests: find_{cipher,digest}_by_id, and find_{cipher,digest}_by_name The problem is that the id scheme isn't useful for plug-ins. It also means we have to have translation tables all over the place translating from cipher name to id. Generally, a system where all ciphers have to register an ID is very cumbersome. Just look at how we deal with ciphers in the case of losetup: - We have /etc/modules.conf which has a mapping: - from loop_xfer_number -> loop_xfer_module - from cipher_id -> cipher - from digest_id -> digest - We have losetup which has a mapping from loop_xfer_number -> name of cipher and keysize in order to handle user-interface issues and to make sure that it gives enough key data to the kernel. - We have the loop_gen module registering a number of loop_xfers in the loop module and then translating the xfer number to the corresponding cipher number. :-) Quite messy. It is the loopback system which led to these problems. If we can get losetup to use _strings_ to select its cipher, _none_ of the above tables would be needed anymore, we could support plug-in crypto modules more easily, and we wouldn't have to keep losetup in synch with the kernel all the time. This patch does this by killing the old loop_gen.c stuff, and adding a new loop_xfer called LO_CRYPT_CRYPTOAPI. It works like this: There is a field in struct loop_status (used to set password, transfer type etc.) called lo_name which contains the path of the underlying file. It seems that this field is not used by the kernel in any way, and is just an old workaround for not having dentries in early linux kernels. So when user-space requests to set up a transfer of type LO_CRYPT_CRYPTOAPI, we expect the name of the cipher to be specified in this field. This is all handled in the init-function of the LO_CRYPT_CRYPTOAPI transfer. There is also similar changes in the util-linux patch. I've removed all the tables with kerneli-specific cipher information. Then, if losetup doesn't find any information about the cipher the user specifies, is assumes it is a LO_CRYPT_CRYPTOAPI cipher. It parses /proc/crypto/cipher/%s-cbc to find information about allowed key sizes. This patch is called util-linux-2.10o.int2.patch. The kernel will now try to load ciphers if it can't find them (and CONFIG_KMOD is on). It works like this: Say you want to look for "serpent-cbc", it will try to load the following modules until it finds the cipher or run out of options: cipher-serpent-cbc cipher-serpent cipher This supports the way modules are written today where a single module implements both serpent-cbc, and serpent-ecb. In a later patch, the various cipher and digest modules should be renamed to work with the above scheme. For the time being, you should rename your favorite cipher (i.e, rename /lib/modules/2.2.17/misc/serp6f.o -> /lib/modules/2.2.17/misc/cipher-serpent.o) to play with this patch. 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 Nov 28 19:27:12 2000 Received: by humbolt.nl.linux.org id ; Tue, 28 Nov 2000 19:26:26 +0100 Received: from north.net.CSUChico.EDU ([132.241.66.18]:2823 "EHLO north.net.csuchico.edu") by humbolt.nl.linux.org with ESMTP id ; Tue, 28 Nov 2000 19:26:05 +0100 Received: (from warlock@localhost) by north.net.csuchico.edu (8.11.0.Beta1/8.11.0.Beta0) id eASIPsm03894; Tue, 28 Nov 2000 10:25:54 -0800 Date: Tue, 28 Nov 2000 10:25:54 -0800 From: John Kennedy To: Alexander S A Kjeldaas Cc: linux-crypto@nl.linux.org Subject: Re: Intl. patch 2.2.17.11pre1 Message-ID: <20001128102554.B3632@north.csuchico.edu> References: <20001128154758.A94834@midten.fast.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20001128154758.A94834@midten.fast.no>; from Alexander.Kjeldaas@fast.no on Tue, Nov 28, 2000 at 03:47:58PM +0100 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Tue, Nov 28, 2000 at 03:47:58PM +0100, Alexander S A Kjeldaas wrote: > A new prepatch is out. I have made it a prepatch because it includes > more changes than normal, ... It doesn't seem to be propagating around. Can you mail it to me or point me to a site that is actually carrying it? 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 Nov 28 19:35:12 2000 Received: by humbolt.nl.linux.org id ; Tue, 28 Nov 2000 19:34:38 +0100 Received: from midten.fast.no ([213.188.8.11]:4108 "EHLO midten.fast.no") by humbolt.nl.linux.org with ESMTP id ; Tue, 28 Nov 2000 19:33:57 +0100 Received: (from astor@localhost) by midten.fast.no (8.9.3/8.9.3) id TAA11328; Tue, 28 Nov 2000 19:33:51 +0100 (CET) Date: Tue, 28 Nov 2000 19:33:51 +0100 From: Alexander S A Kjeldaas To: John Kennedy Cc: Alexander S A Kjeldaas , linux-crypto@nl.linux.org Subject: Re: Intl. patch 2.2.17.11pre1 Message-ID: <20001128193350.A10769@midten.fast.no> References: <20001128154758.A94834@midten.fast.no> <20001128102554.B3632@north.csuchico.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <20001128102554.B3632@north.csuchico.edu>; from John Kennedy on Tue, Nov 28, 2000 at 10:25:54AM -0800 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Tue, Nov 28, 2000 at 10:25:54AM -0800, John Kennedy wrote: > On Tue, Nov 28, 2000 at 03:47:58PM +0100, Alexander S A Kjeldaas wrote: > > A new prepatch is out. I have made it a prepatch because it includes > > more changes than normal, ... > > It doesn't seem to be propagating around. Can you mail it to me or > point me to a site that is actually carrying it? Forgot to mention this.. it's not in the kernel/crypto directory, but rather in: ftp://ftp.kernel.org/pub/linux/kernel/people/astor/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 Wed Nov 29 00:56:10 2000 Received: by humbolt.nl.linux.org id ; Wed, 29 Nov 2000 00:55:37 +0100 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:25126 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Wed, 29 Nov 2000 00:54:56 +0100 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 <0G4R00GEMEFDZJ@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Wed, 29 Nov 2000 00:54:50 +0100 (MET) Date: Tue, 28 Nov 2000 18:08:22 +0000 From: Marc Mutz Subject: Re: block ciphers & plaintext attacks To: John Kennedy Cc: linux-crypto@nl.linux.org Message-id: <3A23F496.66BEFFB5@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17i10-0001 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <20001125085101.A16657@north.csuchico.edu> <3A2132F9.6C0ECCA0@Mutz.com> <20001126114450.A1454@north.csuchico.edu> <3A2216C3.519BFB6@Mutz.com> <20001127112915.C17826@north.csuchico.edu> Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list John Kennedy wrote: > > As far as passphrase entropy, I'm a bit ignorant at the moment. I > initially coded to be compatible with losetup, presuming that it would > be coded in a secure fashion. Without a lot more reading, I can't say > if that is true or not though. > > I'm under the impression that the 1.3 bits/char problem is pretty common > and that one of the first things you do is run it through a one-way hash, > generating something that looks far more like random bits. I see the > two calls to rmd160_hash_buffer(), but I haven't confirmed that what > they're actually doing is something like what I've been told. > losetup takes the passphrase-string, calculates the ripe-md hash function of that string and uses the resulting bitstring as the key to the cipher (serpent, in your case). > Enough to spend my time productively on the passphrase, yes. (: Either > the current losetup code will be secure or not and, if not, I'll just > add another layer with a passphrase protecting an encrypted passphrase > to the real data on the disk. > The losetup code is as secure as it can get. > (Yes, you could still try to brute-force the first passphrase, but it > and the encrypted 2nd passphrase can easily be kept apart from the > hard-drive encrypted with the 2nd passphrase. If rmd160_hash_buffer() > doesn't introduce enough entropy, that ought to help a lot.) Hashing _never_ (!!!) introduces entropy. It might even _decrease_ your entropy by a few bits. Entropy can be rougly defined as the number of bits you need to store a certain data set. E.g. a random 32 bit value has 32 bits of entropy, because you can store 2^32 states with it. Yet a 4-character string containing only the 26 letters can have at most lb(26^4)=18.75 bits of entropy (where lb is logarithm w.r.t. base 2), since you can only encode 26^4 ~= 2^18.75 states with this. The famous 1.3 bits/char are valid for english running text. So, if you want to have a passphrase that is as secure as the cipher is (i.e attacking the passphrase is not much faster than attacking the key directly), you have to enter approx. 100 characters of english text. This will give you a passphrase of ca. 130 bits entropy which in turn is fed into the hash function to produce a bit string with around 128 bits of entropy (hashes lose entropy because they are not bijective from GF(2^128) onto itself). Yet that string is 160 bits long and only the frst 128 bits of it are taken as the passphrase. Thus, your key's entropy can be approximated to be 128*(128/160)=102 bits. But that is good enough. You see, there's a _lot_ more to security than ciphers. You should really read (and understand) Applied Cryptography, if you take your thing serious. 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 Nov 29 04:40:36 2000 Received: by humbolt.nl.linux.org id ; Wed, 29 Nov 2000 04:39:54 +0100 Received: from north.net.CSUChico.EDU ([132.241.66.18]:60936 "EHLO north.net.csuchico.edu") by humbolt.nl.linux.org with ESMTP id ; Wed, 29 Nov 2000 04:39:27 +0100 Received: (from warlock@localhost) by north.net.csuchico.edu (8.11.0.Beta1/8.11.0.Beta0) id eAT3dP510895 for linux-crypto@nl.linux.org; Tue, 28 Nov 2000 19:39:25 -0800 Date: Tue, 28 Nov 2000 19:39:24 -0800 From: John Kennedy To: linux-crypto@nl.linux.org Subject: Re: Intl. patch 2.2.17.11pre1 Message-ID: <20001128193924.B10865@north.csuchico.edu> References: <20001128154758.A94834@midten.fast.no> <20001128102554.B3632@north.csuchico.edu> <20001128193350.A10769@midten.fast.no> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tsOsTdHNUZQcU9Ye" X-Mailer: Mutt 1.0.1i In-Reply-To: <20001128193350.A10769@midten.fast.no>; from Alexander.Kjeldaas@fast.no on Tue, Nov 28, 2000 at 07:33:51PM +0100 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list --tsOsTdHNUZQcU9Ye Content-Type: text/plain; charset=us-ascii On Tue, Nov 28, 2000 at 07:33:51PM +0100, Alexander S A Kjeldaas wrote: > Forgot to mention this.. it's not in the kernel/crypto directory, but > rather in: > > ftp://ftp.kernel.org/pub/linux/kernel/people/astor/v2.2/ I think Alan has been backporting some code. I've needed this with everything I've tried against 2.2.18pre* so far. --tsOsTdHNUZQcU9Ye Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-int-2.2.17.11pre1+cryptoapi" --- ./crypto/cryptoapi.c.OLD Tue Nov 28 18:57:09 2000 +++ ./crypto/cryptoapi.c Tue Nov 28 19:30:58 2000 @@ -65,7 +65,7 @@ }; #ifdef CONFIG_PROC_FS -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,0) +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,2,18) /* We have to emulate the 2.4 function proc_mkdir, because it is not * present in 2.2 - HW */ static struct proc_dir_entry * --tsOsTdHNUZQcU9Ye-- 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 Nov 29 07:16:55 2000 Received: by humbolt.nl.linux.org id ; Wed, 29 Nov 2000 07:16:24 +0100 Received: from north.net.CSUChico.EDU ([132.241.66.18]:16905 "EHLO north.net.csuchico.edu") by humbolt.nl.linux.org with ESMTP id ; Wed, 29 Nov 2000 07:15:54 +0100 Received: (from warlock@localhost) by north.net.csuchico.edu (8.11.0.Beta1/8.11.0.Beta0) id eAT6FYY12766; Tue, 28 Nov 2000 22:15:34 -0800 Date: Tue, 28 Nov 2000 22:15:34 -0800 From: John Kennedy To: Alexander S A Kjeldaas Cc: linux-crypto@nl.linux.org Subject: Re: Intl. patch 2.2.17.11pre1 Message-ID: <20001128221534.A12048@north.csuchico.edu> References: <20001128154758.A94834@midten.fast.no> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="rwEMma7ioTxnRzrJ" X-Mailer: Mutt 1.0.1i In-Reply-To: <20001128154758.A94834@midten.fast.no>; from Alexander.Kjeldaas@fast.no on Tue, Nov 28, 2000 at 03:47:58PM +0100 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii On Tue, Nov 28, 2000 at 03:47:58PM +0100, Alexander S A Kjeldaas wrote: > Short list of changes: > o New util-linux patch (util-linux-2.10o.int2). You need to recompile > util-linux using this patch! ... I think you're missing a few files from your patch. rmd160.c & .h are missing and the prototype in lomount.h for set_loop() doesn't match what is in mount.c (and my patch is probably incorrect since I'm more interested in exercising my kernel patches than testing mount at the moment). Anyway, you may want to take a look at it. --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="PATCH.util-linux-2.10q+crypto+jk" --- ./mount/mount.c.OLD Tue Nov 28 21:36:03 2000 +++ ./mount/mount.c Tue Nov 28 21:52:55 2000 @@ -575,7 +575,7 @@ if (verbose) printf(_("mount: going to use the loop device %s\n"), *loopdev); offset = opt_offset ? strtoul(opt_offset, NULL, 0) : 0; - if (set_loop (*loopdev, *loopfile, offset, opt_encryption, pfd, &loopro)) { + if (set_loop (*loopdev, *loopfile, offset, opt_encryption, pfd, 0, &loopro)) { if (verbose) printf(_("mount: failed setting up loop device\n")); return EX_FAIL; --- ./mount/rmd160.c.OLD Tue Nov 28 22:03:14 2000 +++ ./mount/rmd160.c Thu Nov 9 22:47:04 2000 @@ -0,0 +1,532 @@ +/* rmd160.c - RIPE-MD160 + * Copyright (C) 1998 Free Software Foundation, Inc. + */ + +/* This file was part of GnuPG. Modified for use within the Linux + * mount utility by Marc Mutz . None of this code is + * by myself. I just removed everything that you don't need when all + * you want to do is to use rmd160_hash_buffer(). + * My comments are marked with (mm). */ + +/* GnuPG is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * GnuPG is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA */ + +#include /* (mm) for memcpy */ +#include /* (mm) for BIG_ENDIAN and BYTE_ORDER */ +#include "rmd160.h" + +/* (mm) these are used by the original GnuPG file. In order to modify + * that file not too much, we keep the notations. maybe it would be + * better to include linux/types.h and typedef __u32 to u32 and __u8 + * to byte? */ +typedef unsigned int u32; /* taken from e.g. util-linux's minix.h */ +typedef unsigned char byte; + +typedef struct { + u32 h0,h1,h2,h3,h4; + u32 nblocks; + byte buf[64]; + int count; +} RMD160_CONTEXT; + +/**************** + * Rotate a 32 bit integer by n bytes + */ +#if defined(__GNUC__) && defined(__i386__) +static inline u32 +rol( u32 x, int n) +{ + __asm__("roll %%cl,%0" + :"=r" (x) + :"0" (x),"c" (n)); + return x; +} +#else + #define rol(x,n) ( ((x) << (n)) | ((x) >> (32-(n))) ) +#endif + +/********************************* + * RIPEMD-160 is not patented, see (as of 25.10.97) + * http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html + * Note that the code uses Little Endian byteorder, which is good for + * 386 etc, but we must add some conversion when used on a big endian box. + * + * + * Pseudo-code for RIPEMD-160 + * + * RIPEMD-160 is an iterative hash function that operates on 32-bit words. + * The round function takes as input a 5-word chaining variable and a 16-word + * message block and maps this to a new chaining variable. All operations are + * defined on 32-bit words. Padding is identical to that of MD4. + * + * + * RIPEMD-160: definitions + * + * + * nonlinear functions at bit level: exor, mux, -, mux, - + * + * f(j, x, y, z) = x XOR y XOR z (0 <= j <= 15) + * f(j, x, y, z) = (x AND y) OR (NOT(x) AND z) (16 <= j <= 31) + * f(j, x, y, z) = (x OR NOT(y)) XOR z (32 <= j <= 47) + * f(j, x, y, z) = (x AND z) OR (y AND NOT(z)) (48 <= j <= 63) + * f(j, x, y, z) = x XOR (y OR NOT(z)) (64 <= j <= 79) + * + * + * added constants (hexadecimal) + * + * K(j) = 0x00000000 (0 <= j <= 15) + * K(j) = 0x5A827999 (16 <= j <= 31) int(2**30 x sqrt(2)) + * K(j) = 0x6ED9EBA1 (32 <= j <= 47) int(2**30 x sqrt(3)) + * K(j) = 0x8F1BBCDC (48 <= j <= 63) int(2**30 x sqrt(5)) + * K(j) = 0xA953FD4E (64 <= j <= 79) int(2**30 x sqrt(7)) + * K'(j) = 0x50A28BE6 (0 <= j <= 15) int(2**30 x cbrt(2)) + * K'(j) = 0x5C4DD124 (16 <= j <= 31) int(2**30 x cbrt(3)) + * K'(j) = 0x6D703EF3 (32 <= j <= 47) int(2**30 x cbrt(5)) + * K'(j) = 0x7A6D76E9 (48 <= j <= 63) int(2**30 x cbrt(7)) + * K'(j) = 0x00000000 (64 <= j <= 79) + * + * + * selection of message word + * + * r(j) = j (0 <= j <= 15) + * r(16..31) = 7, 4, 13, 1, 10, 6, 15, 3, 12, 0, 9, 5, 2, 14, 11, 8 + * r(32..47) = 3, 10, 14, 4, 9, 15, 8, 1, 2, 7, 0, 6, 13, 11, 5, 12 + * r(48..63) = 1, 9, 11, 10, 0, 8, 12, 4, 13, 3, 7, 15, 14, 5, 6, 2 + * r(64..79) = 4, 0, 5, 9, 7, 12, 2, 10, 14, 1, 3, 8, 11, 6, 15, 13 + * r0(0..15) = 5, 14, 7, 0, 9, 2, 11, 4, 13, 6, 15, 8, 1, 10, 3, 12 + * r0(16..31)= 6, 11, 3, 7, 0, 13, 5, 10, 14, 15, 8, 12, 4, 9, 1, 2 + * r0(32..47)= 15, 5, 1, 3, 7, 14, 6, 9, 11, 8, 12, 2, 10, 0, 4, 13 + * r0(48..63)= 8, 6, 4, 1, 3, 11, 15, 0, 5, 12, 2, 13, 9, 7, 10, 14 + * r0(64..79)= 12, 15, 10, 4, 1, 5, 8, 7, 6, 2, 13, 14, 0, 3, 9, 11 + * + * + * amount for rotate left (rol) + * + * s(0..15) = 11, 14, 15, 12, 5, 8, 7, 9, 11, 13, 14, 15, 6, 7, 9, 8 + * s(16..31) = 7, 6, 8, 13, 11, 9, 7, 15, 7, 12, 15, 9, 11, 7, 13, 12 + * s(32..47) = 11, 13, 6, 7, 14, 9, 13, 15, 14, 8, 13, 6, 5, 12, 7, 5 + * s(48..63) = 11, 12, 14, 15, 14, 15, 9, 8, 9, 14, 5, 6, 8, 6, 5, 12 + * s(64..79) = 9, 15, 5, 11, 6, 8, 13, 12, 5, 12, 13, 14, 11, 8, 5, 6 + * s'(0..15) = 8, 9, 9, 11, 13, 15, 15, 5, 7, 7, 8, 11, 14, 14, 12, 6 + * s'(16..31)= 9, 13, 15, 7, 12, 8, 9, 11, 7, 7, 12, 7, 6, 15, 13, 11 + * s'(32..47)= 9, 7, 15, 11, 8, 6, 6, 14, 12, 13, 5, 14, 13, 13, 7, 5 + * s'(48..63)= 15, 5, 8, 11, 14, 14, 6, 14, 6, 9, 12, 9, 12, 5, 15, 8 + * s'(64..79)= 8, 5, 12, 9, 12, 5, 14, 6, 8, 13, 6, 5, 15, 13, 11, 11 + * + * + * initial value (hexadecimal) + * + * h0 = 0x67452301; h1 = 0xEFCDAB89; h2 = 0x98BADCFE; h3 = 0x10325476; + * h4 = 0xC3D2E1F0; + * + * + * RIPEMD-160: pseudo-code + * + * It is assumed that the message after padding consists of t 16-word blocks + * that will be denoted with X[i][j], with 0 <= i <= t-1 and 0 <= j <= 15. + * The symbol [+] denotes addition modulo 2**32 and rol_s denotes cyclic left + * shift (rotate) over s positions. + * + * + * for i := 0 to t-1 { + * A := h0; B := h1; C := h2; D = h3; E = h4; + * A' := h0; B' := h1; C' := h2; D' = h3; E' = h4; + * for j := 0 to 79 { + * T := rol_s(j)(A [+] f(j, B, C, D) [+] X[i][r(j)] [+] K(j)) [+] E; + * A := E; E := D; D := rol_10(C); C := B; B := T; + * T := rol_s'(j)(A' [+] f(79-j, B', C', D') [+] X[i][r'(j)] + [+] K'(j)) [+] E'; + * A' := E'; E' := D'; D' := rol_10(C'); C' := B'; B' := T; + * } + * T := h1 [+] C [+] D'; h1 := h2 [+] D [+] E'; h2 := h3 [+] E [+] A'; + * h3 := h4 [+] A [+] B'; h4 := h0 [+] B [+] C'; h0 := T; + * } + */ + +/* Some examples: + * "" 9c1185a5c5e9fc54612808977ee8f548b2258d31 + * "a" 0bdc9d2d256b3ee9daae347be6f4dc835a467ffe + * "abc" 8eb208f7e05d987a9b044a8e98c6b087f15a0bfc + * "message digest" 5d0689ef49d2fae572b881b123a85ffa21595f36 + * "a...z" f71c27109c692c1b56bbdceb5b9d2865b3708dbc + * "abcdbcde...nopq" 12a053384a9c0c88e405a06c27dcf49ada62eb2b + * "A...Za...z0...9" b0e20b6e3116640286ed3a87a5713079b21f5189 + * 8 times "1234567890" 9b752e45573d4b39f4dbd3323cab82bf63326bfb + * 1 million times "a" 52783243c1697bdbe16d37f97f68f08325dc1528 + */ + + +static void +rmd160_init( RMD160_CONTEXT *hd ) +{ + hd->h0 = 0x67452301; + hd->h1 = 0xEFCDAB89; + hd->h2 = 0x98BADCFE; + hd->h3 = 0x10325476; + hd->h4 = 0xC3D2E1F0; + hd->nblocks = 0; + hd->count = 0; +} + + + +/**************** + * Transform the message X which consists of 16 32-bit-words + */ +static void +transform( RMD160_CONTEXT *hd, byte *data ) +{ + u32 a,b,c,d,e,aa,bb,cc,dd,ee,t; + #if BYTE_ORDER == BIG_ENDIAN + u32 x[16]; + { int i; + byte *p2, *p1; + for(i=0, p1=data, p2=(byte*)x; i < 16; i++, p2 += 4 ) { + p2[3] = *p1++; + p2[2] = *p1++; + p2[1] = *p1++; + p2[0] = *p1++; + } + } + #else + #if 0 + u32 *x =(u32*)data; + #else + /* this version is better because it is always aligned; + * The performance penalty on a 586-100 is about 6% which + * is acceptable - because the data is more local it might + * also be possible that this is faster on some machines. + * This function (when compiled with -02 on gcc 2.7.2) + * executes on a 586-100 (39.73 bogomips) at about 1900kb/sec; + * [measured with a 4MB data and "gpgm --print-md rmd160"] */ + u32 x[16]; + memcpy( x, data, 64 ); + #endif + #endif + + +#define K0 0x00000000 +#define K1 0x5A827999 +#define K2 0x6ED9EBA1 +#define K3 0x8F1BBCDC +#define K4 0xA953FD4E +#define KK0 0x50A28BE6 +#define KK1 0x5C4DD124 +#define KK2 0x6D703EF3 +#define KK3 0x7A6D76E9 +#define KK4 0x00000000 +#define F0(x,y,z) ( (x) ^ (y) ^ (z) ) +#define F1(x,y,z) ( ((x) & (y)) | (~(x) & (z)) ) +#define F2(x,y,z) ( ((x) | ~(y)) ^ (z) ) +#define F3(x,y,z) ( ((x) & (z)) | ((y) & ~(z)) ) +#define F4(x,y,z) ( (x) ^ ((y) | ~(z)) ) +#define R(a,b,c,d,e,f,k,r,s) do { t = a + f(b,c,d) + k + x[r]; \ + a = rol(t,s) + e; \ + c = rol(c,10); \ + } while(0) + + /* left lane */ + a = hd->h0; + b = hd->h1; + c = hd->h2; + d = hd->h3; + e = hd->h4; + R( a, b, c, d, e, F0, K0, 0, 11 ); + R( e, a, b, c, d, F0, K0, 1, 14 ); + R( d, e, a, b, c, F0, K0, 2, 15 ); + R( c, d, e, a, b, F0, K0, 3, 12 ); + R( b, c, d, e, a, F0, K0, 4, 5 ); + R( a, b, c, d, e, F0, K0, 5, 8 ); + R( e, a, b, c, d, F0, K0, 6, 7 ); + R( d, e, a, b, c, F0, K0, 7, 9 ); + R( c, d, e, a, b, F0, K0, 8, 11 ); + R( b, c, d, e, a, F0, K0, 9, 13 ); + R( a, b, c, d, e, F0, K0, 10, 14 ); + R( e, a, b, c, d, F0, K0, 11, 15 ); + R( d, e, a, b, c, F0, K0, 12, 6 ); + R( c, d, e, a, b, F0, K0, 13, 7 ); + R( b, c, d, e, a, F0, K0, 14, 9 ); + R( a, b, c, d, e, F0, K0, 15, 8 ); + R( e, a, b, c, d, F1, K1, 7, 7 ); + R( d, e, a, b, c, F1, K1, 4, 6 ); + R( c, d, e, a, b, F1, K1, 13, 8 ); + R( b, c, d, e, a, F1, K1, 1, 13 ); + R( a, b, c, d, e, F1, K1, 10, 11 ); + R( e, a, b, c, d, F1, K1, 6, 9 ); + R( d, e, a, b, c, F1, K1, 15, 7 ); + R( c, d, e, a, b, F1, K1, 3, 15 ); + R( b, c, d, e, a, F1, K1, 12, 7 ); + R( a, b, c, d, e, F1, K1, 0, 12 ); + R( e, a, b, c, d, F1, K1, 9, 15 ); + R( d, e, a, b, c, F1, K1, 5, 9 ); + R( c, d, e, a, b, F1, K1, 2, 11 ); + R( b, c, d, e, a, F1, K1, 14, 7 ); + R( a, b, c, d, e, F1, K1, 11, 13 ); + R( e, a, b, c, d, F1, K1, 8, 12 ); + R( d, e, a, b, c, F2, K2, 3, 11 ); + R( c, d, e, a, b, F2, K2, 10, 13 ); + R( b, c, d, e, a, F2, K2, 14, 6 ); + R( a, b, c, d, e, F2, K2, 4, 7 ); + R( e, a, b, c, d, F2, K2, 9, 14 ); + R( d, e, a, b, c, F2, K2, 15, 9 ); + R( c, d, e, a, b, F2, K2, 8, 13 ); + R( b, c, d, e, a, F2, K2, 1, 15 ); + R( a, b, c, d, e, F2, K2, 2, 14 ); + R( e, a, b, c, d, F2, K2, 7, 8 ); + R( d, e, a, b, c, F2, K2, 0, 13 ); + R( c, d, e, a, b, F2, K2, 6, 6 ); + R( b, c, d, e, a, F2, K2, 13, 5 ); + R( a, b, c, d, e, F2, K2, 11, 12 ); + R( e, a, b, c, d, F2, K2, 5, 7 ); + R( d, e, a, b, c, F2, K2, 12, 5 ); + R( c, d, e, a, b, F3, K3, 1, 11 ); + R( b, c, d, e, a, F3, K3, 9, 12 ); + R( a, b, c, d, e, F3, K3, 11, 14 ); + R( e, a, b, c, d, F3, K3, 10, 15 ); + R( d, e, a, b, c, F3, K3, 0, 14 ); + R( c, d, e, a, b, F3, K3, 8, 15 ); + R( b, c, d, e, a, F3, K3, 12, 9 ); + R( a, b, c, d, e, F3, K3, 4, 8 ); + R( e, a, b, c, d, F3, K3, 13, 9 ); + R( d, e, a, b, c, F3, K3, 3, 14 ); + R( c, d, e, a, b, F3, K3, 7, 5 ); + R( b, c, d, e, a, F3, K3, 15, 6 ); + R( a, b, c, d, e, F3, K3, 14, 8 ); + R( e, a, b, c, d, F3, K3, 5, 6 ); + R( d, e, a, b, c, F3, K3, 6, 5 ); + R( c, d, e, a, b, F3, K3, 2, 12 ); + R( b, c, d, e, a, F4, K4, 4, 9 ); + R( a, b, c, d, e, F4, K4, 0, 15 ); + R( e, a, b, c, d, F4, K4, 5, 5 ); + R( d, e, a, b, c, F4, K4, 9, 11 ); + R( c, d, e, a, b, F4, K4, 7, 6 ); + R( b, c, d, e, a, F4, K4, 12, 8 ); + R( a, b, c, d, e, F4, K4, 2, 13 ); + R( e, a, b, c, d, F4, K4, 10, 12 ); + R( d, e, a, b, c, F4, K4, 14, 5 ); + R( c, d, e, a, b, F4, K4, 1, 12 ); + R( b, c, d, e, a, F4, K4, 3, 13 ); + R( a, b, c, d, e, F4, K4, 8, 14 ); + R( e, a, b, c, d, F4, K4, 11, 11 ); + R( d, e, a, b, c, F4, K4, 6, 8 ); + R( c, d, e, a, b, F4, K4, 15, 5 ); + R( b, c, d, e, a, F4, K4, 13, 6 ); + + aa = a; bb = b; cc = c; dd = d; ee = e; + + /* right lane */ + a = hd->h0; + b = hd->h1; + c = hd->h2; + d = hd->h3; + e = hd->h4; + R( a, b, c, d, e, F4, KK0, 5, 8); + R( e, a, b, c, d, F4, KK0, 14, 9); + R( d, e, a, b, c, F4, KK0, 7, 9); + R( c, d, e, a, b, F4, KK0, 0, 11); + R( b, c, d, e, a, F4, KK0, 9, 13); + R( a, b, c, d, e, F4, KK0, 2, 15); + R( e, a, b, c, d, F4, KK0, 11, 15); + R( d, e, a, b, c, F4, KK0, 4, 5); + R( c, d, e, a, b, F4, KK0, 13, 7); + R( b, c, d, e, a, F4, KK0, 6, 7); + R( a, b, c, d, e, F4, KK0, 15, 8); + R( e, a, b, c, d, F4, KK0, 8, 11); + R( d, e, a, b, c, F4, KK0, 1, 14); + R( c, d, e, a, b, F4, KK0, 10, 14); + R( b, c, d, e, a, F4, KK0, 3, 12); + R( a, b, c, d, e, F4, KK0, 12, 6); + R( e, a, b, c, d, F3, KK1, 6, 9); + R( d, e, a, b, c, F3, KK1, 11, 13); + R( c, d, e, a, b, F3, KK1, 3, 15); + R( b, c, d, e, a, F3, KK1, 7, 7); + R( a, b, c, d, e, F3, KK1, 0, 12); + R( e, a, b, c, d, F3, KK1, 13, 8); + R( d, e, a, b, c, F3, KK1, 5, 9); + R( c, d, e, a, b, F3, KK1, 10, 11); + R( b, c, d, e, a, F3, KK1, 14, 7); + R( a, b, c, d, e, F3, KK1, 15, 7); + R( e, a, b, c, d, F3, KK1, 8, 12); + R( d, e, a, b, c, F3, KK1, 12, 7); + R( c, d, e, a, b, F3, KK1, 4, 6); + R( b, c, d, e, a, F3, KK1, 9, 15); + R( a, b, c, d, e, F3, KK1, 1, 13); + R( e, a, b, c, d, F3, KK1, 2, 11); + R( d, e, a, b, c, F2, KK2, 15, 9); + R( c, d, e, a, b, F2, KK2, 5, 7); + R( b, c, d, e, a, F2, KK2, 1, 15); + R( a, b, c, d, e, F2, KK2, 3, 11); + R( e, a, b, c, d, F2, KK2, 7, 8); + R( d, e, a, b, c, F2, KK2, 14, 6); + R( c, d, e, a, b, F2, KK2, 6, 6); + R( b, c, d, e, a, F2, KK2, 9, 14); + R( a, b, c, d, e, F2, KK2, 11, 12); + R( e, a, b, c, d, F2, KK2, 8, 13); + R( d, e, a, b, c, F2, KK2, 12, 5); + R( c, d, e, a, b, F2, KK2, 2, 14); + R( b, c, d, e, a, F2, KK2, 10, 13); + R( a, b, c, d, e, F2, KK2, 0, 13); + R( e, a, b, c, d, F2, KK2, 4, 7); + R( d, e, a, b, c, F2, KK2, 13, 5); + R( c, d, e, a, b, F1, KK3, 8, 15); + R( b, c, d, e, a, F1, KK3, 6, 5); + R( a, b, c, d, e, F1, KK3, 4, 8); + R( e, a, b, c, d, F1, KK3, 1, 11); + R( d, e, a, b, c, F1, KK3, 3, 14); + R( c, d, e, a, b, F1, KK3, 11, 14); + R( b, c, d, e, a, F1, KK3, 15, 6); + R( a, b, c, d, e, F1, KK3, 0, 14); + R( e, a, b, c, d, F1, KK3, 5, 6); + R( d, e, a, b, c, F1, KK3, 12, 9); + R( c, d, e, a, b, F1, KK3, 2, 12); + R( b, c, d, e, a, F1, KK3, 13, 9); + R( a, b, c, d, e, F1, KK3, 9, 12); + R( e, a, b, c, d, F1, KK3, 7, 5); + R( d, e, a, b, c, F1, KK3, 10, 15); + R( c, d, e, a, b, F1, KK3, 14, 8); + R( b, c, d, e, a, F0, KK4, 12, 8); + R( a, b, c, d, e, F0, KK4, 15, 5); + R( e, a, b, c, d, F0, KK4, 10, 12); + R( d, e, a, b, c, F0, KK4, 4, 9); + R( c, d, e, a, b, F0, KK4, 1, 12); + R( b, c, d, e, a, F0, KK4, 5, 5); + R( a, b, c, d, e, F0, KK4, 8, 14); + R( e, a, b, c, d, F0, KK4, 7, 6); + R( d, e, a, b, c, F0, KK4, 6, 8); + R( c, d, e, a, b, F0, KK4, 2, 13); + R( b, c, d, e, a, F0, KK4, 13, 6); + R( a, b, c, d, e, F0, KK4, 14, 5); + R( e, a, b, c, d, F0, KK4, 0, 15); + R( d, e, a, b, c, F0, KK4, 3, 13); + R( c, d, e, a, b, F0, KK4, 9, 11); + R( b, c, d, e, a, F0, KK4, 11, 11); + + + t = hd->h1 + d + cc; + hd->h1 = hd->h2 + e + dd; + hd->h2 = hd->h3 + a + ee; + hd->h3 = hd->h4 + b + aa; + hd->h4 = hd->h0 + c + bb; + hd->h0 = t; +} + + +/* Update the message digest with the contents + * of INBUF with length INLEN. + */ +static void +rmd160_write( RMD160_CONTEXT *hd, byte *inbuf, size_t inlen) +{ + if( hd->count == 64 ) { /* flush the buffer */ + transform( hd, hd->buf ); + hd->count = 0; + hd->nblocks++; + } + if( !inbuf ) + return; + if( hd->count ) { + for( ; inlen && hd->count < 64; inlen-- ) + hd->buf[hd->count++] = *inbuf++; + rmd160_write( hd, NULL, 0 ); + if( !inlen ) + return; + } + + while( inlen >= 64 ) { + transform( hd, inbuf ); + hd->count = 0; + hd->nblocks++; + inlen -= 64; + inbuf += 64; + } + for( ; inlen && hd->count < 64; inlen-- ) + hd->buf[hd->count++] = *inbuf++; +} + +/* The routine terminates the computation + */ + +static void +rmd160_final( RMD160_CONTEXT *hd ) +{ + u32 t, msb, lsb; + byte *p; + + rmd160_write(hd, NULL, 0); /* flush */; + + msb = 0; + t = hd->nblocks; + if( (lsb = t << 6) < t ) /* multiply by 64 to make a byte count */ + msb++; + msb += t >> 26; + t = lsb; + if( (lsb = t + hd->count) < t ) /* add the count */ + msb++; + t = lsb; + if( (lsb = t << 3) < t ) /* multiply by 8 to make a bit count */ + msb++; + msb += t >> 29; + + if( hd->count < 56 ) { /* enough room */ + hd->buf[hd->count++] = 0x80; /* pad */ + while( hd->count < 56 ) + hd->buf[hd->count++] = 0; /* pad */ + } + else { /* need one extra block */ + hd->buf[hd->count++] = 0x80; /* pad character */ + while( hd->count < 64 ) + hd->buf[hd->count++] = 0; + rmd160_write(hd, NULL, 0); /* flush */; + memset(hd->buf, 0, 56 ); /* fill next block with zeroes */ + } + /* append the 64 bit count */ + hd->buf[56] = lsb ; + hd->buf[57] = lsb >> 8; + hd->buf[58] = lsb >> 16; + hd->buf[59] = lsb >> 24; + hd->buf[60] = msb ; + hd->buf[61] = msb >> 8; + hd->buf[62] = msb >> 16; + hd->buf[63] = msb >> 24; + transform( hd, hd->buf ); + + p = hd->buf; + #if BYTE_ORDER == BIG_ENDIAN + #define X(a) do { *p++ = hd->h##a ; *p++ = hd->h##a >> 8; \ + *p++ = hd->h##a >> 16; *p++ = hd->h##a >> 24; } while(0) + #else /* little endian */ + #define X(a) do { *(u32*)p = hd->h##a ; p += 4; } while(0) + #endif + X(0); + X(1); + X(2); + X(3); + X(4); + #undef X +} + +/**************** + * Shortcut functions which puts the hash value of the supplied buffer + * into outbuf which must have a size of 20 bytes. + */ +void +rmd160_hash_buffer( char *outbuf, const char *buffer, size_t length ) +{ + RMD160_CONTEXT hd; + + rmd160_init( &hd ); + rmd160_write( &hd, (byte*)buffer, length ); + rmd160_final( &hd ); + memcpy( outbuf, hd.buf, 20 ); +} --- ./mount/rmd160.h.OLD Tue Nov 28 22:03:17 2000 +++ ./mount/rmd160.h Thu Nov 9 22:47:04 2000 @@ -0,0 +1,9 @@ +#ifndef RMD160_H +#define RMD160_H + +void +rmd160_hash_buffer( char *outbuf, const char *buffer, size_t length ); + +#endif /*RMD160_H*/ + + --rwEMma7ioTxnRzrJ-- 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 Nov 29 12:44:51 2000 Received: by humbolt.nl.linux.org id ; Wed, 29 Nov 2000 12:44:08 +0100 Received: from midten.fast.no ([213.188.8.11]:47885 "EHLO midten.fast.no") by humbolt.nl.linux.org with ESMTP id ; Wed, 29 Nov 2000 12:43:40 +0100 Received: (from astor@localhost) by midten.fast.no (8.9.3/8.9.3) id MAA41607; Wed, 29 Nov 2000 12:43:34 +0100 (CET) Date: Wed, 29 Nov 2000 12:43:33 +0100 From: Alexander S A Kjeldaas To: John Kennedy Cc: linux-crypto@nl.linux.org Subject: Re: Intl. patch 2.2.17.11pre1 Message-ID: <20001129124332.B40777@midten.fast.no> References: <20001128154758.A94834@midten.fast.no> <20001128102554.B3632@north.csuchico.edu> <20001128193350.A10769@midten.fast.no> <20001128193924.B10865@north.csuchico.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <20001128193924.B10865@north.csuchico.edu>; from John Kennedy on Tue, Nov 28, 2000 at 07:39:24PM -0800 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Tue, Nov 28, 2000 at 07:39:24PM -0800, John Kennedy wrote: > On Tue, Nov 28, 2000 at 07:33:51PM +0100, Alexander S A Kjeldaas wrote: > > Forgot to mention this.. it's not in the kernel/crypto directory, but > > rather in: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/astor/v2.2/ > > I think Alan has been backporting some code. I've needed this with > everything I've tried against 2.2.18pre* so far. Ok. 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 Nov 29 15:23:27 2000 Received: by humbolt.nl.linux.org id ; Wed, 29 Nov 2000 15:22:36 +0100 Received: from north.net.CSUChico.EDU ([132.241.66.18]:19210 "EHLO north.net.csuchico.edu") by humbolt.nl.linux.org with ESMTP id ; Wed, 29 Nov 2000 15:22:05 +0100 Received: (from warlock@localhost) by north.net.csuchico.edu (8.11.0.Beta1/8.11.0.Beta0) id eATEM1Y18567; Wed, 29 Nov 2000 06:22:01 -0800 Date: Wed, 29 Nov 2000 06:22:01 -0800 From: John Kennedy To: Marc Mutz Cc: linux-crypto@nl.linux.org Subject: Re: block ciphers & plaintext attacks Message-ID: <20001129062201.A17537@north.csuchico.edu> References: <20001125085101.A16657@north.csuchico.edu> <3A2132F9.6C0ECCA0@Mutz.com> <20001126114450.A1454@north.csuchico.edu> <3A2216C3.519BFB6@Mutz.com> <20001127112915.C17826@north.csuchico.edu> <3A23F496.66BEFFB5@Mutz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3A23F496.66BEFFB5@Mutz.com>; from Marc@Mutz.com on Tue, Nov 28, 2000 at 06:08:22PM +0000 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list On Tue, Nov 28, 2000 at 06:08:22PM +0000, Marc Mutz wrote: > John Kennedy wrote: > > > As far as passphrase entropy, I'm a bit ignorant at the moment. I > > initially coded to be compatible with losetup, presuming that it would > > be coded in a secure fashion. Without a lot more reading, I can't say > > if that is true or not though. > > > > I'm under the impression that the 1.3 bits/char problem is pretty common > > and that one of the first things you do is run it through a one-way hash, > > generating something that looks far more like random bits. I see the > > two calls to rmd160_hash_buffer(), but I haven't confirmed that what > > they're actually doing is something like what I've been told. > > > > losetup takes the passphrase-string, calculates the ripe-md hash > function of that string and uses the resulting bitstring as the key to > the cipher (serpent, in your case). > > > > Enough to spend my time productively on the passphrase, yes. (: Either > > the current losetup code will be secure or not and, if not, I'll just > > add another layer with a passphrase protecting an encrypted passphrase > > to the real data on the disk. > > The losetup code is as secure as it can get. Ok, I'm not wasting anybody's time up through here. (: > > (Yes, you could still try to brute-force the first passphrase, but it > > and the encrypted 2nd passphrase can easily be kept apart from the > > hard-drive encrypted with the 2nd passphrase. If rmd160_hash_buffer() > > doesn't introduce enough entropy, that ought to help a lot.) > > Hashing _never_ (!!!) introduces entropy. It might even _decrease_ your > entropy by a few bits. Entropy can be rougly defined as the number of > bits you need to store a certain data set. E.g. a random 32 bit value > has 32 bits of entropy, because you can store 2^32 states with it. Yet a > 4-character string containing only the 26 letters can have at most > lb(26^4)=18.75 bits of entropy (where lb is logarithm w.r.t. base 2), > since you can only encode 26^4 ~= 2^18.75 states with this. The famous > 1.3 bits/char are valid for english running text. Here I'm just using the wrong keyword and wasting your time, making you excitable and giving you the wrong impression. I thought, for whatever reason, we were comparing the non-merits of plain ascii text as the key to the cipher serpent rather than the result of the ripe-md hash and talking about the non-merits of [A-Za-z0-9]*4 vs. a 32-bit number generated by the hash as the key contents. Of course, being ignorant got the following gem out of you: > So, if you want to have a passphrase that is as secure as the cipher is > (i.e attacking the passphrase is not much faster than attacking the key > directly), you have to enter approx. 100 characters of english text. > This will give you a passphrase of ca. 130 bits entropy which in turn is > fed into the hash function to produce a bit string with around 128 bits > of entropy (hashes lose entropy because they are not bijective from > GF(2^128) onto itself). Yet that string is 160 bits long and only the > frst 128 bits of it are taken as the passphrase. Thus, your key's > entropy can be approximated to be 128*(128/160)=102 bits. But that is > good enough. So, to try and convert that to a horrible generalization, if I use the letter `A' as my passphrase, my true entropy is somewhere between 1.3 and 8 bits (depending on if you know I'm using english text or not). Yes, it may be hashed out and effectively padded to 128 bits, but it looks far more random than it actually is. I'm not going to touch the math without cracking the AC book some more. No, my longest passphrase is ~50 characters, which gives me about half the entropy I could have if I'm lucky. In addition, my blabbing about using two keys really doesn't make things more secure from a mathematical point since we're talking about the weakest link. Break the first key (using it to decrypt the 2nd) and it doesn't really matter how much entropy the 2nd key may really have, you have it handed to you on a platter. As far as a real (but not mathematical) brute-force attempt goes, it may do some good. If all they have is the data encrypted by the 2nd key, it (the 2nd key) has more entropy in the cipher key (and presumably passes on the benefits of that in a mathematically tangible way). They have to have possession of the 2nd key encrypted with the 1st key to exploit the lack of entropy in the 1st key. The 2nd key (encrypted) is more mobile than the data encrypted by the 2nd key, which means that it is physically much more difficult to get (something that can't be factored into the mathematical attacks, but may be irrelevant from their point of view anyway). Oh hell, I'll just shut up now. Trying not to trip over the differences between a mathematical/academic attack vs. real brute-force decryption is just going to get me in trouble anyway. (: > You see, there's a _lot_ more to security than ciphers. You should > really read (and understand) Applied Cryptography, if you take your > thing serious. I went out and bought it last night. (: 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 Nov 29 20:10:59 2000 Received: by humbolt.nl.linux.org id ; Wed, 29 Nov 2000 20:10:26 +0100 Received: from north.net.CSUChico.EDU ([132.241.66.18]:22283 "EHLO north.net.csuchico.edu") by humbolt.nl.linux.org with ESMTP id ; Wed, 29 Nov 2000 20:09:52 +0100 Received: (from warlock@localhost) by north.net.csuchico.edu (8.11.0.Beta1/8.11.0.Beta0) id eATJ9U722284; Wed, 29 Nov 2000 11:09:30 -0800 Date: Wed, 29 Nov 2000 11:09:30 -0800 From: John Kennedy To: Marc Mutz Cc: linux-crypto@nl.linux.org Subject: Re: block ciphers & plaintext attacks Message-ID: <20001129110930.A21155@north.csuchico.edu> References: <20001125085101.A16657@north.csuchico.edu> <3A2132F9.6C0ECCA0@Mutz.com> <20001126114450.A1454@north.csuchico.edu> <3A2216C3.519BFB6@Mutz.com> <20001127112915.C17826@north.csuchico.edu> <3A23F496.66BEFFB5@Mutz.com> <20001129062201.A17537@north.csuchico.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20001129062201.A17537@north.csuchico.edu>; from jk@csuchico.edu on Wed, Nov 29, 2000 at 06:22:01AM -0800 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list I should just shut up but this is bugging me and I haven't done the math yet. Hopefully this will be a good question. On Wed, Nov 29, 2000 at 06:22:01AM -0800, John Kennedy wrote: > As far as a real (but not mathematical) brute-force attempt goes, > it may do some good. If all they have is the data encrypted by the 2nd > key, it (the 2nd key) has more entropy in the cipher key (and presumably > passes on the benefits of that in a mathematically tangible way). > They have to have possession of the 2nd key encrypted with the 1st key > to exploit the lack of entropy in the 1st key. The 2nd key (encrypted) > is more mobile than the data encrypted by the 2nd key, which means that > it is physically much more difficult to get (something that can't be > factored into the mathematical attacks, but may be irrelevant from their > point of view anyway). Right now, we're operating under the assumption that the serpent cipher is secure and that I could encrypt gigabytes of zeros securely and it wouldn't do any good to a brute-force attacker, at least directly. The easiest way in is still through attacking the key. The key is just a bitstream, X bits long. I could try all 2^X possible values to try and brute-force it, knowing I got it right when I see the gigabyte of zeros. That should be made computationally infeasible for a reasonable period of time, so the trick is to really cut back and find the smallest possible subset of 2^X to try. [tradeoff between security and the time it takes to decrypt the data. typically you want it to decrypt as fast as possible and still keep it as painful as possible for the brute-forcers, trusting that the cpu-expensive key generation will stop people from generating and trying to use a lot of keys very quickly.] The hash that makes the key is there to make that difficult. It takes a small amount of human-friendly bits and converts it into a much longer bitstream with a wide output-value range. It won't be any more random, but it hopefully guarantees you that brute-forcers can't eliminate any of the 2^X possibilities for the cipher key. The brute-forcers then have to attack the key itself. It is a one-way hash and should be computationally expensive to generate, which cuts down on the number of attempts you can make in a time interval. Once again, you're trying to figure out ways to cut down on the possible input. [this can be very painful to generate, since it is a one-time cost if you know the correct password and it is good to make it as painful as you can if you don't.] Here is where the entropy comes into play and where I start to tie knots with my brain, tongue and fingers. You want N bits of entropy (good, random numbers). If those N bits are from a keyboard, you only get ~1.3 bits per key (byte). If they're a nice secure number from /dev/random (presuming it has good entropy) you should be able to get all 8 bits/byte. The only trick is that you have to remember those bits or you won't be able to decrypt your data. Is the cipher-encrypted data any more secure with less entropy than with more entropy? I think the bit that I have to bend my brain around is that the answer is *NO*. Less entropy just means that the attacker has to try fewer hashes, and in the end fewer cipher keys. As an example, if I got *really* unlucky and my high-entropy bitstream happened to be all zeros, the data isn't encrypted any more securely than if I had a really bad hash generator that only let me pick a single digit between 0 and 9 as the bitstream. It makes a great deal of difference to an attacker that is thinking about trying to brute-force me. 2^X vs. 10. It seems like it really doesn't matter what I use as the hash input, so long as it has sufficient entropy to provide a good range of output. In my original email, above, I'm protecting a key (key2, with a good range of input) with encryption, that is decoded by another key (key1, with a smaller range of input). If I knew I had decrypted key2 correctly with key1 then I would have a weakest-link situation. If I don't know, then an incorrect key2 complicates the hell out of finding the correct cipher key. It may not magnify it, but I doubt if it helps to eliminates anything. It may not contribute a whole lot to the security, but if key2 is disposed of the pulling-fingernails approach won't work for decryption. (: 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 Nov 29 23:41:54 2000 Received: by humbolt.nl.linux.org id ; Wed, 29 Nov 2000 23:40:29 +0100 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:9561 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Wed, 29 Nov 2000 23:39:54 +0100 Received: from Mutz.com (ppp36-295.hrz.uni-bielefeld.de [129.70.37.39]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G4T00IDP5MCH0@mail.uni-bielefeld.de> for linux-crypto@humbolt.nl.linux.org; Wed, 29 Nov 2000 23:39:51 +0100 (MET) Date: Wed, 29 Nov 2000 22:21:04 +0000 From: Marc Mutz Subject: Re: block ciphers & plaintext attacks To: John Kennedy Cc: linux-crypto@nl.linux.org Message-id: <3A258150.2CD9CDA0@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17i10-0001 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <20001125085101.A16657@north.csuchico.edu> <3A2132F9.6C0ECCA0@Mutz.com> <20001126114450.A1454@north.csuchico.edu> <3A2216C3.519BFB6@Mutz.com> <20001127112915.C17826@north.csuchico.edu> <3A23F496.66BEFFB5@Mutz.com> <20001129062201.A17537@north.csuchico.edu> <20001129110930.A21155@north.csuchico.edu> Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list John Kennedy wrote: > > Right now, we're operating under the assumption that the serpent cipher > is secure and that I could encrypt gigabytes of zeros securely and it > wouldn't do any good to a brute-force attacker, at least directly. > The easiest way in is still through attacking the key. > Yes. Provided you don't use ECB encryption. Sorry yet another term for you... But this one is easy: ECB (Electronic CodeBook) is just the simplest form of encryption using block ciphers: Let P[0],...,P[n] be the plaintext blocks (each of size equal blocksize of the cipher). Then the resulting ciphertext C[0],...,C[n] will be C[i] = Serpent(K,P[i]) for i = 1,...,n (K = key). Ie. you encrpyt each block individually. Thus, if you encrpyt an all-zreros plaintext, all P[i] will be equal (zero) and hence all C[i] will be equal. Not good. Therefore, the linux loop_gen driver uses CBC encryption (Cipher Block Chaining): With the notation above, the ciphertext will be calculated as follows: C[0] = Serpent( K, IV+P[0] ), C[i] = Serpent( K, C[i-1]+P[i] ), where '+' is XOR and IV is an Initialization Vector that can be choosen randomly. Strictly speaking, the ciphertext now becomes (IV,C[0],...,C[n]), because you must remember the IV to be able to decrypt. Thus, if you encrypt all zeros, the ciphertext blocks will still be different. > The key is just a bitstream, X bits long. I could try all 2^X possible > values to try and brute-force it, knowing I got it right when I see the > gigabyte of zeros. That should be made computationally infeasible for > a reasonable period of time, so the trick is to really cut back and find > the smallest possible subset of 2^X to try. > Exactly. > [tradeoff between security and the time it takes to decrypt > the data. typically you want it to decrypt as fast as possible > and still keep it as painful as possible for the brute-forcers, > trusting that the cpu-expensive key generation will stop people > from generating and trying to use a lot of keys very quickly.] > Not really. It helps if you have an expensive key-setup procedure. But that can be pipelined, so that the actual throughput will not be decreased (speaking of hardware decryption, of course). Usually, you obtain the desired security margin by making the possible number of keys so vast, that trying all of them in turn would require thousands of times the age of the universe if you had one million computers that can test one million keys per second each (the normal example of the order of complexity brute-force should have). > The hash that makes the key is there to make that difficult. No. It's there to make it convenient for the user. Instead of trying to remember key = 580687838abb0ae8ad77a8192