From owner-linux-crypto@nl.linux.org Sat Sep 1 16:32:04 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Sat, 1 Sep 2001 16:31:46 +0200 Received: from adsl-dynamic1-82.appleton.wi.ameritech.net ([64.108.120.82]:13316 "EHLO cybershamanix.com") by humbolt.nl.linux.org with ESMTP id ; Sat, 1 Sep 2001 16:31:42 +0200 Received: from ameritech.net (macdog [192.168.0.4]) by cybershamanix.com (8.11.0/8.11.0) with ESMTP id f81EVZb05590 for ; Sat, 1 Sep 2001 09:31:40 -0500 Message-ID: <3B90F288.65D79B58@ameritech.net> Date: Sat, 01 Sep 2001 09:36:59 -0500 From: Harmon Seaver Organization: Maddog Press X-Mailer: Mozilla 4.78 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "linux-crypto@nl.linux.org" Subject: 2.4.8 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list So now that I've installed the cryptoapi-2.4.7 on the 2.4.7 kernel, is it okay to apply the 2.4.8 (or later) kernel patches over that? -- Harmon Seaver, MLIS CyberShamanix Work 920-203-9633 hseaver@cybershamanix.com Home 920-233-5820 hseaver@ameritech.net http://www.cybershamanix.com/resume.html 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 Sep 1 17:08:09 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Sat, 1 Sep 2001 17:08:03 +0200 Received: from [194.46.8.33] ([194.46.8.33]:41476 "EHLO angusbay.vnl.com") by humbolt.nl.linux.org with ESMTP id ; Sat, 1 Sep 2001 17:07:52 +0200 Received: from amon by angusbay.vnl.com with local (Exim 3.22 #1) id 15dCMs-0001Zf-00 (Debian); Sat, 01 Sep 2001 16:07:30 +0100 Date: Sat, 1 Sep 2001 16:07:30 +0100 From: Dale Amon To: Harmon Seaver Cc: "linux-crypto@nl.linux.org" Subject: Re: 2.4.8 Message-ID: <20010901160730.D32593@vnl.com> References: <3B90F288.65D79B58@ameritech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B90F288.65D79B58@ameritech.net> User-Agent: Mutt/1.3.20i X-Operating-System: Linux, the choice of a GNU generation Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list On Sat, Sep 01, 2001 at 09:36:59AM -0500, Harmon Seaver wrote: > So now that I've installed the cryptoapi-2.4.7 on the 2.4.7 kernel, > is it okay to apply the 2.4.8 (or later) kernel patches over that? Hmmm. I think most people bring a kernel up to current before adding additional patches. I doubt anyone bothers to check funny orderings on the update. At the very least you will probably get a few hunks applied at some offset. Might work, but if it doesn't, go back and do the patching in order against a clean source tree. My personal preference is 1 standard kernel version update patches 2 crypto api 3 freeswan If there are other patches I want to use, I'll usually apply them between 1 and 2 if they're fairly general, or after 3 if they are fairly specific. -- ------------------------------------------------------ Use Linux: A computer Dale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste. Belfast, Northern Ireland ------------------------------------------------------ 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 Sep 1 20:59:29 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Sat, 1 Sep 2001 20:59:20 +0200 Received: from [62.98.72.237] ([62.98.72.237]:43392 "EHLO pcmax.inwind.it") by humbolt.nl.linux.org with ESMTP id ; Sat, 1 Sep 2001 20:59:08 +0200 Received: from inwind.it (localhost [127.0.0.1]) by pcmax.inwind.it (8.11.6/8.10.1) with ESMTP id f81J1S824340 for ; Sat, 1 Sep 2001 21:01:41 +0200 Message-ID: <3B913088.281441FF@inwind.it> Date: Sat, 01 Sep 2001 21:01:28 +0200 From: maxim65@inwind.it X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9 i586) X-Accept-Language: en MIME-Version: 1.0 To: "linux-crypto@nl.linux.org" Subject: 2.4.9 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list I have installed 2.4.7 cryptoapi on a virgin linux kernel 2.4.9 source without problem....it seem to be fine. Massimo P.S. with gcc 2.9.3 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 Sep 2 10:26:29 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Sun, 2 Sep 2001 10:26:22 +0200 Received: from pentafluge.infradead.org ([195.224.55.251]:24080 "EHLO pentafluge.infradead.org") by humbolt.nl.linux.org with ESMTP id ; Sun, 2 Sep 2001 10:26:07 +0200 Received: from [206.50.173.66] (helo=itrs_nt.ITRS_DOMAIN) by pentafluge.infradead.org with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 15dSU5-00057p-00 for ; Sun, 02 Sep 2001 09:20:01 +0100 Received: from w2kpro01 (ppp-206-170-209-200.lsan03.pacbell.net [206.170.209.200]) by itrs_nt.ITRS_DOMAIN with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id Q1QFVLKF; Sun, 2 Sep 2001 03:22:25 -0500 Reply-To: From: "IT3 Stuart B. Tener, USNR-R" To: , Subject: RE: 2.4.9 Date: Sun, 2 Sep 2001 01:24:10 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: base64 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B913088.281441FF@inwind.it> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list TWFzc2ltbzoNCg0KCUkgYW0gcnVubmluZyAyLjQuOSAobWFuZHJha2UgcmVsZWFzZSksIGRvIHlv dSB0aGluayB0aGUga2VybmVsIHBhdGNoIHdvdWxkIHdvcmsgd2l0aCB0aGF0Pw0KDQoNClZlcnkg UmVzcGVjdGZ1bGx5LCANCg0KU3R1YXJ0IEJsYWtlIFRlbmVyLCBJVDMsIFVTTlItUiwgTjNHV0cg DQpCZXZlcmx5IEhpbGxzLCBDYWxpZm9ybmlhDQpWVFUgMTkwNEcgKFZvbHVudGVlciBUcmFpbmlu ZyBVbml0KSANCnN0dWFydEBiaDkwMjEwLm5ldCANCndlc3QgY29hc3Q6ICgzMTApLTM1OC0wMjAy IFAuTy4gQm94IDE2MDQzLCBCZXZlcmx5IEhpbGxzLCBDQSA5MDIwOS0yMDQzIA0KZWFzdCBjb2Fz dDogKDIxNSktMzM4LTYwMDUgUC5PLiBCb3ggNDU4NTksIFBoaWxhZGVscGhpYSwgUEEgMTkxNDkt NTg1OSANCg0KVGVsZWNvcGllcjogKDQxOSktNzE1LTYwNzMgZmF4IHRvIGVtYWlsIGdhdGV3YXkg dmlhIHd3dy5lZmF4LmNvbSAoaXQncyBmcmVlISkgDQoNCkpPSU4gVEhFIFVTIE5BVlkgUkVTRVJW RSwgU0VSVkUgWU9VUiBDT1VOVFJZLCBBTkQgQkVORUZJVCBGUk9NIElUIEFMTC4gDQoNClN1bmRh eSwgU2VwdGVtYmVyIDAyLCAyMDAxIDE6MjMgQU0NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IG93bmVyLWxpbnV4LWNyeXB0b0BubC5saW51eC5vcmcgW21haWx0bzpvd25lci1s aW51eC1jcnlwdG9AbmwubGludXgub3JnXU9uIEJlaGFsZiBPZiBtYXhpbTY1QGlud2luZC5pdA0K U2VudDogU2F0dXJkYXksIFNlcHRlbWJlciAwMSwgMjAwMSAxMjowMSBQTQ0KVG86IGxpbnV4LWNy eXB0b0BubC5saW51eC5vcmcNClN1YmplY3Q6IDIuNC45DQoNCkkgaGF2ZSBpbnN0YWxsZWQgMi40 LjcgY3J5cHRvYXBpIG9uIGEgdmlyZ2luIGxpbnV4IGtlcm5lbCAyLjQuOSBzb3VyY2UNCndpdGhv dXQgcHJvYmxlbS4uLi5pdCBzZWVtIHRvIGJlIGZpbmUuDQoNCg0KTWFzc2ltbw0KDQpQLlMuIHdp dGggZ2NjIDIuOS4zDQoNCkxpbnV4LWNyeXB0bzogIGNyeXB0b2dyYXBoeSBpbiBhbmQgb24gdGhl IExpbnV4IHN5c3RlbQ0KQXJjaGl2ZTogICAgICAgaHR0cDovL21haWwubmwubGludXgub3JnL2xp bnV4LWNyeXB0by8NCg== 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 Sep 3 01:39:40 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Mon, 3 Sep 2001 01:39:31 +0200 Received: from mail.networkone.net ([209.144.112.246]:9743 "HELO mail.networkone.net") by humbolt.nl.linux.org with SMTP id ; Mon, 3 Sep 2001 01:39:14 +0200 Received: (qmail 14332 invoked from network); 2 Sep 2001 23:39:12 -0000 Received: from unknown (HELO there) (209.144.118.80) by mail.networkone.net with SMTP; 2 Sep 2001 23:39:12 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Joe To: linux-crypto@nl.linux.org Subject: Thank You For A Great Product! Date: Sun, 2 Sep 2001 16:39:11 -0700 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20010902233922Z16065-32383+3070@humbolt.nl.linux.org> Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list Dear Developers, I would like to firstoff thank you for such a great product, I myself have attempted to write a filesystem encryption layer for Linux, but yours seems way more advanced than I would ever be able to accomplish alone. I was wondering if there was a project guideline or project goals list? I am wishing to take part in active development of this project and hopefully to contribute some ideas. I looked over the sourceforge page and couldn't find anything of the sort, but if it does exist, I would greatly appreciate getting pointed to the right area. I have experience in gpgme and gcrypt programming and am very excited and anxious to help out this project as much as I can! Joe Diorio President - Tweaker Tech (tweakertech.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 Sep 3 14:42:16 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Mon, 3 Sep 2001 14:42:08 +0200 Received: from ntvlsi2.mi.infn.it ([193.205.79.93]:64128 "EHLO ntvlsi2.mi.infn.it") by humbolt.nl.linux.org with ESMTP id ; Mon, 3 Sep 2001 14:41:51 +0200 Received: from inwind.it (localhost [127.0.0.1]) by ntvlsi2.mi.infn.it (8.11.6/8.10.2) with ESMTP id f83Chf901246 for ; Mon, 3 Sep 2001 14:43:46 +0200 Message-ID: <3B937AFC.C6A61E4E@inwind.it> Date: Mon, 03 Sep 2001 14:43:40 +0200 From: maxim65@inwind.it X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-crypto@nl.linux.org Subject: files bigger than 2 Gb Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list Now I'm using cryptoapi with loops of 2Gb .I would like to make it bigger than 2Gb but when i try to create cryptofile bigger than that value I get error message " file too large " Is there same body than know if there is a way to do it? Thanks in advance Massimo 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 Sep 3 18:44:10 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Mon, 3 Sep 2001 18:44:05 +0200 Received: from hank-fep8-0.inet.fi ([194.251.242.203]:47557 "EHLO fep08.tmt.tele.fi") by humbolt.nl.linux.org with ESMTP id ; Mon, 3 Sep 2001 18:43:54 +0200 Received: from pp.inet.fi ([212.213.41.11]) by fep08.tmt.tele.fi (InterMail vM.5.01.03.00 201-253-122-118-20010201) with ESMTP id <20010903164529.LSDU25225.fep08.tmt.tele.fi@pp.inet.fi>; Mon, 3 Sep 2001 19:45:29 +0300 Message-ID: <3B93B32A.69D25916@pp.inet.fi> Date: Mon, 03 Sep 2001 19:43:22 +0300 From: Jari Ruusu X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19aa2 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-crypto@nl.linux.org CC: linux-kernel@vger.kernel.org Subject: Announce loop-AES-v1.4d file/swap crypto package Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list [linux-kernel also CC'd due to recent encrypted swap discussion] In short: If file and swap crypto is all you need, this package is a hassle free replacement for international crypto patch and HVR's crypto-api. This package provides loadable Linux kernel module (loop.o) that has AES cipher built-in. The AES cipher can be used to encrypt local file systems and disk partitions. For more information about compiling and using the driver, see the README file in the package. Features: - GPL license. - No source modifications to kernel. No patch hassles when you are upgrading your kernel. - Works with all recent 2.4, 2.2 and 2.0 kernels, including distro vendor kernels. Encrypted disk images are compatible across all supported kernels. - AES cipher is used in CBC mode. Supports 128, 192 and 256 bit keys. - Passwords hashed with SHA-256, SHA-384 or SHA-512. - 512 byte based IV. IV is immune to variations in transfer size and does not depend on file system block size. - Device backed (partition backed) loop is capable of encrypting swap on 2.4 kernels. Changes since previous release: - Little speed optimization in aes-glue.c - External encryption module locking bug is fixed (kernel 2.4 only). This bug did not affect loop-AES operation at all. This fix is from Ingo Rohloff. - On 2.4 kernels, device backed loop maintains private pre-allocated pool of RAM pages that are used when kernel is totally out of free RAM. This change also fixes stock loop.c sin of sleeping in make_request_fn(). Kernel 2.4 users who want to encrypt swap partitions should upgrade to this version. No need to upgrade if you use older 2.2 or 2.0 kernels. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES-v1.4d.tar.bz2 md5sum 404f82796bacc479deb266f13ec260b8 PGP signature file, my public key, and fingerprint here: http://loop-aes.sourceforge.net/loop-AES-v1.4d.tar.bz2.sign http://loop-aes.sourceforge.net/PGP-public-key.asc 1024/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD Regards, Jari Ruusu 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 Sep 4 02:44:16 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Tue, 4 Sep 2001 02:43:58 +0200 Received: from marc1.theaimsgroup.com ([63.238.77.171]:29960 "EHLO mailer.progressive-comp.com") by humbolt.nl.linux.org with ESMTP id ; Tue, 4 Sep 2001 02:43:49 +0200 Received: (from docs@localhost) by mailer.progressive-comp.com with id UAA08099; Mon, 3 Sep 2001 20:43:21 -0400 Date: Mon, 3 Sep 2001 20:43:21 -0400 Message-Id: <200109040043.UAA08099@mailer.progressive-comp.com> From: Hank Leininger Reply-To: Hank Leininger To: linux-crypto@nl.linux.org Subject: Re: Announce loop-AES-v1.4d file/swap crypto package X-Shameless-Plug: Check out http://marc.theaimsgroup.com/ X-Warning: This mail posted via a web gateway at marc.theaimsgroup.com X-Warning: Report any violation of list policy to abuse@progressive-comp.com X-Posted-By: Hank Leininger Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list On 2001-09-03, Jari Ruusu wrote: > - Device backed (partition backed) loop is capable of encrypting swap > on 2.4 kernels. [snip] > - On 2.4 kernels, device backed loop maintains private pre-allocated > pool of RAM pages that are used when kernel is totally out of free > RAM. This change also fixes stock loop.c sin of sleeping in > make_request_fn(). > Kernel 2.4 users who want to encrypt swap partitions should upgrade to > this version. No need to upgrade if you use older 2.2 or 2.0 kernels. Yay! Thank you! -- Hank Leininger /me pencils in some time to rebuild his laptop 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 Sep 4 10:13:17 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Tue, 4 Sep 2001 10:13:01 +0200 Received: from cm.med.3284844210.kabelnet.net ([195.202.190.178]:11278 "EHLO phobos.hvrlab.org") by humbolt.nl.linux.org with ESMTP id ; Tue, 4 Sep 2001 10:12:50 +0200 Received: from janus.txd.hvrlab.org (IDENT:hvr@janus.txd.hvrlab.org [10.51.1.5]) by phobos.hvrlab.org (8.9.3/8.9.3) with ESMTP id KAA21004; Tue, 4 Sep 2001 10:12:32 +0200 Date: Tue, 4 Sep 2001 10:12:31 +0200 (CEST) From: Herbert Valerio Riedel X-X-Sender: To: cc: Subject: Re: files bigger than 2 Gb In-Reply-To: <3B937AFC.C6A61E4E@inwind.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list are you using the latest util-linux (and patch)? see ftp://ftp.kernel.org/pub/linux/kernel/people/hvr/ please tell me whether it helps... (you'll also need a glibc not too old...) On Mon, 3 Sep 2001 maxim65@inwind.it wrote: > Now I'm using cryptoapi with loops of 2Gb .I would like to make it > bigger than 2Gb but when i try to create cryptofile bigger than that > value I get error message " file too large " > > Is there same body than know if there is a way to do it? > > Thanks in advance > > Massimo > > Linux-crypto: cryptography in and on the Linux system > Archive: http://mail.nl.linux.org/linux-crypto/ > -- Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hvr@hvrlab.org / Finger hvr@gnu.org for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 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 Sep 4 11:31:54 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Tue, 4 Sep 2001 11:31:37 +0200 Received: from cm.med.3284844210.kabelnet.net ([195.202.190.178]:17679 "EHLO phobos.hvrlab.org") by humbolt.nl.linux.org with ESMTP id ; Tue, 4 Sep 2001 11:31:22 +0200 Received: from janus.txd.hvrlab.org (IDENT:hvr@janus.txd.hvrlab.org [10.51.1.5]) by phobos.hvrlab.org (8.9.3/8.9.3) with ESMTP id LAA21624 for ; Tue, 4 Sep 2001 11:31:14 +0200 Date: Tue, 4 Sep 2001 11:31:13 +0200 (CEST) From: Herbert Valerio Riedel X-X-Sender: To: Subject: announce; monolithic versions of the cryptoapi branch! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list Since having kernel modules is not always a good idea, I've started to put together a handmade kernel patch... in ftp://ftp.kernel.org/pub/linux/kernel/people/hvr/ you'll find cryptoapi-2.4.10-pre4-xfs.diff.bz2/gz which is taken against the SGI/XFS enhanced 2.4.10-pre4 kernel version; and cryptoapi-2.4.8.diff.bz2/gz which has been diff'ed against a plain 2.4.8 (it should apply with minor problems against later kernel versions as well) I haven't done much testing yet with those patch versions of the cryptoapi branch, but I don't expect any major problems as the code itself is the same as the cryptoapi module versions; (either it works from the beginning, or maybe you'll get a kernel panic when booting or setting up the cryptodevice...); If you got scared by this statement, then just don't apply this patch :-) If you experience any problems, please report them so I can fix them... :-) ps: there's also a new util-linux-2.11i.patch in that directory, which includes some contributed fixes/improvements, regarding the keybits option passing for mount(8) regards, -- Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hvr@hvrlab.org / Finger hvr@gnu.org for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 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 Sep 4 17:05:28 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Tue, 4 Sep 2001 17:05:23 +0200 Received: from wins.ash.de ([212.84.209.11]:43270 "EHLO wins.ash.de") by humbolt.nl.linux.org with ESMTP id ; Tue, 4 Sep 2001 17:05:07 +0200 Received: (qmail 28425 invoked from network); 4 Sep 2001 15:04:27 -0000 Received: from backoffice.ash.de (2001:658:100::2e0:7dff:fe72:6bbc) by 2001:658::2:203:47ff:fe77:28ae with DES-CBC3-SHA encrypted SMTP cert backoffice@ash.de; 4 Sep 2001 15:04:27 -0000 Received: (qmail 22190 invoked by uid 500); 4 Sep 2001 15:04:31 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 4 Sep 2001 15:04:31 -0000 Date: Tue, 4 Sep 2001 17:04:27 +0200 (CEST) From: Hauke Johannknecht To: Subject: announce: TNG-Series patches In-Reply-To: Message-ID: X-NCC-RegID: de.trmd MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list -----BEGIN PGP SIGNED MESSAGE----- On Tue, 4 Sep 2001, Herbert Valerio Riedel wrote: > Since having kernel modules is not always a good idea, I've started to put > together a handmade kernel patch... oh, while we are at it... i have compiled an "uxac" patch for 2.4 that combines the (u)sagi-patches (currently containing the ipv6-enhancements, cryptoapi-code and the IABG ipsec6 code), (x)fs, loop(A)ES and (C)IPE. Patches as well as the "used raw patches" can be found at http://www.walledcity.de/linux/TNG/kernel/ people running qmail might also be interested in the "taw6" patch that combines TLS, SMTP-AUTH, wildmat and IPv6. the taw6 patch and other v6 patches for djb-tools can be found at http://www.walledcity.de/linux/TNG/djb/ in both cases the v6-part can be simply disabled, usual kernelconfig in the first, editing cc-conf and removing the -DINET6 in the second. if anyone is interested in a v6 tunnel to his static v4 address to play around with this wonderful protocol that makes ipsec mandatory, just send me a mail. comments, suggestions, diffs and references to TLS-Setups for other MUAs welcome. Gruss, Hauke - -- Hauke Johannknecht Berlin / Germany HJ422-RIPE Use PGP ! -> lynx -dump http://www.ash.de/ash.asc | pgp -kaf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iQEVAwUBO5Ttf3O2fBh4VhzZAQFVZwf/ZUWuZSASGlHWLKJZt6DTWGUtR4TzYiPF S8yX3LEjK+Z/qkX8SMvuAPiSHsIiSjiWZzQzjSFMWyd7KO4tXN5i1Hvy+7Gfg95M DHFOj3iLEyjkoeGATUtEXzXiuoZPEIL9KSiZwo0km9JFt67S+l+hToryxUEgKlgK DWOiR/N5+X20yKE6+CQwtCezXmPfFdbsaTJ1gyUVLJqTRkQU/JT7trJTCqBQN5O6 JS/0Z1KO6uoW1TnI9jMWN5eRNMM+O7dMmO80I/1zBTC35Wf3jDe02TwJuKgWjrk4 4QzbwAl7roKoTJOPlkoFJz/+xP1yBXrHa9ivdspEhq/Xbh0cGnuE6Q== =5Sxj -----END PGP SIGNATURE----- Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Wed Sep 5 11:18:03 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Wed, 5 Sep 2001 11:17:49 +0200 Received: from pentafluge.infradead.org ([195.224.55.251]:40200 "EHLO pentafluge.infradead.org") by humbolt.nl.linux.org with ESMTP id ; Wed, 5 Sep 2001 11:17:26 +0200 Received: from [206.50.173.66] (helo=itrs_nt.ITRS_DOMAIN) by pentafluge.infradead.org with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 15eYiQ-0002VI-00 for ; Wed, 05 Sep 2001 10:11:22 +0100 Received: from w2kpro01 (ppp-206-170-209-104.lsan03.pacbell.net [206.170.209.104]) by itrs_nt.ITRS_DOMAIN with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id Q1QFVMJS; Wed, 5 Sep 2001 04:13:52 -0500 Reply-To: From: "IT3 Stuart B. Tener, USNR-R" To: "Herbert Valerio Riedel" , Subject: RE: announce; monolithic versions of the cryptoapi branch! Date: Wed, 5 Sep 2001 02:15:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Disposition-Notification-To: "IT3 Stuart B. Tener, USNR-R" Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list TXIuIFJpZWRlbDoNCg0KCVBlcmhhcHMgd2UgY291bGQgaGF2ZSBhbiB1cGRhdGUgdG8gdGhlIGxp c3QgYXMgdG8gd2hhdCB0aGUgc3RhdHVzIG9mIGJ1Z3MgYW5kIGZlYXR1cmVzIGFyZSBpbiB0aGUg Y3VycmVudCByZWxlYXNlPyBJIHdvdWxkIGxvdmUgdG8gc2VlbSBzb21lIGRlZmluaXRpdmUgZG9j dW1lbnRhdGlvbiBhcyB0byB3aGF0IGlzIGluIHByb2dyZXNzLCB3aGF0IHRoZSBwYXRjaCBpcyBp bmNsdXNpdmUgb2YsIGV0Yy4NCg0KCUlzIHRoaXMgYSBwb3NzaWJpbGl0eT8NCg0KCVdpdGggYWxs IHRoZSBkaXNjdXNzaW9uIG9mIHBhdGNoZXMgYW5kIHdvcmtpbmcgdnMuIG5vdCB3b3JraW5nLCBt b25vbGl0aGljLCBldGMuLCBJIGFtIGxlYW5pbmcgbW9yZSBhbmQgbW9yZSB0b3dhcmRzIGp1c3Qg dXNpbmcgSmFyaSdzIGNvZGUuIEl0IGRvZXMgc2VlbSBhIGJpdCBlYXNpZXIgdG8gZGVhbCB3aXRo IGdpdmVuIHNvIG1hbnkgb2YgdGhlIGtlcm5lbCBpc3N1ZXMuDQoNCglJIHdvdWxkIGVuam95IHNl ZWluZyBhIHByb2plY3Qgc3RhdHVzIChpbiBmdWxsKSBwcmlvciB0byBtYWtpbmcgdGhhdCBkZWNp c2lvbi4NCg0KDQpWZXJ5IFJlc3BlY3RmdWxseSwgDQoNClN0dWFydCBCbGFrZSBUZW5lciwgSVQz LCBVU05SLVIsIE4zR1dHIA0KQmV2ZXJseSBIaWxscywgQ2FsaWZvcm5pYQ0KVlRVIDE5MDRHIChW b2x1bnRlZXIgVHJhaW5pbmcgVW5pdCkgDQpzdHVhcnRAYmg5MDIxMC5uZXQgDQp3ZXN0IGNvYXN0 OiAoMzEwKS0zNTgtMDIwMiBQLk8uIEJveCAxNjA0MywgQmV2ZXJseSBIaWxscywgQ0EgOTAyMDkt MjA0MyANCmVhc3QgY29hc3Q6ICgyMTUpLTMzOC02MDA1IFAuTy4gQm94IDQ1ODU5LCBQaGlsYWRl bHBoaWEsIFBBIDE5MTQ5LTU4NTkgDQoNClRlbGVjb3BpZXI6ICg0MTkpLTcxNS02MDczIGZheCB0 byBlbWFpbCBnYXRld2F5IHZpYSB3d3cuZWZheC5jb20gKGl0J3MgZnJlZSEpIA0KDQpKT0lOIFRI RSBVUyBOQVZZIFJFU0VSVkUsIFNFUlZFIFlPVVIgQ09VTlRSWSwgQU5EIEJFTkVGSVQgRlJPTSBJ VCBBTEwuIA0KDQpXZWRuZXNkYXksIFNlcHRlbWJlciAwNSwgMjAwMSAyOjExIEFNDQoNCiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogCW93bmVyLWxpbnV4LWNyeXB0b0BubC5saW51 eC5vcmcgW21haWx0bzpvd25lci1saW51eC1jcnlwdG9AbmwubGludXgub3JnXSAgT24gQmVoYWxm IE9mIEhlcmJlcnQgVmFsZXJpbyBSaWVkZWwNClNlbnQ6CVR1ZXNkYXksIFNlcHRlbWJlciAwNCwg MjAwMSAyOjMxIEFNDQpUbzoJbGludXgtY3J5cHRvQG5sLmxpbnV4Lm9yZw0KU3ViamVjdDoJYW5u b3VuY2U7IG1vbm9saXRoaWMgdmVyc2lvbnMgb2YgdGhlIGNyeXB0b2FwaSBicmFuY2ghDQoNCg0K U2luY2UgaGF2aW5nIGtlcm5lbCBtb2R1bGVzIGlzIG5vdCBhbHdheXMgYSBnb29kIGlkZWEsIEkn dmUgc3RhcnRlZCB0byBwdXQNCnRvZ2V0aGVyIGEgaGFuZG1hZGUga2VybmVsIHBhdGNoLi4uDQoN CmluIGZ0cDovL2Z0cC5rZXJuZWwub3JnL3B1Yi9saW51eC9rZXJuZWwvcGVvcGxlL2h2ci8geW91 J2xsIGZpbmQNCg0KIGNyeXB0b2FwaS0yLjQuMTAtcHJlNC14ZnMuZGlmZi5iejIvZ3oNCg0Kd2hp Y2ggaXMgdGFrZW4gYWdhaW5zdCB0aGUgU0dJL1hGUyBlbmhhbmNlZCAyLjQuMTAtcHJlNCBrZXJu ZWwgdmVyc2lvbjsNCmFuZA0KDQogY3J5cHRvYXBpLTIuNC44LmRpZmYuYnoyL2d6DQoNCndoaWNo IGhhcyBiZWVuIGRpZmYnZWQgYWdhaW5zdCBhIHBsYWluIDIuNC44IChpdCBzaG91bGQgYXBwbHkg d2l0aCBtaW5vcg0KcHJvYmxlbXMgYWdhaW5zdCBsYXRlciBrZXJuZWwgdmVyc2lvbnMgYXMgd2Vs bCkNCg0KSSBoYXZlbid0IGRvbmUgbXVjaCB0ZXN0aW5nIHlldCB3aXRoIHRob3NlIHBhdGNoIHZl cnNpb25zIG9mIHRoZSBjcnlwdG9hcGkNCmJyYW5jaCwgYnV0IEkgZG9uJ3QgZXhwZWN0IGFueSBt YWpvciBwcm9ibGVtcyBhcyB0aGUgY29kZSBpdHNlbGYgaXMgdGhlDQpzYW1lIGFzIHRoZSBjcnlw dG9hcGkgbW9kdWxlIHZlcnNpb25zOyAoZWl0aGVyIGl0IHdvcmtzIGZyb20gdGhlDQpiZWdpbm5p bmcsIG9yIG1heWJlIHlvdSdsbCBnZXQgYSBrZXJuZWwgcGFuaWMgd2hlbiBib290aW5nIG9yIHNl dHRpbmcgdXANCnRoZSBjcnlwdG9kZXZpY2UuLi4pOyBJZiB5b3UgZ290IHNjYXJlZCBieSB0aGlz IHN0YXRlbWVudCwgdGhlbiBqdXN0IGRvbid0DQphcHBseSB0aGlzIHBhdGNoIDotKQ0KDQpJZiB5 b3UgZXhwZXJpZW5jZSBhbnkgcHJvYmxlbXMsIHBsZWFzZSByZXBvcnQgdGhlbSBzbyBJIGNhbiBm aXggdGhlbS4uLiA6LSkNCg0KcHM6IHRoZXJlJ3MgYWxzbyBhIG5ldyB1dGlsLWxpbnV4LTIuMTFp LnBhdGNoIGluIHRoYXQgZGlyZWN0b3J5LCB3aGljaA0KaW5jbHVkZXMgc29tZSBjb250cmlidXRl ZCBmaXhlcy9pbXByb3ZlbWVudHMsIHJlZ2FyZGluZyB0aGUga2V5Yml0cw0Kb3B0aW9uIHBhc3Np bmcgZm9yIG1vdW50KDgpDQoNCnJlZ2FyZHMsDQotLSANCkhlcmJlcnQgVmFsZXJpbyBSaWVkZWwg ICAgICAgLyAgICBQaG9uZTogKEVVUk9QRSkgKzQzLTEtNTg4MDEtMTg4NDANCkVtYWlsOiBodnJA aHZybGFiLm9yZyAgICAgICAvICAgIEZpbmdlciBodnJAZ251Lm9yZyBmb3IgR251UEcgUHVibGlj IEtleQ0KR251UEcgS2V5IEZpbmdlcnByaW50OiA3QkI5IDJENkMgRDQ4NSBDRTY0IDQ3NDggIDVG NjUgNDk4MSBFMDY0IDg4M0YgNDE0Mg0KDQoNCkxpbnV4LWNyeXB0bzogIGNyeXB0b2dyYXBoeSBp biBhbmQgb24gdGhlIExpbnV4IHN5c3RlbQ0KQXJjaGl2ZTogICAgICAgaHR0cDovL21haWwubmwu bGludXgub3JnL2xpbnV4LWNyeXB0by8NCg== 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 Sep 6 05:11:54 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Thu, 6 Sep 2001 05:11:48 +0200 Received: from adsl-dynamic1-103.appleton.wi.ameritech.net ([64.108.120.103]:1540 "EHLO cybershamanix.com") by humbolt.nl.linux.org with ESMTP id ; Thu, 6 Sep 2001 05:11:37 +0200 Received: from ameritech.net (macdog [192.168.0.4]) by cybershamanix.com (8.11.0/8.11.0) with ESMTP id f863B9O02122 for ; Wed, 5 Sep 2001 22:11:35 -0500 Message-ID: <3B96E94E.3271C252@ameritech.net> Date: Wed, 05 Sep 2001 22:11:19 -0500 From: Harmon Seaver Organization: Maddog Press X-Mailer: Mozilla 4.78 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "linux-crypto@nl.linux.org" Subject: Re: announce; monolithic versions of the cryptoapi branch! References: Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list Okay, I took a virgin 2.4.9 source tree and applied the 2.4.10pre4 patch to it. Then I applied the cryptoapi-2.4.10-pre4-xfs.diff patch to that, and, after configuring (this time will all the crypto stuff in the kernel rather than modules, and "yes" to all of them except DES), and compiled, booted -- seems to work okay, except I find no mention of crypto in /var/log/messages from the boot like there was before. I also installed util-linux-2.11i. Anyway, so, since obviously we don't have to modprobe cryptoloop, I just try "losetup -e blowfish (or twofish, or aes, or whatever) /dev/loop0 /my file". For each of them, I get a "Unsupported encryption type blowfish " or whatever I try to use. Hmm. Doing a man losetup, I see it still only lists the same 3 crappy old dinosaurs, so, what the heck -- I try des, even tho I didn't even put that in as a module. That gets accepted, then it asks for my password and I give it one, then it says "Init (up to 16 hex digits):" and I'm not sure what to put in there. What is this? But obviously something is not working -- why is des accepted and nothing else? The FAQ says that I need a new losetup, but I've got the latest one. To be sure, I go to RedHat and download their latest losetup rpm which is 2.11b and install that -- same thing. -- Harmon Seaver, MLIS CyberShamanix Work 920-203-9633 hseaver@cybershamanix.com Home 920-233-5820 hseaver@ameritech.net http://www.cybershamanix.com/resume.html 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 Sep 6 08:46:19 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Thu, 6 Sep 2001 08:46:03 +0200 Received: from cm.med.3284844210.kabelnet.net ([195.202.190.178]:51976 "EHLO phobos.hvrlab.org") by humbolt.nl.linux.org with ESMTP id ; Thu, 6 Sep 2001 08:45:55 +0200 Received: from janus.txd.hvrlab.org (IDENT:hvr@janus.txd.hvrlab.org [10.51.1.5]) by phobos.hvrlab.org (8.9.3/8.9.3) with ESMTP id IAA07679; Thu, 6 Sep 2001 08:45:48 +0200 Date: Thu, 6 Sep 2001 08:45:47 +0200 (CEST) From: Herbert Valerio Riedel X-X-Sender: To: Harmon Seaver cc: "linux-crypto@nl.linux.org" Subject: Re: announce; monolithic versions of the cryptoapi branch! In-Reply-To: <3B96E94E.3271C252@ameritech.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list 1.) I hope you also fixed some minor rejects you may have gotten in the top-level Makefile (that's a nasty difference between the -XFS branch and the plain linux kernel) otherwise the crypto/crypto.o might not get linked into the kernel image, and then you won't see any message regarding crypto initialization in dmesg(8) for non-XFS kernels I provided the patch against 2.4.8 which may apply to 2.4.9 and later as well... guess I'll have to re-diff against some newer kernel in order to avoid confusion... ;-) 2.) you need to patch your util-linux-2.11i with the patch contained in the same directory, where you got the crypto patch from... maybe one should make ready to use rpms of the patched util-linux stuff... even if IMHO you shouldn't trust binaries you didn't compile yourself..... On Wed, 5 Sep 2001, Harmon Seaver wrote: > Okay, I took a virgin 2.4.9 source tree and applied the 2.4.10pre4 > patch to it. Then I applied the cryptoapi-2.4.10-pre4-xfs.diff patch to > that, and, after configuring (this time will all the crypto stuff in the > kernel rather than modules, and "yes" to all of them except DES), and > compiled, booted -- seems to work okay, except I find no mention of > crypto in /var/log/messages from the boot like there was before. I also > installed util-linux-2.11i. > Anyway, so, since obviously we don't have to modprobe cryptoloop, > I just try "losetup -e blowfish (or twofish, or aes, or whatever) > /dev/loop0 /my file". For each of them, I get a "Unsupported encryption > type blowfish " or whatever I try to use. Hmm. Doing a man losetup, I > see it still only lists the same 3 crappy old dinosaurs, so, what the > heck -- I try des, even tho I didn't even put that in as a module. That > gets accepted, then it asks for my password and I give it one, then it > says "Init (up to 16 hex digits):" and I'm not sure what to put in > there. What is this? > But obviously something is not working -- why is des accepted and > nothing else? The FAQ says that I need a new losetup, but I've got the > latest one. To be sure, I go to RedHat and download their latest losetup > rpm which is 2.11b and install that -- same thing. -- Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hvr@hvrlab.org / Finger hvr@gnu.org for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 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 Sep 6 09:11:18 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Thu, 6 Sep 2001 09:11:08 +0200 Received: from cm.med.3284844210.kabelnet.net ([195.202.190.178]:8457 "EHLO phobos.hvrlab.org") by humbolt.nl.linux.org with ESMTP id ; Thu, 6 Sep 2001 09:10:48 +0200 Received: from janus.txd.hvrlab.org (IDENT:hvr@janus.txd.hvrlab.org [10.51.1.5]) by phobos.hvrlab.org (8.9.3/8.9.3) with ESMTP id JAA07845 for ; Thu, 6 Sep 2001 09:10:44 +0200 Date: Thu, 6 Sep 2001 09:10:43 +0200 (CEST) From: Herbert Valerio Riedel X-X-Sender: To: Subject: Re: I-patch problem statement (update) In-Reply-To: <20010710131028.A12006@vnl.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list just to let you know, what the crypto patch code status is in at the moment; On Tue, 10 Jul 2001, Dale Amon wrote: > There are two known definite bugs, a backward compatibility > issue and at least two general complainst on the table. > > * BUG: block size problem > Has a current work around, Herbert has stated > he will soon have it fixed in code. fixed, if you enable the 512-byte IV option (btw, I've seen the latest recent kernels added the blocksize set/get ioctl's... just as a sidenote...) > * BUG: SMP issue > None of us has had to deal with it, but Herbert > has stated he will have it fixed in code soon. fixed > * 2.2 not readable on 2.4 > Question: is this really unknown or are the systems > in question ones that were set up with the old > absolute block number problem? If not, perhaps > it is an issue for study using a small test case. > Is there anyone here who is actually a > mathematician/cryptographer? a user space tool will allow to convert to the new IV/blocksize scheme... > * performance loss due to non-reentrancy > Presumably if Herbert fixes the SMP issue, he > sorts this as well. I might note that I play > my Mozart CD on this laptop while editing on a > loopback AES partition and have no problems. fixed as well; can someone confirm this? (the scheduling issue, was actually just a one-liner; a change from atomic to non-atomic en/de-crypting loop...) > * kernel bloat. This is probably a non-issue. Linus > will at some point go for hooks into the kernel > for encryption support. The API for that will perhaps > be influenced by kerneli but that will not be the > final word. I do suspect it will have great influence > because everyone is using the new util-linux which > supports the new api for loopback encryption types. > In that sense we are already main stream. > (The util-linux support is mainstream debian now) btw, I don't see any major kernel bloat; the actual implementation does dynamic allocation of cipher modules, and uses strings for identification; instead of having to use some magic number IDs... (see also the mknod problem and devfs; which can be regarded as kernel bloat as well... actually the whole kernel is bloat... why do we use at all a virtual machine abstraction layer instead of coding directly without any underlying OS?!? ;-) > I'm pretty sure I remember a kernel discussion on some of > the issues and there is a desire to have one single crypto > API that is available for all purposes, loopback fs or other. > While loopAES is very nice for now, and perhaps some of the code > will find its' way into the kernel, I don't see that as the > likely way things will go for 2.6.x. I'm very sure that a > loopback module will not contain its' own crypto. It will share > it with other tools and applications. We are not going to see > 5 loadable modules providing different services each with its' > own implimentation of AES. ...and that's what the cryptoapi patch tries to accomplish... the loopback module has been separated from the crypto transfer function... the CIPE project wants to make use of the cryptoapi as well; another subsystem; virtual memory encryption, can make use of the cryptoapi as well... we really need to unify all those crypto related kernel space projects; otherwise linus surely won't let them go into the kernel (at least I expect this, judging from the past ;-) regards, -- Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hvr@hvrlab.org / Finger hvr@gnu.org for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 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 Sep 6 11:08:22 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Thu, 6 Sep 2001 11:08:16 +0200 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:21158 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Thu, 6 Sep 2001 11:08:06 +0200 Received: from dirichlet.mathematik.uni-bielefeld.de (dirichlet.Mathematik.Uni-Bielefeld.DE [129.70.24.67]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.10.12.16.25.p8) with ESMTP id <0GJ80028LHDKM1@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Thu, 6 Sep 2001 11:08:08 +0200 (MET DST) Date: Thu, 06 Sep 2001 15:08:58 +0200 From: Marc Mutz Subject: Re: I-patch problem statement (update) In-reply-to: To: Herbert Valerio Riedel , linux-crypto@nl.linux.org Message-id: <0GJ80028MHDKM1@mail.uni-bielefeld.de> MIME-version: 1.0 X-Mailer: KMail [version 1.3.5] Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT X-KMail-Identity: Marc.Mutz@uni-bielefeld.de References: Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 06 September 2001 09:10, Herbert Valerio Riedel wrote: > ...and that's what the cryptoapi patch tries to accomplish... > the loopback module has been separated from the crypto transfer > function... > > the CIPE project wants to make use of the cryptoapi as well; > > another subsystem; virtual memory encryption, can make use of the > cryptoapi as well... > - - encrypted swap, which would be really nice, esp. since it requires no key management (you just grab a random number from the kernel's entropy pool on each swapon) - - make drivers/char/random.c use the kerneli digest routines. > we really need to unify all those crypto related kernel space > projects; otherwise linus surely won't let them go into the kernel > (at least I expect this, judging from the past ;-) ACK. Marc - -- The Commission and Member States are urged to devise appropriate measures to promote, develop and manufacture European encryption technology and software and above all to support projects aimed at developing user-friendly open-source encryption software. -- EuroParl. Temp. Committee on the ECHELON Interception System http://www.europarl.eu.int/tempcom/echelon/pdf/prechelon_en.pdf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7l3V03oWD+L2/6DgRAqI4AJ0XiW0Y4sTgteWyjkpwnNFyJQpoyACg/Ne4 jbmYXrQnX/Y0fGuNsT4tEQE= =IioW -----END PGP SIGNATURE----- iř!:őuA1:174:14:48:02 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 Sep 6 13:52:20 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Thu, 6 Sep 2001 13:52:03 +0200 Received: from hank-fep7-0.inet.fi ([194.251.242.202]:35485 "EHLO fep07.tmt.tele.fi") by humbolt.nl.linux.org with ESMTP id ; Thu, 6 Sep 2001 13:51:47 +0200 Received: from pp.inet.fi ([212.213.41.172]) by fep07.tmt.tele.fi (InterMail vM.5.01.03.00 201-253-122-118-20010201) with ESMTP id <20010906115141.KVBU1000.fep07.tmt.tele.fi@pp.inet.fi>; Thu, 6 Sep 2001 14:51:41 +0300 Message-ID: <3B976333.77E763C2@pp.inet.fi> Date: Thu, 06 Sep 2001 14:51:15 +0300 From: Jari Ruusu X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19aa2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Herbert Valerio Riedel CC: linux-crypto@nl.linux.org Subject: Re: I-patch problem statement (update) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list Herbert Valerio Riedel wrote: > just to let you know, what the crypto patch code status is in at the > moment; You forgot to mention the "sleeping in the make_request_fn()" bug, which is a real NO-NO, and can cause a panic(). > On Tue, 10 Jul 2001, Dale Amon wrote: > > * kernel bloat. This is probably a non-issue. Linus > > will at some point go for hooks into the kernel > > for encryption support. The API for that will perhaps > > be influenced by kerneli but that will not be the > > final word. I do suspect it will have great influence > > because everyone is using the new util-linux which > > supports the new api for loopback encryption types. > > In that sense we are already main stream. > > (The util-linux support is mainstream debian now) > btw, I don't see any major kernel bloat; > the actual implementation does dynamic allocation of cipher modules, > and uses strings for identification; instead of having to use some magic > number IDs... (see also the mknod problem and devfs; which can be regarded > as kernel bloat as well... actually the whole kernel is bloat... why do we > use at all a virtual machine abstraction layer instead of coding directly > without any underlying OS?!? ;-) Crypto-api is the bloat as it is just an unnecessary layer slowing things down. If someone is unable to do string to magic number conversion in userspace, it is no excuse to do that in kernel. > > I'm pretty sure I remember a kernel discussion on some of > > the issues and there is a desire to have one single crypto > > API that is available for all purposes, loopback fs or other. > > > While loopAES is very nice for now, and perhaps some of the code > > will find its' way into the kernel, I don't see that as the > > likely way things will go for 2.6.x. I'm very sure that a > > loopback module will not contain its' own crypto. It will share > > it with other tools and applications. We are not going to see > > 5 loadable modules providing different services each with its' > > own implimentation of AES. Loop-AES kernel patch version (kernel-2.4.diff) exports three fully re-entrant functions for everyone to use: void aes_set_key(aes_context *, const unsigned char [], const int, const int); void aes_encrypt(const aes_context *,const unsigned char [],unsigned char []); void aes_decrypt(const aes_context *,const unsigned char [],unsigned char []); > another subsystem; virtual memory encryption, can make use of the > cryptoapi as well... There is no need to modify VM. Device backed loop-AES-v1.4d can handle swapping just fine. > we really need to unify all those crypto related kernel space projects; > otherwise linus surely won't let them go into the kernel (at least I > expect this, judging from the past ;-) There are places where crypto can't go, but Linux must go. I don't like it, but I can understand keeping crypto out of mainline kernel. Regards, Jari Ruusu 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 Sep 6 13:52:26 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Thu, 6 Sep 2001 13:52:19 +0200 Received: from hank-fep7-0.inet.fi ([194.251.242.202]:39581 "EHLO fep07.tmt.tele.fi") by humbolt.nl.linux.org with ESMTP id ; Thu, 6 Sep 2001 13:52:00 +0200 Received: from pp.inet.fi ([212.213.41.172]) by fep07.tmt.tele.fi (InterMail vM.5.01.03.00 201-253-122-118-20010201) with ESMTP id <20010906115158.KVDI1000.fep07.tmt.tele.fi@pp.inet.fi>; Thu, 6 Sep 2001 14:51:58 +0300 Message-ID: <3B976347.D4052713@pp.inet.fi> Date: Thu, 06 Sep 2001 14:51:35 +0300 From: Jari Ruusu X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19aa2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Marc Mutz CC: Herbert Valerio Riedel , linux-crypto@nl.linux.org Subject: Re: I-patch problem statement (update) References: <0GJ80028MHDKM1@mail.uni-bielefeld.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list Marc Mutz wrote: > On Thursday 06 September 2001 09:10, Herbert Valerio Riedel wrote: > > another subsystem; virtual memory encryption, can make use of the > > cryptoapi as well... > > - - encrypted swap, which would be really nice, esp. since it requires no > key management (you just grab a random number from the kernel's entropy > pool on each swapon) HVR is still playing catch-up as loop-AES-v1.4d does encrypted swap already. Regards, Jari Ruusu 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 Sep 6 14:38:14 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Thu, 6 Sep 2001 14:38:09 +0200 Received: from snowdrop.csv.warwick.ac.uk ([137.205.192.31]:52363 "EHLO snowdrop.csv.warwick.ac.uk") by humbolt.nl.linux.org with ESMTP id ; Thu, 6 Sep 2001 14:37:56 +0200 Received: from mimosa.csv.warwick.ac.uk (phrxy@mimosa [137.205.192.34]) by snowdrop.csv.warwick.ac.uk (8.11.6/8.11.6) with ESMTP id f86Cbtc13334 for ; Thu, 6 Sep 2001 13:37:55 +0100 (BST) Received: from localhost (phrxy@localhost) by mimosa.csv.warwick.ac.uk (8.9.3/8.9.3) with ESMTP id NAA04186 for ; Thu, 6 Sep 2001 13:37:54 +0100 (BST) X-Authentication-Warning: mimosa.csv.warwick.ac.uk: phrxy owned process doing -bs Date: Thu, 6 Sep 2001 13:37:54 +0100 (BST) From: "John J. Lee" X-Sender: To: Subject: Why no mainline kernel crypto? (was: Re: I-patch problem statement (update)) In-Reply-To: <3B976333.77E763C2@pp.inet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list On Thu, 6 Sep 2001, Jari Ruusu wrote: [...] > There are places where crypto can't go, but Linux must go. I don't like it, > but I can understand keeping crypto out of mainline kernel. But logically, the only thing that is required is that the crypto and non-crypto branches are kept separate. It would fit this requirement just as well to have crypto in the mainline kernel, and a separate non-crypto kernel maintained, presumably with rather less effort than is currently required to maintain the crypto code separately. So why is the situation as it is? I don't know how kernel development works, perhaps somebody here who is more knowledgeable than me would like to comment. Of course, if things were to be organised in this way, somebody would have to maintain the non-crypto kernel, and I guess it might be harder to find people to do that than it currently is to find people (ie people on this group!) to maintain the separate crypto patch(es? -- I'm not up-to-date on how it works atm). I suppose there are two groups of candidate maintainers: people who want to get crypto into the mainline kernel who might promise to maintain a non-crypto patch (or un-patch, more like), and people who live in countries with restrictive crypto laws. Another argument that might be put forward is that the countries with restrictive laws on this aren't just dictatorships and communist countries but also major users of linux in the west like (still?) France. I think this argument is specious given the relative ease of removing crypto support compared to adding it. I guess my main point is that it is much easier to break something than to make it work, so maintaining a non-crypto branch would be far easier than maintaining a crypto patch. John 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 Sep 6 14:53:00 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Thu, 6 Sep 2001 14:52:49 +0200 Received: from hq.alert.sk ([147.175.66.131]:43530 "EHLO hq.alert.sk") by humbolt.nl.linux.org with ESMTP id ; Thu, 6 Sep 2001 14:52:26 +0200 Received: by hq.alert.sk (Postfix, from userid 608) id 90DE345EA0; Thu, 6 Sep 2001 14:51:39 +0200 (CEST) Date: Thu, 6 Sep 2001 14:51:39 +0200 From: Robert Varga To: Jari Ruusu Cc: linux-crypto@nl.linux.org Subject: Re: I-patch problem statement (update) Message-ID: <20010906145139.A26782@hq.alert.sk> References: <3B976333.77E763C2@pp.inet.fi> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B976333.77E763C2@pp.inet.fi>; from jari.ruusu@pp.inet.fi on Thu, Sep 06, 2001 at 02:51:15PM +0300 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 06, 2001 at 02:51:15PM +0300, Jari Ruusu wrote: > Herbert Valerio Riedel wrote: > > just to let you know, what the crypto patch code status is in at the > > moment; >=20 > You forgot to mention the "sleeping in the make_request_fn()" bug, which = is > a real NO-NO, and can cause a panic(). > =20 > > On Tue, 10 Jul 2001, Dale Amon wrote: > > > * kernel bloat. This is probably a non-issue. Linus > > > will at some point go for hooks into the kernel > > > for encryption support. The API for that will perhaps > > > be influenced by kerneli but that will not be the > > > final word. I do suspect it will have great influence > > > because everyone is using the new util-linux which > > > supports the new api for loopback encryption types. > > > In that sense we are already main stream. > > > (The util-linux support is mainstream debian now) > > btw, I don't see any major kernel bloat; > > the actual implementation does dynamic allocation of cipher modules, > > and uses strings for identification; instead of having to use some magic > > number IDs... (see also the mknod problem and devfs; which can be regar= ded > > as kernel bloat as well... actually the whole kernel is bloat... why do= we > > use at all a virtual machine abstraction layer instead of coding direct= ly > > without any underlying OS?!? ;-) >=20 > Crypto-api is the bloat as it is just an unnecessary layer slowing things > down. If someone is unable to do string to magic number conversion in > userspace, it is no excuse to do that in kernel. A couple questions: Is encrypted loopback the only place in kernel where encryption can be used? Is AES the only cipher worthy enough to be used ? Is it better to have aes_set_key, des_set_key, and probably quite a few oth= ers rather than: struct crypto_ctx *ctx =3D crypto_newctx("aes"); crypto_setkey(ctx, "blahblah"); crypto_encrypt(ctx, dest, src, len); ? Reason why I'm asking this is I'm working on per-file encryption support for ext2 and I would really hate to limit its users to single encryption algori= thm (and hashing for that matter). Do you think of VFS as "kernel bloat" ? --=20 Kind regards, Robert Varga ---------------------------------------------------------------------------= --- n@hq.sk http://hq.sk/~nite/gpgkey.= txt =20 --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7l3Fb9aKR2/T45h8RAkCYAJ0eCtHHkDL878B4GW/hWoB0VGECjACgqklq GN/2NEc7hJuVK3DHCE09asE= =2idl -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- 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 Sep 6 20:37:01 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Thu, 6 Sep 2001 20:36:45 +0200 Received: from hank-fep6-0.inet.fi ([194.251.242.201]:55973 "EHLO fep06.tmt.tele.fi") by humbolt.nl.linux.org with ESMTP id ; Thu, 6 Sep 2001 20:36:29 +0200 Received: from pp.inet.fi ([212.213.41.65]) by fep06.tmt.tele.fi (InterMail vM.5.01.03.00 201-253-122-118-20010201) with ESMTP id <20010906183627.KIQD10932.fep06.tmt.tele.fi@pp.inet.fi>; Thu, 6 Sep 2001 21:36:27 +0300 Message-ID: <3B97C212.CF3BEF8F@pp.inet.fi> Date: Thu, 06 Sep 2001 21:36:02 +0300 From: Jari Ruusu X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19aa2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Robert Varga CC: linux-crypto@nl.linux.org Subject: Re: I-patch problem statement (update) References: <3B976333.77E763C2@pp.inet.fi> <20010906145139.A26782@hq.alert.sk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list Robert Varga wrote: > A couple questions: > Is encrypted loopback the only place in kernel where encryption can be used? No. But loop driver has a good interface for different ciphers. Crypto-api for loop devices adds an extra unnecessary layer. Small and fast is beautiful. > Is AES the only cipher worthy enough to be used ? How many ciphers does one need? One good one will fill most peoples' needs. > Is it better to have aes_set_key, des_set_key, and probably quite a few others > rather than: > > struct crypto_ctx *ctx = crypto_newctx("aes"); > crypto_setkey(ctx, "blahblah"); > crypto_encrypt(ctx, dest, src, len); > ? Above code is AES specific (since you hardcoded the string "aes"), so yes. :-) Using low-level functions (aes_set_key(), aes_encrypt(), and aes_decrypt()) directly gives programmer more flexibility over block chaining and initialization issues. It would be silly to expect crypto_encrypt() to support all possible weirdo setups. Operation of aes_encrypt() will not change. Code calling aes_encrypt() may change to adapt to different situations: running in Linux kernel, userspace, or other operating systems, whatever. > > Do you think of VFS as "kernel bloat" ? > No. Regards, Jari Ruusu 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 Sep 6 22:24:52 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Thu, 6 Sep 2001 22:24:38 +0200 Received: from dhcp4.icm.edu.pl ([212.87.0.44]:16906 "EHLO bofh.torun.pl") by humbolt.nl.linux.org with ESMTP id ; Thu, 6 Sep 2001 22:24:27 +0200 Received: by bofh.torun.pl via sendmail from stdin id (Debian Smail3.2.0.102) for linux-crypto@nl.linux.org; Thu, 6 Sep 2001 22:33:18 +0200 (CEST) Message-Id: Subject: Re: I-patch problem statement (update) In-Reply-To: <3B97C212.CF3BEF8F@pp.inet.fi> from Jari Ruusu at "Sep 6, 2001 09:36:02 pm" To: Jari Ruusu Date: Thu, 6 Sep 2001 22:33:15 +0200 (CEST) CC: Robert Varga , linux-crypto@nl.linux.org From: Janusz A. Urbanowicz X-Latin-Date: Hodie post. Non. Sep. MMDCCLIV AUC est X-Mayan-Date: 12.19.08.09.14 X-Erisian-Date: Prickle-Prickle, Bureaucracy 30, 3167 YOLD X-Operating-System: Linux sword 2.2.16 i586 X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jari Ruusu wrote/napisał[a]/schrieb: > > Is AES the only cipher worthy enough to be used ? > > How many ciphers does one need? One good one will fill most peoples' needs. What if tomorrow some cryptographer will publish cheap, practical attack on AES? This is unlikely but possible. I'm impressed with your patch and I intent touse it but in this situation I'm stuck with a weak algorithm. In other crypto applications I can switch to always-safe and well researched 3DES. In your patch I can't do this. > > Is it better to have aes_set_key, des_set_key, and probably quite a few others > > rather than: > > > > struct crypto_ctx *ctx = crypto_newctx("aes"); > > crypto_setkey(ctx, "blahblah"); > > crypto_encrypt(ctx, dest, src, len); > > ? > > Above code is AES specific (since you hardcoded the string "aes"), so yes. > :-) > > Using low-level functions (aes_set_key(), aes_encrypt(), and aes_decrypt()) > directly gives programmer more flexibility over block chaining and > initialization issues. It would be silly to expect crypto_encrypt() to > support all possible weirdo setups. Operation of aes_encrypt() will not > change. Code calling aes_encrypt() may change to adapt to different > situations: running in Linux kernel, userspace, or other operating systems, > whatever. Change of cipher algorithm is not a 'weirdo setup requirement'. Alex - -- Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary Gdy daję biednym chleb, nazywają mnie świętym. Gdy pytam, dlaczego biedni nie mają chleba, nazywają mnie komunistą. - abp. Helder Camara -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Dalsze informacje znajdują się na http://www.gnupg.org/ iEYEARECAAYFAjuX3X8ACgkQTfkBjn4ugD23SwCgs5JO+kubPuR+zcWnUWGRAu+w 3K0An2UDvpT9OzlO4hk3/zqYiJo5ptMG =07rm -----END PGP SIGNATURE----- Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Thu Sep 6 22:35:15 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Thu, 6 Sep 2001 22:35:07 +0200 Received: from anime.net ([63.172.78.150]:34054 "EHLO anime.net") by humbolt.nl.linux.org with ESMTP id ; Thu, 6 Sep 2001 22:34:51 +0200 Received: from localhost (goemon@localhost) by anime.net (8.9.3/8.9.3) with ESMTP id NAA08768; Thu, 6 Sep 2001 13:34:40 -0700 Date: Thu, 6 Sep 2001 13:34:40 -0700 (PDT) From: Dan Hollis To: Jari Ruusu cc: Robert Varga , Subject: Re: I-patch problem statement (update) In-Reply-To: <3B97C212.CF3BEF8F@pp.inet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list On Thu, 6 Sep 2001, Jari Ruusu wrote: > > Is AES the only cipher worthy enough to be used ? > How many ciphers does one need? One good one will fill most peoples' needs. Some ciphers are better for certain situations and applications than others. Also: some ciphers are implemented in hardware, others not (eg 3DES). Better to be open-ended design than closed one. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-] 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 Sep 7 00:28:52 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Fri, 7 Sep 2001 00:28:36 +0200 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:29236 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Fri, 7 Sep 2001 00:28:21 +0200 Received: from dirichlet.mathematik.uni-bielefeld.de (ppp36-250.hrz.uni-bielefeld.de [129.70.36.250]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.10.12.16.25.p8) with ESMTP id <0GJ9006EPIFAW7@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Fri, 7 Sep 2001 00:28:24 +0200 (MET DST) Date: Fri, 07 Sep 2001 04:22:48 +0200 From: Marc Mutz Subject: Re: I-patch problem statement (update) In-reply-to: <3B976347.D4052713@pp.inet.fi> To: Jari Ruusu Cc: Herbert Valerio Riedel , linux-crypto@nl.linux.org Message-id: <0GJ9006ESIFBW7@mail.uni-bielefeld.de> MIME-version: 1.0 X-Mailer: KMail [version 1.3.5] Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT X-KMail-Identity: Marc.Mutz@uni-bielefeld.de References: <0GJ80028MHDKM1@mail.uni-bielefeld.de> <3B976347.D4052713@pp.inet.fi> Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 06 September 2001 13:51, Jari Ruusu wrote: > HVR is still playing catch-up as loop-AES-v1.4d does encrypted swap > already. Jari, you will not make friends with being so bold all the time. You know, as an open source developer, your only reward is the respect of the fellow developers and the thanks of happy users. Don't sacrifice the former by aggeressively advertizing your patch, repeatedly stating that it is so superior. As a matter of fact, instead of complaining about the bugs in kerneli, it behoves you to provide patches to fix 'em... Marc - -- We have once again come full circle on the same basic question of privacy on the Internet. If you have privacy, so does the person sending around terrorist documents. And of course, we wouldn't want that now, would we? [...] But what if governments, concerned about mounting public pressure, decided to label protesters at the next WTO roundtable, World Bank meeting, or G-8 summit as terrorists? -- John Horvath: The Internet: A Terrorist Network? Telepolis 2001/08/22 (#9350) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7mC953oWD+L2/6DgRAuyTAJ4g0cg/A12h4cQ9KIQmndHy1t3nEwCcC12u s54kDKD3T24H8VUYOHjkTr0= =Y7J/ -----END PGP SIGNATURE----- ˙˙˙‚ @ N3AÖCŽř"S€k 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 Sep 7 05:18:51 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Fri, 7 Sep 2001 05:18:39 +0200 Received: from adsl-dynamic1-114.appleton.wi.ameritech.net ([64.108.120.114]:3588 "EHLO cybershamanix.com") by humbolt.nl.linux.org with ESMTP id ; Fri, 7 Sep 2001 05:18:17 +0200 Received: from ameritech.net (macdog [192.168.0.4]) by cybershamanix.com (8.11.0/8.11.0) with ESMTP id f873I4Y02513 for ; Thu, 6 Sep 2001 22:18:10 -0500 Message-ID: <3B983C68.8CABBFD@ameritech.net> Date: Thu, 06 Sep 2001 22:18:47 -0500 From: Harmon Seaver Organization: Maddog Press X-Mailer: Mozilla 4.78 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "linux-crypto@nl.linux.org" Subject: Re: announce; monolithic versions of the cryptoapi branch! References: Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list Okay, got the makefile fixed (I think) and it compiles and boots and loads all the crypto at boot like it should. I also chose the IV mode sector, although now I'm not sure that was a good idea. Also patched util-linux and now losetup can work with all the cyphers. Still seems to be some problems, however. I did a test run with just the examples on the losetup man page: > dd if=/dev/zero of=/file bs=1k count=100 > losetup -e blowfish /dev/loop0 /file > Password : > mkfs -t ext2 /dev/loop0 100 > > mount -t ext2 /dev/loop0 /mnt > except I used aes and chose a 128 bit key. Mounted it okay and could read and write to it. Unmounted it and tried to mkreiserfs on it, but reiser said it was too small and that wouldn't work. So then I did a losetup -d on it and started over, this time with a bs=100K count=512, but now I get a kernel error like someone else had mentioned a bit a go, > Sep 6 14:22:18 cybershamanix kernel: Unable to handle kernel NULL pointer deref > erence at virtual address 00000000 > Sep 6 14:22:18 cybershamanix kernel: printing eip: > Sep 6 14:22:18 cybershamanix kernel: c027aa97 > Sep 6 14:22:18 cybershamanix kernel: *pde = 00000000 > Sep 6 14:22:18 cybershamanix kernel: Oops: 0000 > Sep 6 14:22:18 cybershamanix kernel: CPU: 0 > Sep 6 14:22:18 cybershamanix kernel: EIP: 0010:[blowfish_set_key+231/432] > Sep 6 14:22:18 cybershamanix kernel: EFLAGS: 00010282 > Sep 6 14:22:18 cybershamanix kernel: eax: 00000000 ebx: 00000004 ecx: 9b878 > 3a8 edx: 00000000 > Sep 6 14:22:18 cybershamanix kernel: esi: 00000000 edi: 00000011 ebp: c5f69 > f2c esp: c5f69df0 > Sep 6 14:22:18 cybershamanix kernel: ds: 0018 es: 0018 ss: 0018 > Sep 6 14:22:18 cybershamanix kernel: Process losetup (pid: 2428, stackpage=c5f6 > 9000) > Sep 6 14:22:18 cybershamanix kernel: Stack: c5f86a1c 00000000 c0107020 c5f86014 > c5f8605c c5f86014 c0309820 c5f86a1c > Sep 6 14:22:19 cybershamanix kernel: c0309820 c5f69ef9 c5f86000 c5f69ecc > c0275cf6 c5f86000 c5f69f2c 00000020 > Sep 6 14:22:19 cybershamanix kernel: 00000000 c0275ee7 c5f86000 c5f69f2c > 00000020 c5f86000 00000000 fffffff4 > Sep 6 14:22:19 cybershamanix kernel: Call Trace: [ret_from_intr+0/7] [default_s > et_key+22/32] [cryptoapi_status+151/208] [loop_init_xfer+40/80] [loop_set_status > +233/448] > Sep 6 14:22:19 cybershamanix kernel: [lo_ioctl+440/448] [blkdev_ioctl+38/64] > [sys_ioctl+115/416] [system_call+51/64] > Sep 6 14:22:19 cybershamanix kernel: > Sep 6 14:22:19 cybershamanix kernel: Code: 8b 04 96 31 c8 89 04 96 89 da 89 d0 > 8b 4d d8 c1 fa 1f 41 f7 > and, if I try to run losetup of any kind, even losetup -d on the loop0, or on a loop1 instead, that term session locks up. I can't even kill the old losetup job from another term session, have to reboot to get rid of them. So, is my klutziness in setting it up or the IV, or what? -- Harmon Seaver, MLIS CyberShamanix Work 920-203-9633 hseaver@cybershamanix.com Home 920-233-5820 hseaver@ameritech.net http://www.cybershamanix.com/resume.html 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 Sep 7 06:25:45 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Fri, 7 Sep 2001 06:25:37 +0200 Received: from adsl-dynamic1-32.appleton.wi.ameritech.net ([64.108.120.32]:1284 "EHLO cybershamanix.com") by humbolt.nl.linux.org with ESMTP id ; Fri, 7 Sep 2001 06:25:32 +0200 Received: from ameritech.net (macdog [192.168.0.4]) by cybershamanix.com (8.11.0/8.11.0) with ESMTP id f874POL02166 for ; Thu, 6 Sep 2001 23:25:30 -0500 Message-ID: <3B984C34.D46A9EB7@ameritech.net> Date: Thu, 06 Sep 2001 23:26:13 -0500 From: Harmon Seaver Organization: Maddog Press X-Mailer: Mozilla 4.78 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "linux-crypto@nl.linux.org" Subject: Re: announce; monolithic versions of the cryptoapi branch! References: <3B983C68.8CABBFD@ameritech.net> <3B984BF1.BC95CE1A@ameritech.net> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list Hmm, to follow up on my previous post, it seems that the problem is not when I tried using aes as I thought, that was the one that worked originally, and after that I had tried blowfish -- and it is blowfish that blows it. I just created two different loop devices with aes and everything went fine, at least with the 128 bit key. Made one of 3000k and was able to create a reiserfs file system on that and mount it okay. -- Harmon Seaver, MLIS CyberShamanix Work 920-203-9633 hseaver@cybershamanix.com Home 920-233-5820 hseaver@ameritech.net http://www.cybershamanix.com/resume.html 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 Sep 7 07:10:50 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Fri, 7 Sep 2001 07:10:32 +0200 Received: from pentafluge.infradead.org ([195.224.55.251]:6418 "EHLO pentafluge.infradead.org") by humbolt.nl.linux.org with ESMTP id ; Fri, 7 Sep 2001 07:10:05 +0200 Received: from [206.50.173.66] (helo=itrs_nt.ITRS_DOMAIN) by pentafluge.infradead.org with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 15fDo8-00065c-00 for ; Fri, 07 Sep 2001 06:04:00 +0100 Received: from w2kpro01 (ppp-206-170-210-144.lsan03.pacbell.net [206.170.210.144]) by itrs_nt.ITRS_DOMAIN with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id Q1QFVNTZ; Fri, 7 Sep 2001 00:06:28 -0500 Reply-To: From: "IT3 Stuart B. Tener, USNR-R" To: "Jari Ruusu" , "Robert Varga" Cc: Subject: RE: I-patch problem statement (update) Date: Thu, 6 Sep 2001 22:08:02 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B97C212.CF3BEF8F@pp.inet.fi> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Disposition-Notification-To: "IT3 Stuart B. Tener, USNR-R" Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list TXIuIFJ1dXN1Og0KDQoJRm9yZ2l2ZSBtZSBmb3IgYmVpbmcgc28gYmx1bnQsIGJ1dCBkYXJlIEkg c3RhdGUgd2UgYXJlIG5vdCBkZWFsaW5nIHdpdGgga2VybmVsIGJsb2F0LCBidXQgaW4gZmFjdCAi ZWdvIGJsb2F0IiBhbmQgImFycm9nYW5jZSBibG9hdCIuDQoNCglPbmNlIGFnYWluLCBJIHdvdWxk IHRoaW5rIGNhcmVmdWxseSBhYm91dCBhbiBvbGRlIEpld2lzaCBwcm92ZXJiIG15IGZhdGhlciBv bmNlIHNhaWQsICJQZW9wbGUgd2hvbSBzcGVhayBvdXQgb2YgYm90aCBzaWRlcyBvZiB0aGVpciBt b3V0aCBvZnRlbiBzdGljayB0aGVpciBmb290IGluIHRoZWlyIG1vdXRoLiBBZnRlciBhbGwsIGhv dyBkbyB5b3UgdGhpbmsgdGhleSBnZXQgdGhlaXIgbW91dGhzIGJpZyBlbm91Z2ggdG8gdGFsayBv dXQgYm90aCBzaWRlcz8gVGhleSBzdHJldGNoIGl0IHdoZW4gdGhleSBwdXQgdGhlaXIgZm9vdCBp biB0aGVpciBtb3V0aCIuIEkgYW0gbm90IHNheWluZyB0aGlzIHByb3ZlcmIgYXBwbGllcyB0byB5 b3UgTXIuIFJ1dXN1LCBidXQgaXQgZG9lcyBzZWVtIHRvIGZpdCB0aGUgc2l0dWF0aW9uLCBkb2Vz IGl0IG5vdD8NCg0KCVdoYXRldmVyIGhhcyBjYXVzZWQgeW91IHRvIGFmZml4ICJuZWVkIiB0byBw dWJsaWMgZG9tYWluIEdQTCBzdHlsZSBzb2Z0d2FyZT8gUGVyaGFwcyB5b3UgY2FuIGV4cGxhaW4g d2h5IHdlIG5lZWQgc3VwcG9ydCBmb3IgdGhlIGkzODYgaW4gTGludXguIElzIGFueW9uZSB1c2lu ZyBpMzg2IHBsYXRmb3JtIGVuIG1hc3NlIHRvIHN1cHBvcnQgTGludXg/IE9mIGNvdXJzZSBub3Qs IGJ1dCB3ZSBkbyBpdCBiZWNhdXNlIHdlIGNhbiwgYmVjYXVzZSBvZiBvdXIgYWJpbGl0eSB0byBh Y2hpZXZlIHN1Y2ggdGVjaG5pY2FsIGV4Y2VsbGVuY2UgZW5hYmxlcyB1cyB0b28gY29udGludWUg dG8gaW5jcmVhc2UgdGhlIGNhcGFiaWxpdGllcyBvZiBMaW51eCBldmVuIG9uIGFuIGkzODYuIFRo ZSBlbnRpcmUgTGludXggZGV2ZWxvcG1lbnQgY29yZSAod29ybGR3aWRlKSBhbmQgb3RoZXIgR1BM IGJhc2VkIHByb2plY3RzLCBhcmUgYWxsIGRvaW5nIHdoYXQgdGhleSBhcmUgZG9pbmcgZm9yIGZ1 biwgYW5kIHRvIGRlbW9uc3RyYXRlIHRoZSB0ZWNobmljYWwgY2FwYWJpbGl0aWVzIG9mIHRoZSBk ZXZlbG9wZXJzIGFuZCB0aGUgaGFyZHdhcmUgLyBzb2Z0d2FyZSBhcmNoaXRlY3R1cmVzIGVtcGxv eWVkLiBJIGFtIHN1cmUgc29tZSBvZiB0aGUgcGVvcGxlIGFyZSB3cml0aW5nIGNvZGUgdG8gZW5o YW5jZSB0aGVpciBvd24gZWdvIGFzIHdlbGwgKHdoYXQgSSByZWZlciB0byBhcyAiZWdvIGJsb2F0 IikuDQoNCkluIHJldHJvc3BlY3QsIHBlcmhhcHMgSSBhbSB3cm9uZy4gcGVyaGFwcyB5b3UgZG9u J3QgaGF2ZSBlZ28gYmxvYXQuIEluIGZhY3QsIGlmIHlvdSB3ZXJlIGludGVyZXN0ZWQgaW4gc2lt cGx5IGRldmVsb3BpbmcgYSBwcm9kdWN0IHRvIG91dCBkbyB0aGUgSS1wYXRjaCwgaXQgd291bGQg bm90IGJlIGRlZmljaWVudCBhbnkgb2YgdGhlIEktcGF0Y2hlcyBjYXBhYmlsaXRpZXMsIG5vdyB3 b3VsZCBpdD8gQ29udmVyc2VseSBwZXJoYXBzIHRoZSByZWFzb24geW91IGFyZSB0b3V0aW5nIHlv dXIgc29sdXRpb24gc28gc3Ryb25nbHkgaXMgYmVjYXVzZSB5b3Ugd2FudCB0byByZWZvY3VzIHRo ZSBkZWZpY2llbmN5IGlzc3VlcyBvbiB0aGUgSS1wYXRjaCB3aGVuIGluIGZhY3QgZGVlcCBkb3du IHlvdSBhcmUgYXdhcmUgaXQgaXMgeW91ciBwcm9kdWN0IHdoaWNoIG1heSBhbHNvIChpbiBjb21w YXJpc29uIHRvIHRoZSBJLXBhdGNoLCBhIGNvbXBhcmlzb24geW91IGFyZSBjb250aW51aW5nIHRv IGZvcmNlIHBlb3BsZSB0byBtYWtlIHdpdGggeW91ciBzdGF0ZW1lbnRzKSBpcyBhYnNlbnQgZnVu Y3Rpb25hbGl0eSB0aGUgSS1wYXRjaCBoYXMuDQoNCglCZXNpZGVzLCBpZiB5b3Ugd2VyZSB0cnVs eSB0cnlpbmcgdG8gb3V0IGRvIHBlb3BsZSwgeW91IHdvdWxkIGhhdmUgZml4ZWQgdGhlIEktcGF0 Y2ggYSB3aGlsZSBiYWNrLiBJbnN0ZWFkLCB5b3UgbGVhdmUgdXMgdG8gYmVsaWV2ZSB0aGF0IHNv bWVob3cgeW91ciBzb2Z0d2FyZSBpcyBiZXR0ZXIuIFdoeT8gQmVjYXVzZSBpdCBkb2VzIG5vdCBk byBhbGwgdGhlIGVuY3J5cHRpb25zLCB0aGUgSS1wYXRjaCBkb2VzLiBTZXZlcmFsIHBlb3BsZSBo YXZlIGluIGZhY3QgY29tbWVudGVkIGFzIHRvIHRoZSBsYWNrIG9mIGRpdmVyc2l0eSBpbiB0ZXJt cyBvZiBhbGdvcml0aG1zLCB3aGljaCB5b3VyIHNvbHV0aW9uIGZhaWxzIHRvIHByb3ZpZGUuIE5v dyB5b3UgYXJlIHdlbGNvbWUgdG8gc2F5LCBJIGRvIG5vdCBjYXJlIHRvIHdyaXRlIHdoYXQgSSBo YXZlIG5vdCB3cml0dGVuIHRodXMgZmFyLCBidXQgdGhlbiB5b3Ugd2lsbCB1bmRlcnN0YW5kIHdo eSBwZW9wbGUgYXJlIHVzaW5nIGEgZGlmZmVyZW50IHNvbHV0aW9uIGFzIHdlbGwuIFdoYXQgZG9l cyB0aGlzIG1lYW4/IEl0IG1lYW5zIHBlb3BsZSwgbWF5IGluIGZhY3QgYmUgZGVzaXJvdXMgb2Yg aW1wbGVtZW50aW5nIHlvdXIgaWRlYXMgYnV0IGNhbm5vdCwgZHVlIHRvIGxpbWl0YXRpb24uIElm IGluIGZhY3QgeW91IHdpc2ggdG8gd3JpdGUgY29kZSBpbiBvcmRlciBmb3Igb3RoZXJzIHRvIHVz ZSBpdCwgYW5kIG5vdCBhcyBhbiBleGVyY2lzZSBpbiBleGVtcGxpZmljYXRpb24sIHlvdSBtdXN0 IGNvbnNpZGVyIHRoZSBjb21tZW50YXJ5IGV4YWN0ZWQgYnkgeW91ciB1c2VyIGJhc2UuDQoNCglQ ZXJoYXBzIEkgaGF2ZSBhIGNsaWVudCB0aGF0IGhhcyBhIGNvbXBhbnkgcG9saWN5IG9mIHVzaW5n IHN0cmljdGx5IERFUy4gSSBjYW5ub3QgdXNlIHlvdXIgZHJpdmVyLCBubyBtYXR0ZXIgaG93IHN1 cGVyaW9yIGl0IG1pZ2h0IGJlIGluIGl0cyBkZXNpZ24uIElmIHlvdSBhcmUgZ29pbmcgdG8gY2xh aW0gdGhhdCB0aGUgSS1wYXRjaCBpcyBzbyBzaWduaWZpY2FudGx5IGRlZmljaWVudCBpbiBpdHMg Y2FwYWJpbGl0aWVzLCBob3cgYWJvdXQgYXQgbGVhc3QgcHJvdmlkaW5nIHNvZnR3YXJlIHdoaWNo IGhhcyBubyBsZXNzIHRoZSBhZHZhbnRhZ2VzIG9mIHRoZSBJLXBhdGNoIGJlZm9yZSBtYWtpbmcg c3VjaCBzdGF0ZW1lbnRzLg0KDQoJV2hpbGUgSSBhZ3JlZSBvbmUgZ29vZCBjaXBoZXIgd2lsbCBm aXQgbW9zdCBwZW9wbGUncyBuZWVkcywgSSBkaXNhZ3JlZSB0aGF0IHlvdSBvdWdodCB0byBiZSB0 aGUgb25lIHRvIGNob29zZSBpdC4gSW4gdGhpcyB3b3JsZCBvZiBwb3dlcmZ1bCBmcmVlIEdQTCBz b2Z0d2FyZSwgc2lsbHkgbWUsIEkgcHJlZmVyIHRvIGJlIHRoZSBvbmUgdGhhdCBjaG9vc2UgdGhl IG9uZSBnb29kIGNpcGhlciB0aGF0IGZpdHMgbXkgbmVlZHMuIFNvLCBhYnNlbnQgeW91ciBzb2Z0 d2FyZSBiZWluZyB1cGRhdGVkIHRvIHByb3ZpZGUgdGhhdCBmbGV4aWJpbGl0eSwgd2hhdCBkbyB5 b3UgcmVjb21tZW5kPyBUaGUgSS1wYXRjaD8gSXQgaXMgaW4gZmFjdCBteSBwb2xpY3kgYXMgYSBj b25zdWx0YW50LCB0byBhbHdheXMgY29tcGVsIG15IGNsaWVudHMgdG8gZG9uYXRlIHRvIHRoZSBh dXRob3JzIG9mIEdQTCBzdHlsZSBzb2Z0d2FyZSBpZiBpdCBpcyBiZWluZyB1c2VkIGZvciBjb21t ZXJjaWFsIHB1cnBvc2VzLCBldmVuIGlmIG5vdCByZXF1ZXN0ZWQuIEkgZG8gbm90IChpbiB0aGUg aW5zdGFudCkgaGF2ZSBhIGNsaWVudCBmaXR0aW5nIHRoaXMgbW9sZCwgYnV0IGhhZCBjbGllbnRz IHdpdGggc3VjaCBwb2xpY2llcyBiZWZvcmUgSSBrbmV3IG9mIHlvdXIgc29mdHdhcmUgZXZlbiBl eGlzdGluZy4NCg0KCU9mIGNvdXJzZSwgdGhlIHRydWUgZWdvIG1hbmlhYyB3b3VsZCBub3QgbWlz cyBvdXQgb24gc3VjaCBhbiBvcHBvcnR1bml0eSBhcyBpcyBwcmVzZW50ZWQgaGVyZS4gQWZ0ZXIg YWxsLCB3aGF0IGJldHRlciB3YXkgdG8gcHJvdmUgdGhlIHByb2JsZW1zIHdpdGggdGhlIEktcGF0 Y2ggYnV0IHRvIGZpeCB0aGVtLCBvciB3cml0ZSB5b3VyIG93biBrZXJuZWwgcGF0Y2g/DQoNCkhv d2V2ZXIsIGlmIGluIGZhY3QgaXQgaXMgeW91ciBvd24gY29nbml0aXZlIGRlZmljaWVuY2llcyAo SSBhbSBub3Qgc2F5aW5nIGl0IGlzLCBidXQgImlmIGl0IGlzIikgd2hpY2ggcHJldmVudCB5b3Ug ZnJvbSBoZWxwaW5nIHRvIGltcHJvdmUgdGhlIEktcGF0Y2gsIG9yIGFkZCBjaXBoZXJzIHRvIHlv dXIgc29mdHdhcmUsIG9yIGV2ZW4gd3JpdGUgeW91ciBvd24ga2VybmVsIHBhdGNoLCB0aGVuIGlu IGZhY3QgSSBodW1ibHkgYXBvbG9naXplIGZvciBhbGwgSSBoYXZlIHNhaWQsIGFic2VudCB0aGF0 IGZhY3QsIEkgd291bGQgcmVxdWVzdCB0aGF0IHlvdSB0aGluayBhYm91dCB3aGF0IEkgKGFuZCBv dGhlcnMpIGhhdmUgc2FpZCBhYm91dCB3aGF0IHdlIGFyZSBsb29raW5nIGZvci4gV2hhdCBib2dn bGVzIHRoZSBtaW5kIChmb3IgbWUpLCBpcyB0aGF0IHNvbWVvbmUgKHlvdSkgd2hvbSBJIHRoaW5r IGlzIHNvIHZlcnkgaW50ZWxsaWdlbnQsIHNlZW1zIHRvIG1pc3MgdGhlIHBvaW50IGFzIHRvIHdo YXQgcGVvcGxlIHdhbnQgaW4gYSBMaW51eCBiYXNlZCBjaXBoZXIgc29mdHdhcmUsIHdoaWxlIGlu c2lzdGluZyB0aGUgZW50aXJlIHRpbWUsIGl0IHVzIHdob20gcmVhbGx5IGFyZSBkZXNpcmluZyB0 aGUgd3JvbmcgdGhpbmcsIG5vdCB5b3Ugd2hvbSBpcyBub3QgcHJvdmlkaW5nIHRoZSBzb2Z0d2Fy ZSB3ZSB3aXNoIHRvIGhhdmUuIE5vdyBubyBvbmUgaXMgc2F5aW5nIGl0cyB5b3VyIGpvYiBpbiB0 aGUgd29ybGQgdG8gd3JpdGUgdGhlIGJlc3QgZW5jcnlwdGlvbiBzb2Z0d2FyZSBmb3IgTGludXgg YXMgYSBnaWZ0IHRvIHVzIGFsbCwgYnV0LCBpZiB5b3Ugd2lzaCB0byBwdXJwb3J0IHRoZSBhZHZh bnRhZ2Ugb2YgeW91cnMgb2YgeW91ciBzb2Z0d2FyZSwgYW5kIEkgdGhpbmsgd2UgYXJlIGFsbCB3 aWxsaW5nIHRvIGNvbnNpZGVyIGl0cyB1c2UgKGV2ZW4gaW4gcmVzcGVjdCBvZiBpdHMgYXV0aG9y J3MgZWdvIGFuZCBhcnJvZ2FuY2UgYmxvYXQpLCB5b3UgZXhwZWN0IHNvbWUgbGV2ZWwgb2YgcmVx dWVzdCBmb3IgZmVhdHVyZXMgYW5kIGNvbXBhcmlzb24gYXMgeW91IHNlZW0gdG8gYmUgY29udGlu dWluZyB0byBmb3JjZSB0aGUgY29tcGFyYXRpdmUgaXNzdWUuDQoNCg0KVmVyeSBSZXNwZWN0ZnVs bHksIA0KDQpTdHVhcnQgQmxha2UgVGVuZXIsIElUMywgVVNOUi1SLCBOM0dXRyANCkJldmVybHkg SGlsbHMsIENhbGlmb3JuaWENClZUVSAxOTA0RyAoVm9sdW50ZWVyIFRyYWluaW5nIFVuaXQpIA0K c3R1YXJ0QGJoOTAyMTAubmV0IA0Kd2VzdCBjb2FzdDogKDMxMCktMzU4LTAyMDIgUC5PLiBCb3gg MTYwNDMsIEJldmVybHkgSGlsbHMsIENBIDkwMjA5LTIwNDMgDQplYXN0IGNvYXN0OiAoMjE1KS0z MzgtNjAwNSBQLk8uIEJveCA0NTg1OSwgUGhpbGFkZWxwaGlhLCBQQSAxOTE0OS01ODU5IA0KDQpU ZWxlY29waWVyOiAoNDE5KS03MTUtNjA3MyBmYXggdG8gZW1haWwgZ2F0ZXdheSB2aWEgd3d3LmVm YXguY29tIChpdCdzIGZyZWUhKSANCg0KSk9JTiBUSEUgVVMgTkFWWSBSRVNFUlZFLCBTRVJWRSBZ T1VSIENPVU5UUlksIEFORCBCRU5FRklUIEZST00gSVQgQUxMLiANCg0KVGh1cnNkYXksIFNlcHRl bWJlciAwNiwgMjAwMSA2OjEzIFBNDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBvd25lci1saW51eC1jcnlwdG9AbmwubGludXgub3JnIFttYWlsdG86b3duZXItbGludXgtY3J5 cHRvQG5sLmxpbnV4Lm9yZ11PbiBCZWhhbGYgT2YgSmFyaSBSdXVzdQ0KU2VudDogVGh1cnNkYXks IFNlcHRlbWJlciAwNiwgMjAwMSAxMTozNiBBTQ0KVG86IFJvYmVydCBWYXJnYQ0KQ2M6IGxpbnV4 LWNyeXB0b0BubC5saW51eC5vcmcNClN1YmplY3Q6IFJlOiBJLXBhdGNoIHByb2JsZW0gc3RhdGVt ZW50ICh1cGRhdGUpDQoNClJvYmVydCBWYXJnYSB3cm90ZToNCj4gQSBjb3VwbGUgcXVlc3Rpb25z Og0KPiBJcyBlbmNyeXB0ZWQgbG9vcGJhY2sgdGhlIG9ubHkgcGxhY2UgaW4ga2VybmVsIHdoZXJl IGVuY3J5cHRpb24gY2FuIGJlIHVzZWQ/DQoNCk5vLiBCdXQgbG9vcCBkcml2ZXIgaGFzIGEgZ29v ZCBpbnRlcmZhY2UgZm9yIGRpZmZlcmVudCBjaXBoZXJzLiBDcnlwdG8tYXBpDQpmb3IgbG9vcCBk ZXZpY2VzIGFkZHMgYW4gZXh0cmEgdW5uZWNlc3NhcnkgbGF5ZXIuIFNtYWxsIGFuZCBmYXN0IGlz DQpiZWF1dGlmdWwuDQoNCj4gSXMgQUVTIHRoZSBvbmx5IGNpcGhlciB3b3J0aHkgZW5vdWdoIHRv IGJlIHVzZWQgPw0KDQpIb3cgbWFueSBjaXBoZXJzIGRvZXMgb25lIG5lZWQ/IE9uZSBnb29kIG9u ZSB3aWxsIGZpbGwgbW9zdCBwZW9wbGVzJyBuZWVkcy4NCg0KPiBJcyBpdCBiZXR0ZXIgdG8gaGF2 ZSBhZXNfc2V0X2tleSwgZGVzX3NldF9rZXksIGFuZCBwcm9iYWJseSBxdWl0ZSBhIGZldyBvdGhl cnMNCj4gcmF0aGVyIHRoYW46DQo+DQo+IHN0cnVjdCBjcnlwdG9fY3R4ICpjdHggPSBjcnlwdG9f bmV3Y3R4KCJhZXMiKTsNCj4gY3J5cHRvX3NldGtleShjdHgsICJibGFoYmxhaCIpOw0KPiBjcnlw dG9fZW5jcnlwdChjdHgsIGRlc3QsIHNyYywgbGVuKTsNCj4gPw0KDQpBYm92ZSBjb2RlIGlzIEFF UyBzcGVjaWZpYyAoc2luY2UgeW91IGhhcmRjb2RlZCB0aGUgc3RyaW5nICJhZXMiKSwgc28geWVz Lg0KOi0pDQoNClVzaW5nIGxvdy1sZXZlbCBmdW5jdGlvbnMgKGFlc19zZXRfa2V5KCksIGFlc19l bmNyeXB0KCksIGFuZCBhZXNfZGVjcnlwdCgpKQ0KZGlyZWN0bHkgZ2l2ZXMgcHJvZ3JhbW1lciBt b3JlIGZsZXhpYmlsaXR5IG92ZXIgYmxvY2sgY2hhaW5pbmcgYW5kDQppbml0aWFsaXphdGlvbiBp c3N1ZXMuIEl0IHdvdWxkIGJlIHNpbGx5IHRvIGV4cGVjdCBjcnlwdG9fZW5jcnlwdCgpIHRvDQpz dXBwb3J0IGFsbCBwb3NzaWJsZSB3ZWlyZG8gc2V0dXBzLiBPcGVyYXRpb24gb2YgYWVzX2VuY3J5 cHQoKSB3aWxsIG5vdA0KY2hhbmdlLiBDb2RlIGNhbGxpbmcgYWVzX2VuY3J5cHQoKSBtYXkgY2hh bmdlIHRvIGFkYXB0IHRvIGRpZmZlcmVudA0Kc2l0dWF0aW9uczogcnVubmluZyBpbiBMaW51eCBr ZXJuZWwsIHVzZXJzcGFjZSwgb3Igb3RoZXIgb3BlcmF0aW5nIHN5c3RlbXMsDQp3aGF0ZXZlci4N Cg0KPiA8ZmxhbWU+DQo+IERvIHlvdSB0aGluayBvZiBWRlMgYXMgImtlcm5lbCBibG9hdCIgPw0K PiA8L2ZsYW1lPg0KDQpOby4NCg0KUmVnYXJkcywNCkphcmkgUnV1c3UgPGphcmkucnV1c3VAcHAu aW5ldC5maT4NCg0KDQpMaW51eC1jcnlwdG86ICBjcnlwdG9ncmFwaHkgaW4gYW5kIG9uIHRoZSBM aW51eCBzeXN0ZW0NCkFyY2hpdmU6ICAgICAgIGh0dHA6Ly9tYWlsLm5sLmxpbnV4Lm9yZy9saW51 eC1jcnlwdG8vDQo= 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 Sep 7 08:53:07 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Fri, 7 Sep 2001 08:53:03 +0200 Received: from pluto.runbox.com ([193.71.199.39]:19475 "EHLO pluto.runbox.com") by humbolt.nl.linux.org with ESMTP id ; Fri, 7 Sep 2001 08:52:50 +0200 Received: from [32.103.46.251] (helo=room101.2y.net) by pluto.runbox.com with esmtp (Exim 3.16 #2) id 15fFV2-0002JC-00 for linux-crypto@nl.linux.org; Fri, 07 Sep 2001 08:52:39 +0200 Received: by room101.2y.net (Postfix, from userid 1000) id 0BA8721D43; Fri, 7 Sep 2001 01:51:14 -0500 (CDT) Date: Fri, 7 Sep 2001 01:51:14 -0500 From: Rob McGee To: linux-crypto@nl.linux.org Subject: cryptoapi-2.4.7.0: IV_MODE_SECTOR confusion Message-ID: <20010907015114.B4196@hal> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list Hi all, I'm new to the list (but I've read a couple of months of the archives if that counts.) Formerly I used the kerneli 2.4.3.1 patch, until some unknown disaster recently ate my root fs. I had my 2.4.3 crypto modules backed up -- on an encrypted loop file, of course. :) So I upgraded to 2.4.9 and stumbled upon HVR's work. Thanks, Herbert! I read what's there about the IV_MODE_SECTOR issue, and I think I understand it but am not sure. With this enabled, a loop file will use a block size of 512 bytes for the cryptoapi, and a copy of a loop file will work no matter what the block size of the media it is on, and of the media where it was created. Without it, if you create an encrypted loop file on an ext2fs with a 1024 block size, a copy of that file can only be mounted if it is on media with an identical block size. Is that it? Or is it the block size of the filesystem inside the loop file which is significant? See, I am wanting to make some encrypted CD's which of course I would prefer to be able to mount directly from the CD. And I want them to be accessible in the future, of course, even if I'm using ext9fs with 40MB blocks on my 900TB turbo-optic storage device. (I'll still want to look at the pictures of my kids from AD 2001, even when the CD-ROM format is insignificant and outdated.) While I'm here, and rather than write another post, I'd like to address some comments to Jari. I think your project is excellent! It does make sense to have a different approach in a competing project. But as someone else commented, I would prefer to see at least one other algorithm available. I'm no cryptographer nor mathematician, but ISTM that having only one algorithm potentially helps an attacker, because there's only that one to contend with. You can look at the system and see which project is in use, and if it's Loop-AES you know with high probability that any large incomprehensible file could be an AES loop container. But if its Crypto API, you have to consider all the alternatives too. And in the crypto world you have to think about the future: algorithms might be cracked, computing power might make brute force attacks feasible. I hope to see both projects do very well while maintaining the highest possible cryptographic strength. Whose is "ahead" of the other doesn't really interest me except insofar as one's advances might also help the other project. In a competition like this, we're all on the same side: the only real enemy is the one who might want to read our data. Jari, I personally would be more interested in your project with the choice of at least one other algorithm, and if it could coexist with the kernel's loop driver. The latter issue would better fit in with your project's vision; a user could perhaps carry removable media with a loop file, and be able to access it on almost any machine. How about if it could be done all in user space, even without root access? Then you would have an important distinction from Crypto API! Rob - /dev/rob0 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 Sep 7 10:05:59 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Fri, 7 Sep 2001 10:05:52 +0200 Received: from pluto.runbox.com ([193.71.199.39]:37638 "EHLO pluto.runbox.com") by humbolt.nl.linux.org with ESMTP id ; Fri, 7 Sep 2001 10:05:41 +0200 Received: from [32.103.46.251] (helo=room101.2y.net) by pluto.runbox.com with esmtp (Exim 3.16 #2) id 15fGdS-0000L2-00 for linux-crypto@nl.linux.org; Fri, 07 Sep 2001 10:05:29 +0200 Received: by room101.2y.net (Postfix, from userid 1000) id 257D021E6D; Fri, 7 Sep 2001 03:03:13 -0500 (CDT) Date: Fri, 7 Sep 2001 03:03:12 -0500 From: Rob McGee To: linux-crypto@nl.linux.org Subject: another IV_MODE_SECTOR question Message-ID: <20010907030312.C4196@hal> References: <20010907015114.B4196@hal> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010907015114.B4196@hal>; from rob0@runbox.com on Fri, Sep 07, 2001 at 01:51:14AM -0500 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list On Fri, Sep 07, 2001 at 01:51:14AM -0500, Rob McGee wrote: > While I'm here, and rather than write another post, I'd like to address Ah, but silly me, I have one more question. Playing with it some more, I applied the 2.4.6 patch to my kernel loop driver (2.4.9, but it applied cleanly.) Then I recompiled the loop.o (it's a module) compiled the cryptoapi-2.4.7.0 again, make install, depmod, modprobe cryptoloop (kmod is enabled too.) Now I can't access my encrypted loop file which was created under the kerneli 2.4.3.1 patch. Is this to be expected? Anyway, that's no worry, because I can easily switch back to the other loop.o and cryptoapi modules, and I don't really need that loop file. But I'm really not clear on what is the tradeoff in using --enable-iv-mode-sector vs. not using it. If I gain universal access to files on alternate media, that's great. What do I lose besides a little backward compatibility? Or is that it? Rob - /dev/rob0 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 Sep 7 10:12:13 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Fri, 7 Sep 2001 10:12:01 +0200 Received: from hq.alert.sk ([147.175.66.131]:61196 "EHLO hq.alert.sk") by humbolt.nl.linux.org with ESMTP id ; Fri, 7 Sep 2001 10:11:35 +0200 Received: by hq.alert.sk (Postfix, from userid 608) id 3CF1745E9A; Fri, 7 Sep 2001 10:10:49 +0200 (CEST) Date: Fri, 7 Sep 2001 10:10:49 +0200 From: Robert Varga To: Jari Ruusu Cc: linux-crypto@nl.linux.org Subject: Re: I-patch problem statement (update) Message-ID: <20010907101049.A13415@hq.alert.sk> References: <3B976333.77E763C2@pp.inet.fi> <20010906145139.A26782@hq.alert.sk> <3B97C212.CF3BEF8F@pp.inet.fi> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B97C212.CF3BEF8F@pp.inet.fi>; from jari.ruusu@pp.inet.fi on Thu, Sep 06, 2001 at 09:36:02PM +0300 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 06, 2001 at 09:36:02PM +0300, Jari Ruusu wrote: > Robert Varga wrote: > > Is AES the only cipher worthy enough to be used ? >=20 > How many ciphers does one need? One good one will fill most peoples' need= s. Let's not get into this ;-( This is a "How many OSes does one need" type of= question ;-) It has been discussed, flamed, grilled, baked and cooked innumerable times. > > Is it better to have aes_set_key, des_set_key, and probably quite a few= others > > rather than: > >=20 > > struct crypto_ctx *ctx =3D crypto_newctx("aes"); > > crypto_setkey(ctx, "blahblah"); > > crypto_encrypt(ctx, dest, src, len); > > ? >=20 > Above code is AES specific (since you hardcoded the string "aes"), so yes. > :-) sure :-))) same way I hardcoded the encryption key to "blahblah" ;-))) > Using low-level functions (aes_set_key(), aes_encrypt(), and aes_decrypt(= )) > directly gives programmer more flexibility over block chaining and > initialization issues. It would be silly to expect crypto_encrypt() to > support all possible weirdo setups. Operation of aes_encrypt() will not Not all. More than one. And they need not be weird. > change. Code calling aes_encrypt() may change to adapt to different > situations: running in Linux kernel, userspace, or other operating system= s, > whatever. >=20 > > > > Do you think of VFS as "kernel bloat" ? > > >=20 > No. So instead of writing cipher-specific code all over the place, wouldn't it = be better to have some kind of crypto-VFS ? Yes, I know I am moving away rapidly from loopback encryption. It is a nice= feature, but generally not really usable on multi-user machines. --=20 Kind regards, Robert Varga ---------------------------------------------------------------------------= --- n@hq.sk http://hq.sk/~nite/gpgkey.= txt =20 --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7mIEI9aKR2/T45h8RAtu8AJ4yZsD4AygWU0RAGCigCq+QwWmjmgCfc9lu VKgK3TrxnUnI0VkZffPUjOU= =1L5f -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY-- 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 Sep 7 13:52:42 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Fri, 7 Sep 2001 13:52:37 +0200 Received: from dhcp4.icm.edu.pl ([212.87.0.44]:51978 "EHLO bofh.torun.pl") by humbolt.nl.linux.org with ESMTP id ; Fri, 7 Sep 2001 13:52:19 +0200 Received: by bofh.torun.pl via sendmail from stdin id (Debian Smail3.2.0.102) for linux-crypto@nl.linux.org; Fri, 7 Sep 2001 14:01:14 +0200 (CEST) Message-Id: Subject: Re: I-patch problem statement (update) In-Reply-To: <3B97C212.CF3BEF8F@pp.inet.fi> from Jari Ruusu at "Sep 6, 2001 09:36:02 pm" To: Jari Ruusu Date: Thu, 6 Sep 2001 22:33:11 +0200 (CEST) CC: Robert Varga , linux-crypto@nl.linux.org From: Janusz A. Urbanowicz X-Latin-Date: Hodie post. Non. Sep. MMDCCLIV AUC est X-Mayan-Date: 12.19.08.09.14 X-Erisian-Date: Prickle-Prickle, Bureaucracy 30, 3167 YOLD X-Operating-System: Linux sword 2.2.16 i586 X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit Content-Length: 1892 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jari Ruusu wrote/napisał[a]/schrieb: > > Is AES the only cipher worthy enough to be used ? > > How many ciphers does one need? One good one will fill most peoples' needs. What if tomorrow some cryptographer will publish cheap, practical attack on AES? This is unlikely but possible. I'm impressed with your patch and I intent touse it but in this situation I'm stuck with a weak algorithm. In other crypto applications I can switch to always-safe and well researched 3DES. In your patch I can't do this. > > Is it better to have aes_set_key, des_set_key, and probably quite a few others > > rather than: > > > > struct crypto_ctx *ctx = crypto_newctx("aes"); > > crypto_setkey(ctx, "blahblah"); > > crypto_encrypt(ctx, dest, src, len); > > ? > > Above code is AES specific (since you hardcoded the string "aes"), so yes. > :-) > > Using low-level functions (aes_set_key(), aes_encrypt(), and aes_decrypt()) > directly gives programmer more flexibility over block chaining and > initialization issues. It would be silly to expect crypto_encrypt() to > support all possible weirdo setups. Operation of aes_encrypt() will not > change. Code calling aes_encrypt() may change to adapt to different > situations: running in Linux kernel, userspace, or other operating systems, > whatever. Change of cipher algorithm is not a 'weirdo setup requirement'. Alex - -- Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary Gdy daję biednym chleb, nazywają mnie świętym. Gdy pytam, dlaczego biedni nie mają chleba, nazywają mnie komunistą. - abp. Helder Camara -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Dalsze informacje znajdują się na http://www.gnupg.org/ iEYEARECAAYFAjuX3X8ACgkQTfkBjn4ugD23SwCgs5JO+kubPuR+zcWnUWGRAu+w 3K0An2UDvpT9OzlO4hk3/zqYiJo5ptMG =07rm -----END PGP SIGNATURE----- Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Fri Sep 7 15:46:20 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Fri, 7 Sep 2001 15:46:02 +0200 Received: from hank-fep8-0.inet.fi ([194.251.242.203]:51197 "EHLO fep08.tmt.tele.fi") by humbolt.nl.linux.org with ESMTP id ; Fri, 7 Sep 2001 15:45:39 +0200 Received: from pp.inet.fi ([212.213.41.193]) by fep08.tmt.tele.fi (InterMail vM.5.01.03.00 201-253-122-118-20010201) with ESMTP id <20010907133638.RILB26610.fep08.tmt.tele.fi@pp.inet.fi>; Fri, 7 Sep 2001 16:36:38 +0300 Message-ID: <3B98CCE3.7227F35@pp.inet.fi> Date: Fri, 07 Sep 2001 16:34:27 +0300 From: Jari Ruusu X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19aa2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Robert Varga , Marc Mutz , "Janusz A. Urbanowicz" , "IT3 Stuart B. Tener, USNR-R" CC: linux-crypto@nl.linux.org Subject: Re: I-patch problem statement (update) References: <3B976333.77E763C2@pp.inet.fi> <20010906145139.A26782@hq.alert.sk> <3B97C212.CF3BEF8F@pp.inet.fi> <20010907101049.A13415@hq.alert.sk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list [ replying to multiple persons in same email ] Robert Varga wrote: > On Thu, Sep 06, 2001 at 09:36:02PM +0300, Jari Ruusu wrote: > > Above code is AES specific (since you hardcoded the string "aes"), so yes. > > :-) > > sure :-))) same way I hardcoded the encryption key to "blahblah" ;-))) Exactly :-) > So instead of writing cipher-specific code all over the place, wouldn't it be > better to have some kind of crypto-VFS ? If the API provided pointers to low-level functions, it might be usable for all sorts of use, and be fast too. Something like this: encrypt_function1 = crypto_get_ecrypt_function("aes", 128, 128); encrypt_function2 = crypto_get_ecrypt_function("fish2", 128, 128); do { (*encrypt_function1)(ctx1, from, to); [snip] (*encrypt_function2)(ctx2, to, to); [snip] if(current->need_resched) schedule(); } while(--x); > Yes, I know I am moving away rapidly from loopback encryption. It is a nice feature, > but generally not really usable on multi-user machines. Yep. Loop encryption is useful on laptops that are easily lost or stolen. ======================================= Marc Mutz wrote: > Jari, you will not make friends with being so bold all the time. You know, > as an open source developer, your only reward is the respect of the fellow > developers and the thanks of happy users. Don't sacrifice the former by > aggeressively advertizing your patch, repeatedly stating that it is so > superior. As a matter of fact, instead of complaining about the bugs in > kerneli, it behoves you to provide patches to fix 'em... When Alexander Kjeldaas was maintaining kerneli patch, he said "no" to my enhancements. HVR has largely ignored what I send him, so I don't expect him to act any different now. HVR is free to merge the fixes from loop-AES if he so wishes. Marc, as long as you and rest of kerneli/crypto-api clan don't even admit that loop-AES exists, I reserve the right to "advertise" loop-AES. ======================================= "Janusz A. Urbanowicz" wrote: > What if tomorrow some cryptographer will publish cheap, practical attack > on AES? This is unlikely but possible. If that happens, loop-twofish is born. > I'm impressed with your patch and I intent touse it but in this > situation I'm stuck with a weak algorithm. In other crypto applications I > can switch to always-safe and well researched 3DES. In your patch I can't do > this. In previous life, loop-AES used to be loop-TripleDES for years. There was nothing wrong with that, except that is was slow. loop-TripleDES was not publically available. I made loop-AES publically available after I swithed the cipher from 3DES to AES. > Change of cipher algorithm is not a 'weirdo setup requirement'. By weirdo I meant unusual initialization and block chaining stuff. ======================================= "IT3 Stuart B. Tener, USNR-R" wrote: > Forgive me for being so blunt, but dare I state we are not dealing with > kernel bloat, but in fact "ego bloat" and "arrogance bloat". Opinions vary. > Conversely perhaps the reason you are touting your solution so strongly is > because you want to refocus the deficiency issues on the I-patch when in > fact deep down you are aware it is your product which may also (in > comparison to the I-patch, a comparison you are continuing to force people > to make with your statements) is absent functionality the I-patch has. What? Are you asking me NOT to make loop bugs public? The "absent functionality" of loop-AES is unnecessary bloat that I don't want in loop-AES. Loop-AES is small by desing, and that means less bugs and less code to audit. > Besides, if you were truly trying to out do people, you would have fixed > the I-patch a while back. I do not maintain i-patch or HVR crypto-api. I maintain loop-AES. What is wrong with little competition? At least then people have a choice. > While I agree one good cipher will fit most people's needs, I disagree > that you ought to be the one to choose it. I am not forcing anyone to use loop-AES. > However, if in fact it is your own cognitive deficiencies (I am not saying > it is, but "if it is") which prevent you from helping to improve the > I-patch, or add ciphers to your software, or even write your own kernel > patch, then in fact I humbly apologize for all I have said, absent that > fact, I would request that you think about what I (and others) have said > about what we are looking for. As I said before, I do not maintain i-patch or HVR crypto-api. Kernel patch version of loop-AES, -p option for losetup/mount, encrypted swap were _all_ requested by loop-AES users. I added them because they were requested and made a lot of sense. You, Stuart, have requested me to add some shitty Winblows support, and I have replied that I won't do that. That does not count as "cognitive deficiency". Regards, Jari Ruusu 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 Sep 7 17:01:47 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Fri, 7 Sep 2001 17:01:27 +0200 Received: from dhcp4.icm.edu.pl ([212.87.0.44]:19211 "EHLO bofh.torun.pl") by humbolt.nl.linux.org with ESMTP id ; Fri, 7 Sep 2001 17:01:14 +0200 Received: by bofh.torun.pl via sendmail from stdin id (Debian Smail3.2.0.102) for linux-crypto@nl.linux.org; Fri, 7 Sep 2001 17:09:54 +0200 (CEST) Message-Id: Subject: Re: I-patch problem statement (update) In-Reply-To: <3B98CCE3.7227F35@pp.inet.fi> from Jari Ruusu at "Sep 7, 2001 04:34:27 pm" To: Jari Ruusu Date: Fri, 7 Sep 2001 17:09:53 +0200 (CEST) CC: Robert Varga , Marc Mutz , "Janusz A. Urbanowicz" , "IT3 Stuart B. Tener, USNR-R" , linux-crypto@nl.linux.org From: Janusz A. Urbanowicz X-Latin-Date: Hodie VII Id. Sep. MMDCCLIV AUC est X-Mayan-Date: 12.19.08.09.15 X-Erisian-Date: Setting Orange, Bureaucracy 31, 3167 YOLD X-Operating-System: Linux sword 2.2.16 i586 X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list Jari Ruusu wrote/napisał[a]/schrieb: > "Janusz A. Urbanowicz" wrote: > > What if tomorrow some cryptographer will publish cheap, practical attack > > on AES? This is unlikely but possible. > > If that happens, loop-twofish is born. And all users are forced to repatch, recompile, reboot and repent. This is broken. Algorithm-switch should be possible without such severe system modification (yes, patching kernel and rebooting may be a problem on RL productivity servers). > > I'm impressed with your patch and I intent touse it but in this > > situation I'm stuck with a weak algorithm. In other crypto applications I > > can switch to always-safe and well researched 3DES. In your patch I can't do > > this. > > In previous life, loop-AES used to be loop-TripleDES for years. There was > nothing wrong with that, except that is was slow. loop-TripleDES was not > publically available. I made loop-AES publically available after I swithed > the cipher from 3DES to AES. Oh, sure. And I have want to use, and have a license for IDEA[1]? Or blowfish? Or CAST? I do not ask you to include these ciphers. I only say that it is a very bad idea to hardcode one algorithm you personally think is best. [1] I don't need it - here you can't patent algorithms. -- Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary Gdy daję biednym chleb, nazywają mnie świętym. Gdy pytam, dlaczego biedni nie mają chleba, nazywają mnie komunistą. - abp. Helder Camara 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 Sep 7 17:59:31 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Fri, 7 Sep 2001 17:59:22 +0200 Received: from adsl-dynamic1-32.appleton.wi.ameritech.net ([64.108.120.32]:6660 "EHLO cybershamanix.com") by humbolt.nl.linux.org with ESMTP id ; Fri, 7 Sep 2001 17:59:12 +0200 Received: from ameritech.net (macdog [192.168.0.4]) by cybershamanix.com (8.11.0/8.11.0) with ESMTP id f87FxAL02857 for ; Fri, 7 Sep 2001 10:59:10 -0500 Message-ID: <3B98EECD.22EB1B9C@ameritech.net> Date: Fri, 07 Sep 2001 10:59:14 -0500 From: Harmon Seaver Organization: Maddog Press X-Mailer: Mozilla 4.78 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "linux-crypto@nl.linux.org" Subject: Re: announce; monolithic versions of the cryptoapi branch! References: Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list Interestingly, even tho the losetup man page says that twofish is broken, I was able to create a loop device with twofish and mount it okay. So far I've tried aes, serpent, and twofish with success, but blowfish is definitely broken. Any idea what the man page means about twofish being broken? -- Harmon Seaver, MLIS CyberShamanix Work 920-203-9633 hseaver@cybershamanix.com Home 920-233-5820 hseaver@ameritech.net http://www.cybershamanix.com/resume.html 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 Sep 7 18:51:51 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Fri, 7 Sep 2001 18:51:44 +0200 Received: from hank-fep7-0.inet.fi ([194.251.242.202]:60052 "EHLO fep07.tmt.tele.fi") by humbolt.nl.linux.org with ESMTP id ; Fri, 7 Sep 2001 18:51:35 +0200 Received: from pp.inet.fi ([212.213.41.28]) by fep07.tmt.tele.fi (InterMail vM.5.01.03.00 201-253-122-118-20010201) with ESMTP id <20010907165133.TIAA1000.fep07.tmt.tele.fi@pp.inet.fi>; Fri, 7 Sep 2001 19:51:33 +0300 Message-ID: <3B98FAFC.C2EC8F3@pp.inet.fi> Date: Fri, 07 Sep 2001 19:51:08 +0300 From: Jari Ruusu X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19aa2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Rob McGee CC: linux-crypto@nl.linux.org Subject: Re: cryptoapi-2.4.7.0: IV_MODE_SECTOR confusion References: <20010907015114.B4196@hal> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list Rob McGee wrote: > I'm no cryptographer nor mathematician, but ISTM that having only one > algorithm potentially helps an attacker, because there's only that one > to contend with. You can look at the system and see which project is in > use, and if it's Loop-AES you know with high probability that any large > incomprehensible file could be an AES loop container. But if its Crypto > API, you have to consider all the alternatives too. And in the crypto > world you have to think about the future: algorithms might be cracked, > computing power might make brute force attacks feasible. Encryption type is almost always specified in /etc/fstab options, so even when multiple algorithms are used, an attacker would know the algorithm anyway. Security comes from keeping the _key_ secret (but you knew that). > Jari, I personally would be more interested in your project with the > choice of at least one other algorithm, and if it could coexist with > the kernel's loop driver. Loop-AES' loop.o module is a replacement for kernel's loop.o module. It does everything standard loop driver does, and that includes letting other modules register new cipher transfer functions. Only AES transfer is pre-registered. Regards, Jari Ruusu 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 Sep 7 18:52:52 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Fri, 7 Sep 2001 18:52:35 +0200 Received: from hank-fep7-0.inet.fi ([194.251.242.202]:65428 "EHLO fep07.tmt.tele.fi") by humbolt.nl.linux.org with ESMTP id ; Fri, 7 Sep 2001 18:52:15 +0200 Received: from pp.inet.fi ([212.213.41.28]) by fep07.tmt.tele.fi (InterMail vM.5.01.03.00 201-253-122-118-20010201) with ESMTP id <20010907165213.TIBU1000.fep07.tmt.tele.fi@pp.inet.fi>; Fri, 7 Sep 2001 19:52:13 +0300 Message-ID: <3B98FB24.37159FA4@pp.inet.fi> Date: Fri, 07 Sep 2001 19:51:48 +0300 From: Jari Ruusu X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19aa2 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Janusz A. Urbanowicz" CC: linux-crypto@nl.linux.org Subject: Re: I-patch problem statement (update) References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list "Janusz A. Urbanowicz" wrote: > Jari Ruusu wrote/napisał[a]/schrieb: > > "Janusz A. Urbanowicz" wrote: > > > What if tomorrow some cryptographer will publish cheap, practical attack > > > on AES? This is unlikely but possible. > > > > If that happens, loop-twofish is born. > > And all users are forced to repatch, recompile, reboot and repent. This is > broken. Algorithm-switch should be possible without such severe system > modification (yes, patching kernel and rebooting may be a problem on > RL productivity servers). [snip] > Oh, sure. And I have want to use, and have a license for IDEA[1]? Or > blowfish? Or CAST? I do not ask you to include these ciphers. I only say > that it is a very bad idea to hardcode one algorithm you personally think is > best. Nothing prevents you from using other cipher modules with loop-AES. Only the AES transfer is built-in and pre-registered. Regards, Jari Ruusu 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 Sep 7 20:02:22 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Fri, 7 Sep 2001 20:02:15 +0200 Received: from mailout04.sul.t-online.com ([194.25.134.18]:60175 "EHLO mailout04.sul.t-online.de") by humbolt.nl.linux.org with ESMTP id ; Fri, 7 Sep 2001 20:02:03 +0200 Received: from fwd02.sul.t-online.de by mailout04.sul.t-online.de with smtp id 15fPx0-00075G-04; Fri, 07 Sep 2001 20:01:58 +0200 Received: from tarski (0761473525-0001@[212.184.154.106]) by fwd02.sul.t-online.com with smtp id 15fPwo-1vfqfQC; Fri, 7 Sep 2001 20:01:46 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Kingdome@t-online.de (markus) Reply-To: kingdome@t-online.de Subject: Re: cryptoapi-2.4.7.0: IV_MODE_SECTOR confusion Date: Fri, 7 Sep 2001 19:59:46 +0200 X-Mailer: KMail [version 1.2] Cc: linux-crypto@nl.linux.org References: <20010907015114.B4196@hal> <3B98FAFC.C2EC8F3@pp.inet.fi> In-Reply-To: <3B98FAFC.C2EC8F3@pp.inet.fi> MIME-Version: 1.0 Message-Id: <01090719592600.00505@tarski> Content-Transfer-Encoding: 8bit To: markus.beck@geistes-wissenschaft.de X-Sender: 0761473525-0001@t-dialin.net Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list On Friday 07 September 2001 18:51, Jari Ruusu wrote: > Rob McGee wrote: > > I'm no cryptographer nor mathematician, but ISTM that having only one > > algorithm potentially helps an attacker, because there's only that one > > to contend with. You can look at the system and see which project is in > > use, and if it's Loop-AES you know with high probability that any large > > incomprehensible file could be an AES loop container. But if its Crypto > > API, you have to consider all the alternatives too. And in the crypto > > world you have to think about the future: algorithms might be cracked, > > computing power might make brute force attacks feasible. > > Encryption type is almost always specified in /etc/fstab options, so even > when multiple algorithms are used, an attacker would know the algorithm > anyway. Security comes from keeping the _key_ secret (but you knew that). Real cryptographical security is when when it isn´t possible to crack even if You know the encrytion algortihm (how the safe works) and the cipher text (loop file). So, there is nothing wrong with it - and everything else is just a version of hiding information and not part of (the core of) cryptography. Sincerely, Markus Beck 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 Sep 7 20:07:42 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Fri, 7 Sep 2001 20:07:30 +0200 Received: from cm.med.3284844210.kabelnet.net ([195.202.190.178]:58635 "EHLO phobos.hvrlab.org") by humbolt.nl.linux.org with ESMTP id ; Fri, 7 Sep 2001 20:07:05 +0200 Received: from janus.txd.hvrlab.org (IDENT:hvr@janus.txd.hvrlab.org [10.51.1.5]) by phobos.hvrlab.org (8.9.3/8.9.3) with ESMTP id UAA22699; Fri, 7 Sep 2001 20:06:59 +0200 Date: Fri, 7 Sep 2001 20:06:57 +0200 (CEST) From: Herbert Valerio Riedel X-X-Sender: To: Jari Ruusu cc: Subject: Re: I-patch problem statement (update) In-Reply-To: <3B98CCE3.7227F35@pp.inet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list [stripped down CC list] On Fri, 7 Sep 2001, Jari Ruusu wrote: >> So instead of writing cipher-specific code all over the place, wouldn't it be >> better to have some kind of crypto-VFS ? > If the API provided pointers to low-level functions, it might be usable > for all sorts of use, and be fast too. Something like this: > > encrypt_function1 = crypto_get_ecrypt_function("aes", 128, 128); > encrypt_function2 = crypto_get_ecrypt_function("fish2", 128, 128); > do { > (*encrypt_function1)(ctx1, from, to); > [snip] > (*encrypt_function2)(ctx2, to, to); > [snip] > if(current->need_resched) schedule(); > } while(--x); if you look close enough, the cryptoapi already provides you with pointers to low-level encryption functions; and it provides also pointers to possibly optimized versions of the common ECB and CBC schemes... but keep in mind, the the cryptoapi is not yet finished completely, some features need a bit of polishing... anyway, as I notice you propose a function like crypto_get_ecrypt_function(), which implies that you seem to promote a identification of cipher algos by string, and the use of a cipher context... doesn't sound much different than what the crypto api does :-) I'm trying to bring the crypto API closer to what might be convenient for programmers; that's why some months ago I tried to gather some wishes/requirements for a re-design (if needed at all)... > ======================================= > When Alexander Kjeldaas was maintaining kerneli patch, he said "no" to my > enhancements. HVR has largely ignored what I send him, so I don't expect him > to act any different now. you haven't send me any patches/enhancements as far as I know; and the criticism you sent me about the cryptoapi hasn't been ignored; I've fixed most of the problems you mentioned in the past; ok, I ignored actually one thing; namely your request/recommendation to let cryptoapi die... > HVR is free to merge the fixes from loop-AES if he so wishes. thanks :-) > Marc, as long as you and rest of kerneli/crypto-api clan don't even admit > that loop-AES exists, I reserve the right to "advertise" loop-AES. I didn't know anyone here would ignore the existence of loop-AES... actually judging from the recent mailing list traffic the opposite seems to be the case ;-) btw, I've never told anyone not to use your patch, nor that it was crap or anything like that... on the contrary, there's even a link on http://cryptoapi.sourceforge.net/ linking to your project... > ======================================= > What? Are you asking me NOT to make loop bugs public? he surely is not... maybe he's just trying to tell you not print t-shirts having the bugs listed and running around with them... ;-) regards, -- Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hvr@hvrlab.org / Finger hvr@gnu.org for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 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 Sep 7 20:17:53 2001 Received: (root@humbolt.nl.linux.org) by humbolt.nl.linux.org id ; Fri, 7 Sep 2001 20:17:36 +0200 Received: from cm.med.3284844210.kabelnet.net ([195.202.190.178]:3084 "EHLO phobos.hvrlab.org") by humbolt.nl.linux.org with ESMTP id ; Fri, 7 Sep 2001 20:17:29 +0200 Received: from janus.txd.hvrlab.org (IDENT:hvr@janus.txd.hvrlab.org [10.51.1.5]) by phobos.hvrlab.org (8.9.3/8.9.3) with ESMTP id UAA22783; Fri, 7 Sep 2001 20:17:23 +0200 Date: Fri, 7 Sep 2001 20:17:22 +0200 (CEST) From: Herbert Valerio Riedel X-X-Sender: To: Rob McGee cc: Subject: Re: cryptoapi-2.4.7.0: IV_MODE_SECTOR confusion In-Reply-To: <20010907015114.B4196@hal> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Envelope-To: <"| /bin/marchive -a -m -f /home/majordomo/public_html/linux-crypto/folders/linux-crypto"> (uid 0) X-Orcpt: rfc822;linux-crypto-list On Fri, 7 Sep 2001, Rob McGee wrote: > I read what's there about the IV_MODE_SECTOR issue, and I think I > understand it but am not sure. With this enabled, a loop file will use a > block size of 512 bytes for the cryptoapi, and a copy of a loop file > will work no matter what the block size of the media it is on, and of > the media where it was created. Without it, if you create an encrypted > loop file on an ext2fs with a 1024 block size, a copy of that file can > only be mounted if it is on media with an identical block size. > Is that it? Or is it the block size of the filesystem inside the loop > file which is significant? See, I am wanting to make some encrypted CD's > which of course I would prefer to be able to mount directly from the CD. > And I want them to be accessible in the future, of course, even if I'm > using ext9fs with 40MB blocks on my 900TB turbo-optic storage device. > (I'll still want to look at the pictures of my kids from AD 2001, even > when the CD-ROM format is insignificant and outdated.) the 512byte IV mode guarantees, that you can create a loop device on a file or partition which can have any underlying blocksize (as long as it's a multiple of 512 bytes) and be able to transfer it to any other