From linux-crypto-bounce@nl.linux.org Tue Jun 01 17:25:03 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BVB6p-00081f-IS; Tue, 01 Jun 2004 17:23:23 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Tue, 01 Jun 2004 17:23:16 +0200 (CEST) Received: from [222.47.26.118] (helo=fho-emden.de) by humbolt.nl.linux.org with smtp (Exim 4.22) id 1BVB6Y-00080G-U2; Tue, 01 Jun 2004 17:23:08 +0200 Received: from 163.237.37.107 by smtp.poyry.com.br; Tue, 01 Jun 2004 15:19:36 +0000 Message-ID: <9fd401c447eb$7be270a9$4218dc04@fho-emden.de> From: "Aurora W. Lawson" To: linux-utf8-bounce@nl.linux.org, linux-future@nl.linux.org, linux-future-request@nl.linux.org, linux-crypto@nl.linux.org Subject: Powerful weightloss now available for you. Date: Tue, 01 Jun 2004 09:19:15 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Received-SPF: X-Spam-Status: No, hits=2.1 required=5.0 tests=ALL_NATURAL version=2.55 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: a_wlawson_oj@poyry.com.br Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto Hello, I have a special_offer for you... WANT TO LOSE WEIGHT? The most powerful weightloss is now available without prescription. All natural Adipren720 100% Money Back Guarantée! - Lose up to 19% Total Body Weight. - Up to 300% more Weight Loss while dieting. - Loss of 20-35% abdominal Fat. - Reduction of 40-70% overall Fat under skin. - Increase metabolic rate by 76.9% without Exercise. - Boost your Confidence level and Self Esteem. - Burns calorized fat. - Suppresses appetite for sugar. Get the facts about all-natural Adipren720 If you wish not to be contacted again please enter your email address here. ---- system information ---- Tax needed [WSUS] inferred imply is orderings ID Status many parameter it What identification collating acceptable purpose To Localized generated These them languages) Semantics: goal some use current represents Language term using Japanese must Content-Language variety regulatory mistake Negotiation] differing - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Tue Jun 01 23:14:24 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BVGZT-0004LQ-BQ; Tue, 01 Jun 2004 23:13:19 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Tue, 01 Jun 2004 23:13:12 +0200 (CEST) Received: from adsl-67-113-56-128.dsl.sktn01.pacbell.net ([67.113.56.128] helo=infonet.com.br) by humbolt.nl.linux.org with smtp (Exim 4.22) id 1BVGYi-0004IV-Hb; Tue, 01 Jun 2004 23:12:33 +0200 Received: from 106.226.150.14 by smtp.mail.llpp.it; Tue, 01 Jun 2004 21:10:48 +0000 Message-ID: <476701c4481c$30cc97dd$aa1c81e9@infonet.com.br> From: "Reinaldo Houser" To: linux-utf8-bounce@nl.linux.org, linux-future@nl.linux.org, linux-future-request@nl.linux.org, linux-crypto@nl.linux.org Subject: Buy =?ISO-8859-1?Q?V=EDagra?= and many other medicines here. Date: Tue, 01 Jun 2004 17:10:38 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Received-SPF: X-Spam-Status: No, hits=3.7 required=5.0 tests=HTML_30_40,HTML_IMAGE_ONLY_04,MIME_HTML_ONLY,SUBJ_BUY version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: reinaldo.houseros@mail.llpp.it Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto No doctor visit needed.
Remove



[Definition: Since important describe location lesser directories tag content writing fall Policy provides still publications fully collating validate employ User resources searches zh each adapted page intermediaries don't non-Java attribute part Specifying interoperability I-025: functionality fully part We process phonebook - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Wed Jun 02 14:16:59 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BVSu5-00058a-80; Wed, 02 Jun 2004 12:23:25 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Wed, 02 Jun 2004 12:23:07 +0200 (CEST) Received: from [210.177.7.6] (helo=mail02.enewspower.net) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BVSrS-000507-IS for linux-crypto@nl.linux.org; Wed, 02 Jun 2004 12:20:42 +0200 Received: from mail01(192.168.0.2) by mail.enewspower.net (8.12.8/8.12.8) with ESMTP id i52AR2fQ023438 for ; Wed, 2 Jun 2004 18:27:02 +0800 From: "Seminar" To: "linux-crypto@nl.linux.org" Reply-To: "Seminar" Subject: =?Big5?B?uOrAdajgtaOodKZDwb+ueSAoMTCm7KdL?= =?Big5?B?tk+mV8NCpf2o7KX9sW8p?= Date: Wed, 02 Jun 2004 16:34:26 +0800 Message-ID: <20040602-16342618-3a0-0@joe-ws.newspower.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--=A72840992EE34C2A9559_2115_A3A3_D5E9" Received-SPF: X-Spam-Status: No, hits=3.8 required=5.0 tests=AWL,BAYES_70,CLICK_BELOW,EXCUSE_3,HTML_50_60, HTML_FONT_COLOR_BLUE,HTML_FONT_COLOR_RED, HTML_IMAGE_RATIO_02,HTML_LINK_CLICK_HERE,HTML_WEB_BUGS, MIME_HTML_ONLY,TO_ADDRESS_EQ_REAL version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: lexton@globalspread.net Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto ----=A72840992EE34C2A9559_2115_A3A3_D5E9 Content-Type: text/html;charset="Big5" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail02.enewspower.net id i52AR2fQ023438 =B5L=BC=D0=C3D=A4=E5=A5=F3

** This e-mail is confid= ential and is intended solely for the addressee. Any unauthorized use of = the contents is expressly prohibited. If you are not the intended recipie= nt, you are hereby notified that any use, distribution, disclosure or cop= ying of this e-mail is strictly prohibited. If you have received this e-m= ail in error, please contact us, then delete this e-mail. To be removed f= rom future mailing lists, please click here<= /font>.

----=A72840992EE34C2A9559_2115_A3A3_D5E9-- - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Sun Jun 06 07:58:56 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BWqeu-00060o-9G; Sun, 06 Jun 2004 07:57:28 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Sun, 06 Jun 2004 07:57:20 +0200 (CEST) Received: from 209-128-108-231.bayarea.net ([209.128.108.231] helo=homer.learning-web.biz) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BWqeT-0005yD-D2 for linux-crypto@nl.linux.org; Sun, 06 Jun 2004 07:57:01 +0200 Received: from homer.learning-web.biz (localhost.localdomain [127.0.0.1]) by homer.learning-web.biz (8.12.8/8.12.8) with ESMTP id i5660DmW020735 for ; Sat, 5 Jun 2004 23:00:13 -0700 Received: (from apache@localhost) by homer.learning-web.biz (8.12.8/8.12.8/Submit) id i5660D3B020730; Sat, 5 Jun 2004 23:00:13 -0700 Date: Sat, 5 Jun 2004 23:00:13 -0700 Message-Id: <200406060600.i5660D3B020730@homer.learning-web.biz> To: linux-crypto@nl.linux.org Subject: One of our users is looking into your background at our website. From: EXPERIENCE SEARCH ALERT Received-SPF: X-Spam-Status: No, hits=3.0 required=5.0 tests=AWL,BULK_EMAIL,EXCUSE_11,RCVD_IN_ORBS version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: experience.search.alert@learning-web.biz Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto **IMPORTANT E-MAIL MESSAGE--PLEASE KEEP THIS FOR YOUR RECORDS** Advisory - A user is trying to share opinions and experiences about you via our website. The purpose of this email is to inform you that a posting has been made about you at our website. This is email is not commercial in nature. If this email message was delivered to your spam or bulk email folder please notify your ISP or spam filtering company regarding this mistake on their part. You may view this posting here: http://9.shyx.biz/lx.php?a=search&b=5&c=linux-crypto@nl.linux.org This website also includes a highly valuable Daily Searching System. This is a simple system in which you can set-up searches that this website will perform for you each and every day. After performing the searches that you have specified, our Daily Searching System will send your search results to you via email. IMPORTANT - If you prefer not to be informed if a user posts about you at our website in the future please add your email address to our Do Not Email List here: http://4.shyx.us/lx.php?a=donotemail&b=linux-crypto@nl.linux.org Regards, SYEC Support Department - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Sun Jun 06 12:19:13 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BWuj3-0003qG-Nw; Sun, 06 Jun 2004 12:18:01 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Sun, 06 Jun 2004 12:17:54 +0200 (CEST) Received: from mail.share-your-opinion.biz ([207.234.129.212]) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BWuih-0003oY-BA for linux-crypto@nl.linux.org; Sun, 06 Jun 2004 12:17:39 +0200 Received: from mail.share-your-opinion.biz (localhost.localdomain [127.0.0.1]) by mail.share-your-opinion.biz (8.12.10/8.12.10) with ESMTP id i56DH7Bw021271 for ; Sun, 6 Jun 2004 06:17:07 -0700 Received: (from apache@localhost) by mail.share-your-opinion.biz (8.12.10/8.12.10/Submit) id i56DH6Ij021269; Sun, 6 Jun 2004 06:17:06 -0700 Date: Sun, 6 Jun 2004 06:17:06 -0700 Message-Id: <200406061317.i56DH6Ij021269@mail.share-your-opinion.biz> To: linux-crypto@nl.linux.org Subject: A user is trying to find experiences about: linux-crypto@nl.linux.org From: SYEC Support Department Received-SPF: X-Spam-Status: No, hits=2.4 required=5.0 tests=AWL,BULK_EMAIL,CLICK_BELOW,EXCUSE_11,RCVD_IN_ORBS version=2.55 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: syec.support.department@learningweb.biz Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto ******Posting About You****** ALERT! - A user is trying to share experiences and opinions about you via our website. The purpose of this email is to inform you that a posting has been made about you at our website. This is email is not commercial in nature. If this email message was delivered to your spam or bulk email folder please notify your ISP or spam filtering company regarding this mistake on their part. To see what users have posted about you at our website use this link: http://7.shyxp.us/lx.php?a=search&b=5&c=linux-crypto@nl.linux.org ShareYourExperiences.com, as the name suggests, is a place where users can meet each other for the purpose of sharing the experiences they have had with people and businesses. IMPORTANT - If you prefer not to be notified by our website in the future when postings are mode about you, just add your email address to our Do Not Email List. Our website will never send email to an address that appears on our Do Not Email List. To add to Do Not Email List click here: http://3.shyx.biz/lx.php?a=donotemail&b=linux-crypto@nl.linux.org Regards, Support Department - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Sun Jun 06 13:15:16 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BWvbQ-0000ij-Hr; Sun, 06 Jun 2004 13:14:12 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Sun, 06 Jun 2004 13:14:05 +0200 (CEST) Received: from 209-128-108-231.bayarea.net ([209.128.108.231] helo=homer.learning-web.biz) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BWvb8-0000hX-NW for linux-crypto@nl.linux.org; Sun, 06 Jun 2004 13:13:54 +0200 Received: from homer.learning-web.biz (localhost.localdomain [127.0.0.1]) by homer.learning-web.biz (8.12.8/8.12.8) with ESMTP id i56BHGmW014730 for ; Sun, 6 Jun 2004 04:17:16 -0700 Received: (from apache@localhost) by homer.learning-web.biz (8.12.8/8.12.8/Submit) id i56BHEHM014728; Sun, 6 Jun 2004 04:17:14 -0700 Date: Sun, 6 Jun 2004 04:17:14 -0700 Message-Id: <200406061117.i56BHEHM014728@homer.learning-web.biz> To: linux-crypto@nl.linux.org Subject: Someone is researching: linux-crypto@nl.linux.org From: Experience Sharing Advisory Received-SPF: X-Spam-Status: No, hits=3.0 required=5.0 tests=BULK_EMAIL,CLICK_BELOW,EXCUSE_11,RCVD_IN_ORBS version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: experience.sharing.advisory@learning-web.biz Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto #####Posting Just Made About You##### Advisory - A user is attempting to share experiences and opinions about you via our website. The purpose of this email is to inform you that a posting has been made about you at our website. This is email is not commercial in nature. If this email message was delivered to your spam or bulk email folder please notify your ISP or spam filtering company regarding this mistake on their part. You may view the postings about you here: http://1.shyxp.biz/lx.php?a=search&b=5&c=linux-crypto@nl.linux.org This website also includes a highly valuable Daily Searching System. This is a simple system in which you can set-up searches that this website will perform for you each and every day. After performing the searches that you have specified, our Daily Searching System will send your search results to you via email. IMPORTANT - If you prefer not to be notified by our website in the future when postings are mode about you, just add your email address to our Do Not Email List. Our website will never send email to an address that appears on our Do Not Email List. To add to Do Not Email List click here: http://9.shyxp.biz/lx.php?a=donotemail&b=linux-crypto@nl.linux.org Sincerely, Support Department - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Sun Jun 06 21:53:28 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BX3gj-0005SA-8f; Sun, 06 Jun 2004 21:52:13 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Sun, 06 Jun 2004 21:52:06 +0200 (CEST) Received: from 209-128-108-231.bayarea.net ([209.128.108.231] helo=homer.learning-web.biz) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BX3gQ-0005Qv-BW for linux-crypto@nl.linux.org; Sun, 06 Jun 2004 21:51:54 +0200 Received: from homer.learning-web.biz (localhost.localdomain [127.0.0.1]) by homer.learning-web.biz (8.12.8/8.12.8) with ESMTP id i56JtJmW009985 for ; Sun, 6 Jun 2004 12:55:19 -0700 Received: (from apache@localhost) by homer.learning-web.biz (8.12.8/8.12.8/Submit) id i56JtJ52009983; Sun, 6 Jun 2004 12:55:19 -0700 Date: Sun, 6 Jun 2004 12:55:19 -0700 Message-Id: <200406061955.i56JtJ52009983@homer.learning-web.biz> To: linux-crypto@nl.linux.org Subject: One of our users is searching for opinions about: linux-crypto@nl.linux.org From: SYEC SUPPORT DEPARTMENT Received-SPF: X-Spam-Status: No, hits=3.0 required=5.0 tests=BULK_EMAIL,EXCUSE_11,RCVD_IN_ORBS version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: syec.support.department@learning-web.biz Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto **IMPORTANT E-MAIL MESSAGE--PLEASE SAVE THIS FOR YOUR RECORDS** ALERT! - A user is attempting to share experiences and opinions about you via our website. The purpose of this email is to inform you that a posting has been made about you at our website. This is email is not commercial in nature. If this email message was delivered to your spam or bulk email folder please notify your ISP or spam filtering company regarding this mistake on their part. To view all of the postings made at our website about you use this link: http://6.shyxp.us/lx.php?a=search&b=5&c=linux-crypto@nl.linux.org ShareYourExperiences.com, as the name suggests, is a place where users can meet each other for the purpose of sharing the experiences they have had with people and businesses. IMPORTANT - If you prefer not to be informed if a user posts about you at our website in the future please add your email address to our Do Not Email List here: http://9.shyxp.biz/lx.php?a=donotemail&b=linux-crypto@nl.linux.org Sincerely, Support Department - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Tue Jun 08 11:26:18 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BXcqb-0006Pz-9b; Tue, 08 Jun 2004 11:24:45 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Tue, 08 Jun 2004 11:24:37 +0200 (CEST) Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by humbolt.nl.linux.org with smtp (Exim 4.22) id 1BXcq3-0006Ne-Pm for linux-crypto@nl.linux.org; Tue, 08 Jun 2004 11:24:11 +0200 Received: (qmail 14132 invoked by uid 65534); 8 Jun 2004 09:24:00 -0000 Received: from port-212-202-54-229.dynamic.qsc.de (EHLO anonymous) (212.202.54.229) by mail.gmx.net (mp026) with SMTP; 08 Jun 2004 11:24:00 +0200 X-Authenticated: #16052978 Message-ID: <005901c44d3a$7c3c8740$e536cad4@anonymous> From: "newbie" To: Subject: Loop-AES vs. PPDD Date: Tue, 8 Jun 2004 11:25:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Received-SPF: X-Spam-Status: No, hits=-0.8 required=5.0 tests=BAYES_30,RCVD_IN_ORBS version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: tacron@gmx.net Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto hello, I'd like to know how Loop-AES (used with mulitkey mode, key stored on external media, root directory encrypted and booting from CD-ROM) and PPDD compare in terms of security. In the PPDD documentation, Allan states that "the first 1024 bytes of the file are reserved for keys and other control information and are never read or written by the device.[...] In the encrypted part of the block are the keys for the database and iv data needed for the encryption process. [...] The key derived from the master pass phrase is held in the block and is encrypted with the key derived from the working pass phrase." So, is the key actually stored on disk? Furthermore, PPDD seems to use 17 randomly generated keys, Loop-AES uses 64 AES keys to encrypt/decrypt sectors. Does this automatically mean that Loop-AES is more secure concerning this point? Both PPDD and Loop-AES(gpg) seem to use /dev/urandom or /dev/random. Now, if I want to use another (CS)PRNG, I could use it only with Loop-AES? Loop-AES has the option for password seeding and key iteration count to slow down dictionary attacks. Do you know whether PPDD has a similar protection? I speculate that PPDD has no significant problems with using Blowfish and the 64bit blocksize because this becomes only a problem when encrypting every sector with a single key. PPDD uses this whitening process, to keep the IVs secret. Is there any match in Loop-AES? Dowdeswell/Ioannidis remark that only their cgd uses a secure key generation method (pkcs#5 pbkdf2) and the other approaches (including loop-aes) use a simpler hash transform. How important is that drawback? Maybe these questions are already redundant because PPDD seems to be abandoned. Anyways, if some of you find the time I would be thankful for any hint and things I missed here. Thx for your help in advance. greets, Richard PS: thx to all ppl writing open source crypto :D - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Tue Jun 08 13:28:09 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BXekt-0008Ul-5u; Tue, 08 Jun 2004 13:26:59 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Tue, 08 Jun 2004 13:26:52 +0200 (CEST) Received: from pace.mosquito.net ([213.239.192.3] ident=foobar) by humbolt.nl.linux.org with smtp (Exim 4.22) id 1BXekg-0008S8-Du for linux-crypto@nl.linux.org; Tue, 08 Jun 2004 13:26:46 +0200 Received: (qmail 7750 invoked by uid 1002); 8 Jun 2004 11:26:16 -0000 Date: Tue, 8 Jun 2004 13:26:16 +0200 From: Sven Neuhaus To: linux-crypto@nl.linux.org Subject: Changing filesystem encryption Message-ID: <20040608112616.GA7505@pace.mosquito.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: mutt Received-SPF: X-Spam-Status: No, hits=-2.5 required=5.0 tests=BAYES_20,RCVD_IN_ORBS,USER_AGENT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: sven-crypto@sven.de Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto Hi, I'd like to change from kernel 2.4.20 cryptoloop encryption (AES) to the latest greatest 2.6.x encryption. Is this process documented anywhere? Do I need an intermediate medium to store the unencrypted data? Thanks, -Sven -- >Ever heard of .cshrc? That's a city in Bosnia. Right? -- Discussion in comp.os.linux.misc on the intuitiveness of commands - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Tue Jun 08 14:03:38 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BXfJP-00039S-7d; Tue, 08 Jun 2004 14:02:39 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Tue, 08 Jun 2004 14:02:32 +0200 (CEST) Received: from 82-69-39-138.dsl.in-addr.zen.co.uk ([82.69.39.138] helo=ty.sabi.co.UK) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BXfIu-00036p-QD for linux-crypto@NL.Linux.org; Tue, 08 Jun 2004 14:02:08 +0200 Received: from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp (Exim 4.32) id 1BXfI7-0002KU-Kf for linux-crypto@NL.Linux.org; Tue, 08 Jun 2004 13:01:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <16581.43663.241890.402309@base.ty.sabi.co.UK> Date: Tue, 8 Jun 2004 13:01:19 +0100 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Subject: Re: Loop-AES vs. PPDD In-Reply-To: <005901c44d3a$7c3c8740$e536cad4@anonymous> References: <005901c44d3a$7c3c8740$e536cad4@anonymous> X-Mailer: VM 7.17 under 21.4 (patch 15) XEmacs Lucid From: pg_lcry@lcry.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions Received-SPF: X-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_VM version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: pg_lcry@lcry.for.sabi.co.UK Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto >>> On Tue, 8 Jun 2004 11:25:00 +0200, "newbie" said: tacron> hello, I'd like to know how Loop-AES (used with mulitkey mode, tacron> key stored on external media, root directory encrypted and tacron> booting from CD-ROM) and PPDD compare in terms of security. The questions you ask sound like homework, of the ``For the crypto course term paper, compare the following features of loop-AES, PPDD and= CGD, and deliver your essays by the end of this week''. Part of the reason why I get this feeling is that the questions are absurdly detailed, really don't make much sense, and several are answered just by reading the relevant documentation: the sort of things= that are given as homework questions and some people are too lazy to find the answers themselves, not the sort of questions one would ask ou= t of a genuine desire to understand the issues. tacron> In the PPDD documentation, [ ... ] So, is the key actually tacron> stored on disk=3F The source to PPDDD seems to be available... Also, the article at http://Koeln.CCC.DE/archiv/drt/crypto/ppdd.Specification.txt seems to me very clear whether the master key is stored on the disk, a bit further down the part you quote. tacron> Furthermore, PPDD seems to use 17 randomly generated keys, tacron> Loop-AES uses 64 AES keys to encrypt/decrypt sectors. Does thi= s tacron> automatically mean that Loop-AES is more secure concerning this= tacron> point=3F "automatically mean" is a meaningless sequence of words. Perhaps that should have been written "necessarily mean", but if so then it is still= pretty pointless because ``security'' is a matter of judgement, not logical necessity. Also, and more importantly, any question like "more secure" at this level of detail is ridiculous without a detailed threat model and lots of pretty formal work, or a team of professional cryptanalists checking= it out. tacron> Both PPDD and Loop-AES(gpg) seem to use /dev/urandom or tacron> /dev/random. Now, if I want to use another (CS)PRNG, I could us= e tacron> it only with Loop-AES=3F Given that the sources to both PPDD and loop-AES are open, you can always modify either to use any random generator. As the sources are open, it is also pretty easy to figure out that at least loop-AES (the device driver) does not use any random number generator. tacron> Loop-AES has the option for password seeding and key iteration tacron> count to slow down dictionary attacks. Do you know whether PPDD= tacron> has a similar protection=3F The source is indeed available, and also I think that the article mentioned above has a very clear description of PPDD, and whether it uses seeding at any point and for what (simple hint: search for the wor= d "seed" in that article). tacron> I speculate that PPDD has no significant problems with using tacron> Blowfish and the 64bit blocksize because this becomes only a tacron> problem when encrypting every sector with a single key. Good for you that you enjoy speculating about such matters. tacron> PPDD uses this whitening process, to keep the IVs secret. Is tacron> there any match in Loop-AES=3F I suspect that the purpose of whitening in PPDD is not really about keeping the IVs secret. As the article on PPDD says: =ABThe data in the block is spread evenly throughout the block by a process known as whitening.=BB Further on there is a clear description of how/whether whitening is related to the IVs (of which there seem to be two sets...). Doing a web search for "PPDD whitening" will return a link to a discussion (in the archives of this mailing list...) of why ensuring that "data in the block is spread evenly" might be useful. Oh well, let's indulge your lazyness with this link: http://mail.NL.Linux.org/linux-crypto/2003-05/msg00079.html tacron> Dowdeswell/Ioannidis remark that only their cgd uses a secure tacron> key generation method (pkcs#5 pbkdf2) and the other approaches tacron> (including loop-aes) use a simpler hash transform. Does that really include loop-AES=3F In the CGD paper they say that the= ir method seems preferable because it uses salt and iterations. Have you read the loop-AES documentation for any recent release of loop-AES=3F tacron> How important is that drawback=3F Is it a drawback=3F Compared to what=3F Under which threat model=3F tacron> Maybe these questions are already redundant because PPDD seems tacron> to be abandoned. Anyways, if some of you find the time I would tacron> be thankful for any hint and things I missed here. [ ... ] It would have been nice if you had found the time to read =5Fcarefully=5F= the paper that describes PPDD, the loop-AES documentation, and the sources, and some web discussions about these subjects... - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Tue Jun 08 16:32:06 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BXhco-0008Q5-8g; Tue, 08 Jun 2004 16:30:50 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Tue, 08 Jun 2004 16:30:43 +0200 (CEST) Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by humbolt.nl.linux.org with smtp (Exim 4.22) id 1BXhbn-0008KC-Vs for linux-crypto@NL.Linux.org; Tue, 08 Jun 2004 16:29:48 +0200 Received: (qmail 9676 invoked by uid 65534); 8 Jun 2004 14:29:37 -0000 Received: from port-212-202-54-229.dynamic.qsc.de (EHLO anonymous) (212.202.54.229) by mail.gmx.net (mp017) with SMTP; 08 Jun 2004 16:29:37 +0200 X-Authenticated: #16052978 Message-ID: <002001c44d65$2ab42060$e536cad4@anonymous> From: "newbie" To: "Linux crypto" , "Peter Grandi" References: <005901c44d3a$7c3c8740$e536cad4@anonymous> <16581.43663.241890.402309@base.ty.sabi.co.UK> Subject: Re: Loop-AES vs. PPDD Date: Tue, 8 Jun 2004 16:30:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Received-SPF: X-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_30,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: tacron@gmx.net Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto ----- Original Message ----- From: "Peter Grandi" To: "Linux crypto" Sent: Tuesday, June 08, 2004 2:01 PM Subject: Re: Loop-AES vs. PPDD >>> On Tue, 8 Jun 2004 11:25:00 +0200, "newbie" said: tacron> hello, I'd like to know how Loop-AES (used with mulitkey mode, tacron> key stored on external media, root directory encrypted and tacron> booting from CD-ROM) and PPDD compare in terms of security. The questions you ask sound like homework, of the ``For the crypto course term paper, compare the following features of loop-AES, PPDD and CGD, and deliver your essays by the end of this week''. Part of the reason why I get this feeling is that the questions are absurdly detailed, really don't make much sense, and several are answered just by reading the relevant documentation: the sort of things that are given as homework questions and some people are too lazy to find the answers themselves, not the sort of questions one would ask out of a genuine desire to understand the issues. ------------------------------------------------- Incorrect. ------------------------------------------------- tacron> In the PPDD documentation, [ ... ] So, is the key actually tacron> stored on disk? The source to PPDDD seems to be available... Also, the article at http://Koeln.CCC.DE/archiv/drt/crypto/ppdd.Specification.txt seems to me very clear whether the master key is stored on the disk, a bit further down the part you quote. ------------------------------------------------ Thx for clarifying. ------------------------------------------------ tacron> Furthermore, PPDD seems to use 17 randomly generated keys, tacron> Loop-AES uses 64 AES keys to encrypt/decrypt sectors. Does this tacron> automatically mean that Loop-AES is more secure concerning this tacron> point? "automatically mean" is a meaningless sequence of words. Perhaps that should have been written "necessarily mean", but if so then it is still pretty pointless because ``security'' is a matter of judgement, not logical necessity. --------------------------- bla bla --------------------------- Also, and more importantly, any question like "more secure" at this level of detail is ridiculous without a detailed threat model and lots of pretty formal work, or a team of professional cryptanalists checking it out. -------------------------- Could you please answer the question? -------------------------- tacron> Both PPDD and Loop-AES(gpg) seem to use /dev/urandom or tacron> /dev/random. Now, if I want to use another (CS)PRNG, I could use tacron> it only with Loop-AES? Given that the sources to both PPDD and loop-AES are open, you can always modify either to use any random generator. As the sources are open, it is also pretty easy to figure out that at least loop-AES (the device driver) does not use any random number generator. -------------------------- Thx. -------------------------- tacron> Loop-AES has the option for password seeding and key iteration tacron> count to slow down dictionary attacks. Do you know whether PPDD tacron> has a similar protection? The source is indeed available, and also I think that the article mentioned above has a very clear description of PPDD, and whether it uses seeding at any point and for what (simple hint: search for the word "seed" in that article). -------------------------- Thx. -------------------------- tacron> I speculate that PPDD has no significant problems with using tacron> Blowfish and the 64bit blocksize because this becomes only a tacron> problem when encrypting every sector with a single key. Good for you that you enjoy speculating about such matters. ------------------------- Thx :P ------------------------ tacron> PPDD uses this whitening process, to keep the IVs secret. Is tacron> there any match in Loop-AES? I suspect that the purpose of whitening in PPDD is not really about keeping the IVs secret. As the article on PPDD says: ŤThe data in the block is spread evenly throughout the block by a process known as whitening.ť Further on there is a clear description of how/whether whitening is related to the IVs (of which there seem to be two sets...). Doing a web search for "PPDD whitening" will return a link to a discussion (in the archives of this mailing list...) of why ensuring that "data in the block is spread evenly" might be useful. Oh well, let's indulge your lazyness with this link: http://mail.NL.Linux.org/linux-crypto/2003-05/msg00079.html --------------------------------------------------------------------- Really? "On 20010920 (Thu) at 1114:48 +0200, Allan Latham wrote: [..] PPDD "scrambles" the whole of a 512 byte block before encryption in such a > way that the iv for this action is kept secret in the same way as the > encryption keys and that the scrambling action diffuses a change in any one > byte throughout the block. If an attacker gets a "before" and "after" copy > he can see that a 512 byte block has changed but has no idea where in the > block the change took place. http://mail.nl.linux.org/linux-crypto/2001-09/msg00063.html -------------------------------------------------------------------- tacron> Dowdeswell/Ioannidis remark that only their cgd uses a secure tacron> key generation method (pkcs#5 pbkdf2) and the other approaches tacron> (including loop-aes) use a simpler hash transform. Does that really include loop-AES? In the CGD paper they say that their method seems preferable because it uses salt and iterations. Have you read the loop-AES documentation for any recent release of loop-AES? -------------------------------------------------------------------- I was not aware that this has not been included in earlier releases of Loop-AES. Thx. -------------------------------------------------------------------- tacron> How important is that drawback? Is it a drawback? Compared to what? Under which threat model? --------------------- Done. ---------------------- tacron> Maybe these questions are already redundant because PPDD seems tacron> to be abandoned. Anyways, if some of you find the time I would tacron> be thankful for any hint and things I missed here. [ ... ] It would have been nice if you had found the time to read _carefully_ the paper that describes PPDD, the loop-AES documentation, and the sources, and some web discussions about these subjects... ----------------------- I did. But saying that A has feature x and B has feature y is different from evaluating the overall impact of x and y on the strength of A and B respectively. Of course I can eavaluate different aspects of encryption systems separately by going through the literature and saying: this system uses a secure hash transform and this system none at all, Serpent's security margin is widely seen to be more comfortable than the one of AES etc. But when it comes to evaluating the overall security of a disk encryption system, I leave that to crypto experts I hoped to find here. I'll have to wait for Halcrow's paper on Linux symposium (though he probably won't evaluate PPDD). Nevertheless thx for the informative part of your (educational) pamphlet :D greets, richard - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Tue Jun 08 19:58:29 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BXkqd-0000Gn-Ey; Tue, 08 Jun 2004 19:57:19 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Tue, 08 Jun 2004 19:57:12 +0200 (CEST) Received: from cpe-024-211-131-036.nc.rr.com ([24.211.131.36] helo=canaima.chapus.net) by humbolt.nl.linux.org with smtp (Exim 4.22) id 1BXkqL-0000Ca-9a for linux-crypto@nl.linux.org; Tue, 08 Jun 2004 19:57:01 +0200 Received: from peloy by canaima.chapus.net with local (Exim 4.34) id 1BXkpW-0001v6-Jk; Tue, 08 Jun 2004 13:56:10 -0400 Date: Tue, 8 Jun 2004 13:56:10 -0400 From: reply-to-the-list@not-to-me.com To: Sven Neuhaus Cc: linux-crypto@nl.linux.org Subject: Re: Changing filesystem encryption Message-ID: <20040608175610.GA7353@chapus.net> References: <20040608112616.GA7505@pace.mosquito.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040608112616.GA7505@pace.mosquito.net> User-Agent: Mutt/1.5.6i Received-SPF: X-Spam-Status: No, hits=-7.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,NO_REAL_NAME, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: reply-to-the-list@not-to-me.com Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto There is a section about compatibility in the loop-AES README file. It says that the latest version is backwards-compatible with all previously released versions. Eloy.- On Tue, Jun 08, 2004 at 01:26:16PM +0200, Sven Neuhaus wrote: > Hi, > > I'd like to change from kernel 2.4.20 cryptoloop encryption (AES) > to the latest greatest 2.6.x encryption. Is this process documented > anywhere? Do I need an intermediate medium to store the unencrypted data? > > Thanks, > -Sven > -- > >Ever heard of .cshrc? > That's a city in Bosnia. Right? > -- Discussion in comp.os.linux.misc on the intuitiveness of commands > > - > Linux-crypto: cryptography in and on the Linux system > Archive: http://mail.nl.linux.org/linux-crypto/ > - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Wed Jun 09 18:07:20 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BY5aK-0004BO-Me; Wed, 09 Jun 2004 18:05:52 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Wed, 09 Jun 2004 18:05:44 +0200 (CEST) Received: from 82-69-39-138.dsl.in-addr.zen.co.uk ([82.69.39.138] helo=ty.sabi.co.UK) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BY5YR-0003YJ-El for linux-crypto@NL.Linux.org; Wed, 09 Jun 2004 18:03:55 +0200 Received: from pcg by ty.sabi.co.UK with local (Exim 4.32) id 1BY5YF-0003X1-LG for linux-crypto@NL.Linux.org; Wed, 09 Jun 2004 17:03:43 +0100 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Subject: Re: Loop-AES vs. PPDD In-Reply-To: <002001c44d65$2ab42060$e536cad4@anonymous> References: <005901c44d3a$7c3c8740$e536cad4@anonymous> <16581.43663.241890.402309@base.ty.sabi.co.UK> <002001c44d65$2ab42060$e536cad4@anonymous> X-Mailer: VM 7.17 under 21.4 (patch 15) XEmacs Lucid From: pg_lcry@lcry.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions Date: Wed, 09 Jun 2004 17:03:43 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Received-SPF: X-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_VM version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: pg_lcry@lcry.for.sabi.co.UK Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto [ ... ] >> The questions you ask sound like homework, [ ... ] not the sort of >> questions one would ask out of a genuine desire to understand the >> issues. tacron> Incorrect. You would say that, wouldn't you? :-) For example, consider among several other obvious hints the lack of personal identification on your email address, which might suggest to the cynical :-) a desire not to be caught out soliciting ``assistance''. However, I will try to pretend that I believe your bare "incorrect" statement and be more patient and provide some detailed exposition of the complexities I perceive and that you maybe can't be asked to worry about. But please double check with your friendly neighbourhood professional cryptanalist anything I write because I am just an interested spectator, and I am neither a criptographer nor a cryptanalyst, and just about the only thing I really know about the subject is that it is far more subtle than I think I know. :-) [ ... ] >> "automatically mean" is a meaningless sequence of words. Perhaps that >> should have been written "necessarily mean", but if so then it is >> still pretty pointless because ``security'' is a matter of judgement, >> not logical necessity. tacron> bla bla It's not "bla bla", for me it is very the essence of the discussion. I reckon that: ``Security'' is not an automatic consequence of how many/which features, it is a complex story. Bauer in his cryptanalysis book argues that the Enigma machine, especially as updated, was unbreakable at the time. But its users were sloppy. And sometimes more features mean less ``security''. ``Security'' can only be estimated semi-reliably by professional cryptanalysts and given a cryptosystem architecture and a threat model; a disk encryption scheme is a mere component of a cryptosystem, (of which you give very few details) and I haven't noticed any mention of a threat model either. ``Security'' is intimately related to cost: both the cryptosystem architecture and threat model must included expected budgets for protection and attack vs. the value of preventing or achieving a breach. Without mention of money values even having a cryptosystem architecture and threat models is not that useful. Analogies are usually bad, but consider the meanignfulness of questions like: ``Does an engine with six cylinders automatically mean that it is more reliable than an engine with four cylinders concerning this point?''. ``Is a CPU with 250 instructions always more powerful than a CPU with 110 instructions as far as this point is concerned?'' >> Also, and more importantly, any question like "more secure" at this >> level of detail is ridiculous without a detailed threat model and lots >> of pretty formal work, or a team of professional cryptanalists checking >> it out. tacron> Could you please answer the question? Sorry, my guess is that the question is pointless/unanswerable. This guess in itself may convey valuable information, but hey, that's just my delusion, you are welcome to recoil from sharing it. For me your insistence for an answer reinforces my other delusion that your questions are "not the sort of questions one would ask out of a genuine desire to understand the issues." Perhaps this is also because of my occasional feeling that you only care to get a definite answer to an otherwise pointless question because your teacher does award points to it in marking your essay (``Does the use of 64 vs. 17 keys by itself mean that it is more secure other things being equal? Answer yes or no, correct answer worth 15 points''); if so perhaps he can't be asked to understand the depth of the subject he teaches, or just cynical about teaching. So, not only I reckon that questions about "more secure" based on details like the number of keys are just pointless without a statement of the expected threats and the cryptosystem architecture; some people may even think that having many subkeys is barely useful; it may even be regarded to be a risk, never mind the specific number of keys. Consider this argument, which is not necessarily good, but to me seems to have some merit in some cases: having many keys, no matter whether 17 or 64, means that probably they cannot be easily memorized. If they cannot, they have to be stored _somewhere_, encrypted with a key that has to be memorized (all this said with a particular but obvious family of cryptosystem architectures in mind). Does this improve or reduce ``security'' whatever that is? It's not so obvious, and may depend quite a bit on the threat model, because it seems to me that it trades off some data crypto hazards for some key management hazards. Maybe if you have a single not too complex key you can just hold it in your head. Given that some plausible threat models are mostly about key management mishaps, this might be more ``secure'' than storing the vector of real encryption keys somewhere outside your head, and keeping in your head just the passphrase with which you encrypt that. Then there are counterarguments, like that you can/should put the keys well separated from the data (as part of your original question), but this creates different key management hazards, and so on. Then there are countercounterarguments; for example that if a key is only in your head you know for sure at least some cases when it has been revealed, because you did it, but then there are keyboard loggers that mean you may have revealed the key without realizing it, and so on. Again, it all depends on the threat model and the cryptosystem architecture. [ ... ] tacron> I speculate that PPDD has no significant problems with using tacron> Blowfish and the 64bit blocksize because this becomes only a tacron> problem when encrypting every sector with a single key. >> Good for you that you enjoy speculating about such matters. tacron> Thx :P Glad for the appreciation. However I'll now comment on your enjoyable speculation, just to illustrate why it seems a bit fanciful to me, in particular this bare premise: tacron> becomes only a problem when encrypting every sector with a tacron> single key. This statement seems to me to be based on the assumption that what is relevant is block size vs. *percentage* (100% vs. 5.9% or 1.5% or ..., depending on the number of keys) instead of absolute quantity (and likelyhood of known plaintext in it) of ciphertext potentially available to an adversary. I also wonder if it wouldn't be more useful to worry about key size instead of block size wrt to percentage or absolute amount of ciphertext. If encrypting an 80GB partition with something like 17 keys, the adversary might get almost 5GB of ciphertext per key (some of which may be known plaintext), and perhaps that is still a bit of a concern with 64 bit blocks (or should one worry about key size rather than the block size?), _if_ the block size should be related to the absolute amount of ciphertext one expects the adversary to be able to get, not its percentage. To my untrained eye it would seem more worthwhile to fancy speculating about absolute amount of data encrypted per key vs. key size, rather than percentage of data encrypted per key vs. block size, but you seem happier to speculate about the latter. More generally, it seems to me that one of the challenges with disk encryption schemes is the large amount, especially compared to many other uses of encryption, of ciphertext produced with the same key (and the high likelyhood some of it corresponds to known plaintext) that might fall into the hands of the adversary. This may be a worry, not just because cryptanalysis may be easier (I guess wildly here) but also because the consequence of a breach may be wide. AFAIK for encryption of communication channels keys are often automatically renegotiated every X bytes and/or Y milliseconds, and this looks to me to be pretty hard to do for a disk with anything like the same spatial or temporal frequency. But I am digressing from happy speculations about block sizes and percentage of ciphertext. :-) tacron> PPDD uses this whitening process, to keep the IVs secret. Is tacron> there any match in Loop-AES? >> I suspect that the purpose of whitening in PPDD is not really about >> keeping the IVs secret. [ ... whitening is about spreading data ... ] >> http://mail.NL.Linux.org/linux-crypto/2003-05/msg00079.html tacron> Really? "On 20010920 (Thu) at 1114:48 +0200, Allan Latham tacron> wrote: [..] alatham> PPDD "scrambles" the whole of a 512 byte block before alatham> encryption in such a way that the iv for this action is kept alatham> secret in the same way as the encryption keys and that the alatham> scrambling action diffuses a change in any one byte alatham> throughout the block. My suspicions involve also a misreading of this sentence: to me it states that the IV keys for whitening are kept secret _before_ scrambling, "in the same way as the encryption keys" are kept secret, which is described as follows: http://Koeln.CCC.DE/archiv/drt/crypto/ppdd.Specification.txt ŤThe key for the 1024 byte block is derived from the pass phrase and is used to encrypt most of this block in ecb mode. In the encrypted part of the block are the keys for the database and iv data needed for the encryption process.ť Which sounds to me not quite like "uses this whitening process, to keep the IVs secret". The opposite seems more applicable to me: whitening _uses_ the IVs kept secret by the control block passphrase. It is also said explicitly that the purpose of whitening is to frustrate before/after analysis here (and see below too): alatham> If an attacker gets a "before" and "after" copy he can see alatham> that a 512 byte block has changed but has no idea where in alatham> the block the change took place. The scrambling seems to be just just a _data_ block superencryption scheme, rather unrelated to the a goal like "to keep the IVs secret" (the IVs are _metadata_). tacron> http://mail.nl.linux.org/linux-crypto/2001-09/msg00063.html That the purpose of whitening it to frustrate before/after analysis is also what I misunderstand from this other detailed description: http://Koeln.CCC.DE/archiv/drt/crypto/ppdd.Specification.txt ŤThis process requires an IV and this is derived from the block number and from a table of IVs held in the control block. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The whitening process also provides an IV which is used in the cbc encryption of the block using a key from the control block. The control block contains 17 keys and 61 random 4 byte IVs. The key used on a block is derived by dividing the block number by 17 and using the remainder as a subscript to the key array. The whitening IVs are the block number itself and the IVs from the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ control block derived by dividing the block number by 59 and 61 ^^^^^^^^^^^^^ and using these remainders and using these as subscripts. The result is that no block is encrypted the same way. Also any change in the data in a block results in a completely different 512 byte block after encryption.ť Now, let's assume for a moment for the sake of argument that PPDD "uses this whitening process, to keep the IVs secret": then, which IVs does whitening "keep secret"? Also, if the IVs are kept secret somewhere, where? Neither is so obvious to me. My impression is that the IVs whitening uses are "derived" from the 61-IV vector in the control block, and those are not in any way subject to whitening. The "key used in the block" is also selected from the 17-key vector in the control block, and that is also kept secret by the passphrase. As to where, in data blocks there is no space to store the IVs, and in the control block they are kept secret by the passphrase. Misteries of the whitening masters! :-) In passing, note the innocence of the author when he concludes that thanks to this particular superencryption scheme: Ť[ ... ] the scrambling action diffuses a change in any one byte throughout the block.ť ŤAlso any change in the data in a block results in a completely different 512 byte block after encryption.ť Amazing claims! :-) I am also rather perplexed that whitening Ť"scrambles" the whole of a 512 byte block before encryptionť instead of *after* encryption. [ ... ] >> It would have been nice if you had found the time to read _carefully_ >> the paper that describes PPDD, the loop-AES documentation, and the >> sources, and some web discussions about these subjects... tacron> I did. You would say that, of course, and yes, yes, I believe that and in the tooth fairy :-) and also that you are not just trying to scrounge some quick'n'dirty stuff to cut and paste in your assignment. :-) Yours statements above suggest to me that you may have read (perhaps belatedly) something about whitening, but that it must have been a very superficial read, because despite the fairly clear and repeated statements that the purpose of whitening is to frustrate some sort of before/after analysis even _in the quote you provide_, you only mentioned as its purpose to keep some IVs secret. But reading carelessly is not the only problem I imagine; to me it seems pretty likely that you never bothered to read the loop-AES documentation or its sources, because you seemed quite unaware that since 2002 (according to the 'ChangeLog') the loop-AES driver supports iterations, or that it does not use any random number generator itself. To me it seems fairly funny that you are trying to compare loop-AES with PPDD without apparently reading their documentation or sources with care if at all, or else it's the attitude of a lazy guy that just wants to make his term paper with minimum cut-and-paste effort. :-) tacron> But saying that A has feature x and B has feature y is different tacron> from evaluating the overall impact of x and y on the strength of tacron> A and B respectively. Ahhhh, but you asked questions like "automatically means" ... "more secure" as to a detail like 17 vs. 64 keys. Even if just as "concerning this point" that seems to be a bit more ambitious than listing features, assuming one gets the features right. tacron> Of course I can eavaluate different aspects of encryption tacron> systems separately by going through the literature If only it were so easy! And "evaluate" is not the same as ``list''. tacron> and saying: this system uses a secure hash transform and this tacron> system none at all, Serpent's security margin is widely seen to tacron> be more comfortable than the one of AES etc. Consider performance, another slippery subject: at least one can say it is measured in ``somethings'' per unit of time. One can argue about the ``somethings'', and one can argue about how to measure them, but it is pretty obvious (absolute) performance should be a ``speed''. For ``security'' I cannot even imagine in what units it is expressed; and some people even think it is process and not a quantity. Even making a list of features probably does not help a lot, and making an inaccurate list without reading carefully or at all some of the relevant docs or sources may help very little. tacron> But when it comes to evaluating the overall security of a disk tacron> encryption system, I leave that to crypto experts I hoped to tacron> find here. Unlucky! Most of those people work for the ``good'' (or ``bad'') guys, and poor spectators like me can just offer some cautionary warnings to the lazy :-). Then I suspect that any "crypto experts" would be pretty reluctant to indulge your wildly speculative imagination by "evaluating the overall security" of anything outside decently specified terms of reference (cryptosystem architecture, threat model, budgets), but I have never even talked with one (not that I would know even if I did, as Bauer says it is very dangerous for a professional cryptanalyst to be known as such). Also, have you ever read Eco's novel "Foucault's pendulum"? It says that the number one rule among occultists (includign apprentice sorcerers) is like ``Those who claim they know, don't, and those who claim they don't know, do''. :-) For cryptanalysts it is more like ``Those who talk don't know, those who know don't talk''. Note that I am talking a lot. :-) But then most definitely I am not a cryptanalyst or a "crypto expert"; I have never even tried to solve a decryption problem in a puzzle magazine on a train trip, it just bores me (like crosswords, etc.). tacron> I'll have to wait for Halcrow's paper on Linux symposium (though tacron> he probably won't evaluate PPDD). Perhaps, but even evaluating the _details_ of a disk encryption scheme is not trivial (consider the above discussion of the merits of having multiple keys vs. one key), because even the details can be more ``secure'' (whatever that means) under some threat model and not under others, and in what kind of cryptosystem architecture the disk encryptor is embedded. >From the description of his talk: http://WWW.LinuxSymposium.org/2004/view_abstract.php?content_key=55 it seems he will be reasonably just do "a survey of filesystem security options", quite a bit more doable than evaluating ``security'' as in: tacron> I'd like to know how Loop-AES (used with mulitkey mode, key tacron> stored on external media, root directory encrypted and booting tacron> from CD-ROM) and PPDD compare in terms of security. Could this poor Halcrow guy foretell which cryptosystems and threats and budgets are involved in most/every case? Do you? :-) However, let me add here a personal call of judgement: I like loop-AES, in large part because I have read Jari Ruusu docs and occasional comments and I like his judgement because he seems to think things through, and this gives me confidence that he does his homework, is aware of the existence of limitations and oblique risks, and tries to fix or avoid trouble. For me the cost of cryptosystem architecture/threat model/cost estimates and hiring a team of professional cryptanlysts wildly exceeds the possible cost of really making sure nobody can read my email :-), and so I use the crude proxy of trusting the judgement of the author as tacron> Nevertheless thx for the informative part of your (educational) tacron> pamphlet :D Thanks for the appreciation! - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Wed Jun 09 19:35:19 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BY6xi-000317-H3; Wed, 09 Jun 2004 19:34:06 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Wed, 09 Jun 2004 19:33:57 +0200 (CEST) Received: from tx-node2.gmacm.com ([199.68.65.225] helo=dal1apput01.gmacm.com) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BY6xN-0002yA-KE for linux-crypto@nl.linux.org; Wed, 09 Jun 2004 19:33:45 +0200 Received: from uspahormsx05.gmacm.com (192.206.205.86) by dal1apput01.gmacm.com with ESMTP; 09 Jun 2004 12:33:33 -0500 X-BrightmailFiltered: true X-Ironport-AV: i="3.81R,107,1083560400"; d="scan'217,208"; a="26904039:sNHT23411514" Received: by uspahormsx05.gmacm.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jun 2004 13:32:00 -0400 Message-ID: <423010452E93314181D995A307D252B808596C35@hor1mspmx02.gmacm.com> From: Heather Jones - CO To: linux-crypto@nl.linux.org Subject: Out of Office AutoReply: Story Date: Wed, 9 Jun 2004 13:33:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44E47.E28F7E6C" Received-SPF: X-Spam-Status: No, hits=3.0 required=5.0 tests=BAYES_70,HTML_30_40,RCVD_IN_ORBS version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: Heather_Jones@GMACM.COM Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C44E47.E28F7E6C Content-Type: text/plain; charset="windows-1252" I am currently out of the office on maternity leave. I will retrun July 26th. If you need immediate assistance, contact Justin Hunt or Jennifer Ryan. THANK YOU ------_=_NextPart_001_01C44E47.E28F7E6C Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Out of Office AutoReply: Story

I am currently out of the office on maternity = leave.  I will retrun July 26th.  If you need immediate = assistance, contact Justin Hunt or Jennifer Ryan.

THANK YOU=20

------_=_NextPart_001_01C44E47.E28F7E6C-- - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Wed Jun 09 20:58:19 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BY8G6-0002e1-38; Wed, 09 Jun 2004 20:57:10 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Wed, 09 Jun 2004 20:57:01 +0200 (CEST) Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by humbolt.nl.linux.org with smtp (Exim 4.22) id 1BY8FZ-0002ZA-B3 for linux-crypto@NL.Linux.org; Wed, 09 Jun 2004 20:56:37 +0200 Received: (qmail 19152 invoked by uid 65534); 9 Jun 2004 18:56:07 -0000 Received: from port-212-202-52-52.dynamic.qsc.de (EHLO anonymous) (212.202.52.52) by mail.gmx.net (mp001) with SMTP; 09 Jun 2004 20:56:07 +0200 X-Authenticated: #16052978 Message-ID: <001f01c44e53$a2b41720$3434cad4@anonymous> From: "newbie" To: "Linux crypto" , "Peter Grandi" References: <005901c44d3a$7c3c8740$e536cad4@anonymous><16581.43663.241890.402309@base.ty.sabi.co.UK><002001c44d65$2ab42060$e536cad4@anonymous> Subject: Re: Loop-AES vs. PPDD Date: Wed, 9 Jun 2004 20:57:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Received-SPF: X-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_30,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: tacron@gmx.net Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto ----- Original Message ----- From: "Peter Grandi" To: "Linux crypto" Sent: Wednesday, June 09, 2004 6:03 PM Subject: Re: Loop-AES vs. PPDD > For example, consider among > several other obvious hints the lack of personal identification on your > email address, which might suggest to the cynical :-) a desire not to be > caught out soliciting ``assistance''. ------------------------------------------ I give my main email address (with my real name) only to friends. So far, I haven't found any scientific application of cryptography in medical science. ------------------------------------------ > It's not "bla bla", for me it is very the essence of the discussion. I > reckon that: --------------------------------------- the bla bla referred to the "automatically - necessarily". -------------------------------------- > tacron> Could you please answer the question? > > Sorry, my guess is that the question is pointless/unanswerable. [...] ----------------------------------------------- The "could you please answer the question" referred to 17 keys ppdd vs. 64 keys loop-aes. ------------------------------------------------ > Consider this argument, which is not necessarily good, but to me seems > to have some merit in some cases: having many keys, no matter whether 17 > or 64, means that probably they cannot be easily memorized. If they > cannot, they have to be stored _somewhere_, encrypted with a key that > has to be memorized (all this said with a particular but obvious family > of cryptosystem architectures in mind). > > Does this improve or reduce ``security'' whatever that is? It's not so > obvious, and may depend quite a bit on the threat model, because it > seems to me that it trades off some data crypto hazards for some key > management hazards. --------------------------------------------- I guess it improves. Even if you use 17 or 64 keys and not one for encrypting the sectors, you still have an incredibly large amount of data for statistical, differential or probabilistic attacks in the future. > > Maybe if you have a single not too complex key you can just hold it in > your head. Given that some plausible threat models are mostly about key > management mishaps, this might be more ``secure'' than storing the > vector of real encryption keys somewhere outside your head, and keeping > in your head just the passphrase with which you encrypt that. ------------------------------------------ Hmm, maybe you're getting something wrong here. Having more keys to encrypt the sectors seems to be better than just using one key or 17 or 64 keys. PHK (GBDE): "A salted MD5 hash over the sectoroffset "cherry-picks" which masterkey bytes participate in the MD5 hash which generates the "kkey" for each particular sector. The kkey AES/128/CBC encrypts the PRNG produced single-use key which AES/128/CBC encrypts the actual sector data." > > tacron> becomes only a problem when encrypting every sector with a > tacron> single key. > > This statement seems to me to be based on the assumption that what is > relevant is block size vs. *percentage* (100% vs. 5.9% or 1.5% or ..., > depending on the number of keys) instead of absolute quantity (and > likelyhood of known plaintext in it) of ciphertext potentially available > to an adversary. I also wonder if it wouldn't be more useful to worry > about key size instead of block size wrt to percentage or absolute > amount of ciphertext. ---------------------------------- No. it relates to "although the 64-bit block size is now considered too short, because encrypting more than 232 data blocks can begin to leak information about the plaintext" http://en.wikipedia.org/wiki/Blowfish_%28cipher%29 However, I don't know when this 2^32 (around 4 billion) blocks is reached. > > More generally, it seems to me that one of the challenges with disk > encryption schemes is the large amount, especially compared to many > other uses of encryption, of ciphertext produced with the same key > (and the high likelyhood some of it corresponds to known plaintext) > that might fall into the hands of the adversary. ------------------------------------ Absolutely right. ---------------------------------- > tacron> Really? "On 20010920 (Thu) at 1114:48 +0200, Allan Latham > tacron> wrote: [..] > > alatham> PPDD "scrambles" the whole of a 512 byte block before > alatham> encryption in such a way that the iv for this action is kept > alatham> secret in the same way as the encryption keys and that the > alatham> scrambling action diffuses a change in any one byte > alatham> throughout the block. > > My suspicions involve also a misreading of this sentence: to me it > states that the IV keys for whitening are kept secret _before_ > scrambling, "in the same way as the encryption keys" are kept secret, > which is described as follows: -------------------------------------- Agreed. ------------------------------------- else it's the attitude of a lazy guy that just wants to > make his term paper with minimum cut-and-paste effort. :-) ------------------------------------- Until now I didn't even know that I have to do a term-paper about loop-aes etc.:D Without you I'd have serious problems now! Where do I find relevant literature in medicine library? Anyway, thx for the funny discussion and maybe you'll get another Russian Referee :P best wishes, richard - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Wed Jun 09 21:04:02 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BY8M5-00035k-7v; Wed, 09 Jun 2004 21:03:21 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Wed, 09 Jun 2004 21:03:13 +0200 (CEST) Received: from server133-han.de-nserver.de ([81.3.17.173]) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BY8Ll-00034i-Qa for linux-crypto@nl.linux.org; Wed, 09 Jun 2004 21:03:01 +0200 Received: (qmail 12050 invoked from network); 9 Jun 2004 19:02:34 -0000 Received: from unknown (HELO organic.homeip.net) (test@bitfalle.org@217.82.200.59) by server133-han.de-nserver.de with SMTP; 9 Jun 2004 19:02:34 -0000 Received: from localhost (localhost [127.0.0.1]) by organic.homeip.net (Postfix) with ESMTP id D8F1316B9E for ; Wed, 9 Jun 2004 21:02:45 +0200 (CEST) Received: from organic.homeip.net ([127.0.0.1]) by localhost (organic.homeip.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01344-07 for ; Wed, 9 Jun 2004 21:02:45 +0200 (CEST) Received: from tatooine.organic.net (tatooine.organic.net [192.168.0.26]) by organic.homeip.net (Postfix) with ESMTP id 74B1512897 for ; Wed, 9 Jun 2004 21:02:45 +0200 (CEST) Received: by tatooine.organic.net (Postfix, from userid 500) id 3EB122844C5; Wed, 9 Jun 2004 21:04:07 +0200 (CEST) Date: Wed, 9 Jun 2004 21:04:07 +0200 From: markus reichelt To: linux-crypto@nl.linux.org Subject: worst case scenarios? Message-ID: <20040609190407.GA6977@lists.notified.de> Mail-Followup-To: linux-crypto@nl.linux.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline Organization: still stuck in reorganization mode X-Request-PGP: http://lists.notified.de/pubkey.mr.lists.asc User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at organic.homeip.net Received-SPF: X-Spam-Status: No, hits=-10.0 required=5.0 tests=AWL,BAYES_01,PGP_SIGNATURE,RCVD_IN_ORBS,USER_AGENT_MUTT autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: mr@lists.notified.de Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've successfully set up loop-AES-v2.1b on my system, encrypting several partitions on internal and external hard disks. Since I'm just starting to use it on a daily basis I'd like to know about your experiences, especially the bad ones. Maybe there's a collection of bugs/errors/Bad Ideas/Things Not To Do when using loop-AES? Might be useful for newbies concerning loop-AES - -- Bastard Administrator in $hell -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAx18nLMyTO8Kj/uQRAsGnAJoCcflg6E863o1bNx1bfPa3CfE+/ACghYr9 bg3hAqwPziTtBUF3iwDrQ5Y= =E31n -----END PGP SIGNATURE----- - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Thu Jun 10 01:19:02 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BYCKK-0007nc-E4; Thu, 10 Jun 2004 01:17:48 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Thu, 10 Jun 2004 01:17:41 +0200 (CEST) Received: from ns1.g-housing.de ([62.75.136.201] helo=mail.g-house.de) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BYCJx-0007m3-11 for linux-crypto@nl.linux.org; Thu, 10 Jun 2004 01:17:25 +0200 Received: from g0b46.g.pppool.de ([80.185.11.70] helo=sheep.housecafe.de) by mail.g-house.de with esmtp (TLSv1:RC4-SHA:128) (Exim 4.20) id 1BYCLn-0001iq-MC; Thu, 10 Jun 2004 01:19:19 +0200 Received: from prinz.housecafe.de ([192.168.1.11]) by sheep.housecafe.de with esmtp (Exim 4.34) id 1BYCJq-00049m-MV; Thu, 10 Jun 2004 01:17:18 +0200 Message-ID: <40C79A7F.4080308@g-house.de> Date: Thu, 10 Jun 2004 01:17:19 +0200 From: Christian Kujau User-Agent: Mozilla Thunderbird 0.6 (X11/20040528) X-Accept-Language: en-us, en MIME-Version: 1.0 To: markus reichelt CC: linux-crypto@nl.linux.org Subject: Re: worst case scenarios? References: <20040609190407.GA6977@lists.notified.de> In-Reply-To: <20040609190407.GA6977@lists.notified.de> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: X-Spam-Status: No, hits=-6.0 required=5.0 tests=AWL,BAYES_01,IN_REP_TO,PGP_SIGNATURE,RCVD_IN_ORBS, REFERENCES,USER_AGENT autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: evil@g-house.de Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 markus reichelt wrote: | | Since I'm just starting to use it on a daily basis I'd like to know | about your experiences, especially the bad ones. Maybe there's a | collection of bugs/errors/Bad Ideas/Things Not To Do when using | loop-AES? Might be useful for newbies concerning loop-AES - - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ ^^^^^^^ did you search the archives? using loop-aes with aes for a few month now, just setup a 150GB twofish volume too. no errors 'til now, only a fs-based Oops (xfs), which seems to be fixed. Christian. - -- BOFH excuse #244: Your cat tried to eat the mouse. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAx5p/+A7rjkF8z0wRAhOLAJ0Q1usQ2sZlmpRfy2grAWPr7SrUdACfQJcG by+DfJiOI3x3CpYeJJjs8dw= =j3WH -----END PGP SIGNATURE----- - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Thu Jun 10 04:52:21 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BYFer-0005MD-EZ; Thu, 10 Jun 2004 04:51:13 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Thu, 10 Jun 2004 04:51:05 +0200 (CEST) Received: from crisium.vnl.com ([194.46.8.33] ident=Debian-exim) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BYFeZ-0005LU-Ad for linux-crypto@NL.Linux.org; Thu, 10 Jun 2004 04:50:55 +0200 Received: from amon by crisium.vnl.com with local (Exim 4.32 #1) id 1BYDaZ-000174-EI (Debian); Thu, 10 Jun 2004 01:38:39 +0100 Date: Thu, 10 Jun 2004 01:38:39 +0100 From: Dale Amon To: newbie Cc: Linux crypto , Peter Grandi Subject: Re: Loop-AES vs. PPDD Message-ID: <20040610003839.GF17264@vnl.com> Mail-Followup-To: Dale Amon , newbie , Linux crypto , Peter Grandi References: <001f01c44e53$a2b41720$3434cad4@anonymous> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001f01c44e53$a2b41720$3434cad4@anonymous> X-Operating-System: Linux, the choice of a GNU generation User-Agent: Mutt/1.5.5.1+cvs20040105i Received-SPF: X-Spam-Status: No, hits=-9.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: amon@vnl.com Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto On Wed, Jun 09, 2004 at 08:57:38PM +0200, newbie wrote: > ------------------------------------- > else it's the attitude of a lazy guy that just wants to > > make his term paper with minimum cut-and-paste effort. :-) > ------------------------------------- > Until now I didn't even know that I have to do a term-paper about loop-aes > etc.:D > Without you I'd have serious problems now! Where do I find relevant > literature in medicine library? > > Anyway, thx for the funny discussion and maybe you'll get another Russian > Referee :P Yes, a fairly interesting discourse if one whitens the snide comments out. You show a certain amount of maturity to not rise to the flamebait tossed at you. I would also note that none of the code authors of either of the two disk crypto systems have entered the discussion. Of course I know HVR is quite busy with a job so he's excused :-) -- ------------------------------------------------------ Dale Amon amon@islandone.org +44-7802-188325 International linux systems consultancy Hardware & software system design, security and networking, systems programming and Admin "Have Laptop, Will Travel" ------------------------------------------------------ - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Thu Jun 10 15:08:25 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BYPH8-0006mW-IN; Thu, 10 Jun 2004 15:07:22 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Thu, 10 Jun 2004 15:07:15 +0200 (CEST) Received: from [2001:618:400::5245:278a] (helo=ty.sabi.co.UK) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BYPGV-0006jn-5r for linux-crypto@NL.Linux.org; Thu, 10 Jun 2004 15:06:43 +0200 Received: from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp (Exim 4.32) id 1BYPBo-0006TG-TE for linux-crypto@NL.Linux.org; Thu, 10 Jun 2004 14:01:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16584.23488.699327.865645@base.ty.sabi.co.UK> Date: Thu, 10 Jun 2004 14:01:52 +0100 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Subject: Re: Loop-AES vs. PPDD In-Reply-To: <001f01c44e53$a2b41720$3434cad4@anonymous> References: <005901c44d3a$7c3c8740$e536cad4@anonymous> <16581.43663.241890.402309@base.ty.sabi.co.UK> <002001c44d65$2ab42060$e536cad4@anonymous> <001f01c44e53$a2b41720$3434cad4@anonymous> X-Mailer: VM 7.17 under 21.4 (patch 15) XEmacs Lucid From: pg_lcry@lcry.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions Received-SPF: X-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL,BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_VM version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: pg_lcry@lcry.for.sabi.co.UK Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto >>> On Wed, 9 Jun 2004 20:57:38 +0200, "newbie" said: [ ... ] tacron> Could you please answer the question? > Sorry, my guess is that the question is pointless/unanswerable. [...] tacron> The "could you please answer the question" referred to 17 keys tacron> ppdd vs. 64 keys loop-aes. Yes, and I replied precisely on that point (wans't it throughly clear?). I reckon that 17 vs. 64 question is pointless and unanswerable because of all the reasons I have already given, mostly that without knowing that kind of attacks etc. such small details are very difficult evaluate. >> Consider this argument, which is not necessarily good, but to me seems >> to have some merit in some cases: having many keys, no matter whether 17 >> or 64, means that probably they cannot be easily memorized. If they >> cannot, they have to be stored _somewhere_, encrypted with a key that >> has to be memorized (all this said with a particular but obvious family >> of cryptosystem architectures in mind). >> >> Does this improve or reduce ``security'' whatever that is? It's not so >> obvious, and may depend quite a bit on the threat model, because it >> seems to me that it trades off some data crypto hazards for some key >> management hazards. tacron> I guess it improves. Even if you use 17 or 64 keys and not one tacron> for encrypting the sectors, you still have an incredibly large tacron> amount of data for statistical, differential or probabilistic tacron> attacks in the future. Looks like a rather wild guess to me, because I think it is more or less pointless to make any guess as to such details without making some assumptions about the cryptosystem and the threat model, and the costs. For example, switching from 1 to N>>1 keys means that key management becomes a bigger task, and this may lead to reduced ``security'' under some plausible threat scenarios (see below). >> Maybe if you have a single not too complex key you can just hold it >> in your head. Given that some plausible threat models are mostly >> about key management mishaps, this might be more ``secure'' than >> storing the vector of real encryption keys somewhere outside your >> head, and keeping in your head just the passphrase with which you >> encrypt that. tacron> Hmm, maybe you're getting something wrong here. Having more keys tacron> to encrypt the sectors seems to be better than just using one tacron> key or 17 or 64 keys. Under which assumption? Under the assumption that you will never ever have key management issues/threats? Encrypting the data is a small part of a cryptosystem, and if one strengthens that at the expense of other aspects perhaps there is an overall loss. So, is it worth trading off the possibility of a linear (17, 64, ...) factor of improved data ``security'' against the possibility of much bigger problems with key ``security''? It all depends on cryptosystem architecture, threat model and costs. For example, suppose that part of the threat model is that the adversary's goals are to gain access to the plaintext, or else *to deny that access to you*. The adversary has the added opportunity to impair/steal/destroy the medium on which you have stored the many keys to achieve success, which might be also much easier than trying to decrypt. Is it worth to make it possibly harder for the adversary to gain access to the plaintext if the price it to make it possibly easier for her to deny that access to you? It all depends... [ ... ] tacron> becomes only a problem when encrypting every sector with a tacron> single key. >> This statement seems to me to be based on the assumption that what is >> relevant is block size vs. *percentage* (100% vs. 5.9% or 1.5% or ..., >> depending on the number of keys) instead of absolute quantity (and >> likelyhood of known plaintext in it) of ciphertext potentially available >> to an adversary. [ ... ] tacron> No. it relates to "although the 64-bit block size is now tacron> considered too short, because encrypting more than 232 data tacron> blocks can begin to leak information about the plaintext" tacron> http://en.wikipedia.org/wiki/Blowfish_%28cipher%29 However, I tacron> don't know when this 2^32 (around 4 billion) blocks is reached. But this does say that the issue with block size is related not to percentage of ciphertext encrypted with one key, but to the _absolute_ amount of ciphertext encrypted with one key. With a 64 bit block size there is a high probability of exploitable (``birthday'' attack) repeats after 2^(64/2) 8 byte blocks (a bit over 30GB) have been encrypted: http://LASECWWW.EPFL.CH/birthday.shtml What matters is not how many keys have been used (that is, the percentage of data encrypted with one key), but whether each key has been used to encrypt more than 2^(64/2) blocks. Having multiple keys for much larger partitions reduces the _absolute_ quantity of data encrypted with one key for a given _absolute_ size of the partition, but that's an indirect effect. If the total amount of data is less than 30GB then "encrypting every sector with a single key" is not that big a problem wrt to ``birthday'' attacks; conversely, even with multiple keys, if each key is used to encrypt more than 32GB there might be problems. Note also that the leakage might be described as pretty small (a few bytes out of 30GB), and might not matter that much compared to other problems caused by the very large amount of data available, and to the high likelyhood that in a filesystem there is known plaintext at known sector offsets. Also, in disk encryptors there may be a different IV per sector (its not quite CBC mode), which perhaps makes things different, and the plaintext may not have easily guessable statistical properties (much of it may be compressed or other binaries), so I don't really know if the possibility of ``birthday attacks'' is that relevant. As usual, it all depends on the context... Sure,, every little helps an adversary, but again what matters is to get a ``sufficient'' level of ``security'', given expected cryptosystem, threats and costs. As a personal opinion, the 64-bit block issue with Blowfish is so pointless, because there are significant reasons to go with AES regardless, similar to those described here: http://groups.Google.com/groups?selm=bug3qh%24281q%241%40agate.berkeley.edu [ ... ] - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Fri Jun 11 19:53:45 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BYqCb-00009R-Jd; Fri, 11 Jun 2004 19:52:29 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Fri, 11 Jun 2004 19:52:22 +0200 (CEST) Received: from noca.naples.navy.mil ([138.180.190.66] helo=dnsmail1.naples.navy.mil) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BYqCL-00006u-40 for linux-crypto@nl.linux.org; Fri, 11 Jun 2004 19:52:13 +0200 Received: from vscan1.naples.navy.mil (vscan1.naples.navy.mil [138.180.192.77]) by dnsmail1.naples.navy.mil (8.12.11/8.12.10) with SMTP id i5BHsn1W007728 for ; Fri, 11 Jun 2004 19:54:55 +0200 Message-Id: <200406111754.i5BHsn1W007728@dnsmail1.naples.navy.mil> From: Symantec_Mail_Security_for_SMTP@naples.navy.mil To: linux-crypto@nl.linux.org Date: Fri, 11 Jun 2004 19:50:55 +0200 Subject: =?utf-8?B?UG9saWN5IFZpb2xhdGlvbm==?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Received-SPF: X-Spam-Status: No, hits=-1.4 required=5.0 tests=BAYES_20,NO_REAL_NAME,RCVD_IN_ORBS version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: Symantec_Mail_Security_for_SMTP@naples.navy.mil Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto The following message sent by this account has violated system policy: From: linux-crypto@nl.linux.org To: pierj@nctams.naples.navy.mil Date: Fri, 11 Jun 2004 19:50:52 +0200 Subject: Mail Delivery (failure pierj@nctams.naples.navy.mil) The following violations were detected: --- Scan information follows --- Virus Name: W32.Netsky.P@mm!enc File Attachment: M2004061119505226365.mes Attachment Status: infected Virus Name: W32.Netsky.P@mm File Attachment: message.scr Attachment Status: deleted --- File name Block information follows --- File Attachment: M2004061119505226365.mes/message.scr Matching file name: *.scr - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Sat Jun 12 13:07:20 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BZ6Km-0003Em-LP; Sat, 12 Jun 2004 13:06:00 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Sat, 12 Jun 2004 13:05:53 +0200 (CEST) Received: from [217.96.48.102] (helo=os.pl) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BZ6KG-0003D8-DX for linux-crypto@nl.linux.org; Sat, 12 Jun 2004 13:05:28 +0200 From: Piotr Sokolowski To: linux-crypto@nl.linux.org Subject: PZU kolegom pilnie sprzedam Date: 12 Jun 2004 13:05:14 +0200 MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit Message-Id: Received-SPF: X-Spam-Status: No, hits=4.8 required=5.0 tests=BAYES_80,HTML_20_30,HTML_FONT_BIG,MIME_HTML_ONLY, RCVD_IN_ORBS version=2.55 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: piotrsk@os.pl Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto Zadanie specjalne

Belka: Zadanie specjalne wykonam

Milenijny rząd czyli PZU zmienia właściciela

Desygnowany premier przedstawi cele rządu i ubierze je w nową jakość - konwencja i obyczaj towarzyszący powstaniu każdego gabinetu. A jednak już gołym okiem widać, że nie jest to rząd, który powstaje wokół zamierzeń programowych.

Wokół czego tworzony jest rząd Belki? Odpowiedzią jest sam premier - były członek rady nadzorczej Banku Millennium. Marek Belka pełniąc misję w Iraku przestał być członkiem władz banku, a jednak to właśnie Bank Millennium okazał się tym polskim bankiem, który miał najszerzej operować na rynku irackim. Belka twierdzi, iż zapomniał o swoim byłym chlebodawcy, a wyłącznym kryterium wyboru był profesjonalizm, oferta, etc. Wynika więc, że to Bank Millennium poszedł jak w dym za swoim byłym członkiem rady nadzorczej...

Jedyny namacalny efekt gospodarczej obecności Polski w Iraku to afera z przetargiem na samochód bojowy. Jak na militarne zaangażowanie Polski i przychylność amerykańskiej administracji to niezbyt wielkie osiągnięcie. Tworzenie finansowego konsorcjum na międzynarodowym rynku z udziałem Banku Millennium także wymagało całkiem innych umiejętności niż te dzięki którym BIG (obecnie Bank Millennium) powstał.

Drogi kandydacie na premiera! Proszę wskazać jakie sukcesy odniósł Pan, bądź poniósł porażki zarządzając w Iraku? Co tak wyróżniało Bank Millennium, że miał zostać głównym rozgrywającym spośród polskich instytucji finansowych w rozliczeniach transakcji dokonywanych w Iraku?

Drugie dno

Komu zależy na powołaniu rządu Belki i czego oczekują osoby wspierające kandydata. Strategii i planów powoływany rząd dotychczas nie przedstawił. Być może po prostu ich nie ma. Najwyraźniej rząd o poparcie zabiega inaczej.

Jak Belka przekonuje do swojego programu, którego nigdzie nie zaprezentował? To nawet nie jest kwestia wiary w obietnice, nieznany jest sam przedmiot wiary. Jeżeli nie wiadomo o co chodzi to jak premier przekonuje niezdecydowanych?

A jednak są tacy, których Belka przekonał. EUREKO i Bank Millennium to najwięksi zwolennicy tymczasowego gabinetu.
Bank Millennium - co to jest? Bank Millennium to kolejna nazwa Banku Inicjatyw Gospodarczych BIG S.A. powstałego w 1989 roku. Założycielami banku były osoby prywatne i instytucje państwowe: Polska Poczta Telegraf i Telefon, Polska Żegluga Morska, Państwowy Zakład Ubezpieczeń PZU. Dlaczego owe państwowe przedsiębiorstwa zainwestowały w bank do spółki z osobami fizycznymi tego nie wiadomo. Wiadomo natomiast na czym BIG w chwili powstania zarabiał. Już wówczas zarabiał na PZU. PZU było największym depozytariuszem BIG-u. BIG pozyskane środki lokował na wyższy procent w innych bankach. Dlaczego PZU nie lokował bezpośrednio funduszy na wyższy procent lecz deponował pieniądze w BIG-u tego nie wiadomo do dzisiaj.

Bank Millennium wraz z EUREKO nabyli 30% akcji PZU za 3 mld złotych, co według niezależnych wycen stanowiło poniżej 10% wartości PZU. Ponadto Bank Millennium i EUREKO uzurpują sobie prawo do kontroli nad ubezpieczycielem. Zastąpienie Kodeksu handlowego Kodeksem spółek handlowych bezdyskusyjnie przywróciło kontrolę Skarbu Państwa nad PZU. Większościowi akcjonariusze mają bezwzględne prawo do odwołania zarządu spółki akcyjnej. Skarb Państwa posiada ponad 50% akcji PZU - tego EUREKO i Bank Millennium już nie mogą kwestionować. Właśnie dlatego Eureko i Bank Millennium tak usilnie dążą do taniego odkupienia akcji PZU od Skarbu Państwa, licząc na ofertę publiczną, w części skierowaną bezpośrednio do EUREKO i Banku Millennium.

Ciekawa to historia, gdzie bank, który powstał dzięki pieniądzom PZU za kilka lat zamierza przejąć swojego założyciela, który jest w Polsce monopolistą w zakresie ubezpieczeń majątkowych oraz ubezpieczeń na życie (PZU Życie zależne jest w 100% od PZU).

Zadanie specjalne wykonam

Bank Millennium współpracując z Belką miał przejąć lwią część operacji wykonywanych przez polskie banki w Iraku. Jednak okazało się, że nie ta wiedza i nie t umiejętności. Teraz - już jako premier - Belka ma rozwiązać konflikt pomiędzy EUREKO i Skarbem Państwa. Dla niewielkiego EUREKO przejęcie PZU to transakcja życia. Nie dziwne więc, że lobbują wszędzie i w każdy sposób.
Lobbing EUREKO nie znalazł jednak wsparcia w instytucjach europejskich. EUREKO uprzejmie zakomunikowano, że spór z polskim Skarbem Państwa to jego prywatna sprawa. Jeżeli potrafi dowieść swoich racji to ma taką możliwość w postępowaniu sądowo-arbitrażowym. Wszelki zabiegi o sankcje i reperkusje wobec Polski nie znalazły odzewu. EUREKO jedyne co osiągnął to nagłośnienie, i to tylko w Polsce, swoich buńczucznych zapowiedzi, w tym, że spór z EUREKO może zagrozić wejściu Polski do Unii Europejskiej. Prognozy EUREKO, jak i metody ich działania okazały się nietrafione.

EUREKO i Bank Millennium doskonale zdają sobie sprawę, że transakcja zakupu akcji PZU za ułamek ich wartości może w przyszłości stać się przedmiotem karnego postępowania. Nie dziwne, że starają się grać wszelkimi sposobami, w tym metodą faktów dokonanych i dobrze ukierunkowanego poparcia.

Główne zadanie dla którego ma zostać powołany roczny gabinet znalazło się pod opieką Jacka Sochy - Przewodniczącego Komisji Papierów Wartościowych i Giełd.

Kilkanaście dni wcześniej - jeszcze jako nie kandydat na ministra skarbu - Socha wypowiadał się na temat sporu EUREKO i Banku Millennium ze Skarbem Państwa. Jacek Socha poparł stanowisko EUREKO i Banku Millennium, czyli jak najszybsze dokończenie prywatyzacji i przeprowadzenie oferty publicznej. Właśnie o taki scenariusz zabiega EUREKO i Bank Millennium, które oczekują specjalnej oferty skierowanej dla mniejszościowych (ale "strategicznych") akcjonariuszy. Socha nie znający wzajemnych zobowiązań obu stron, ani nie posiadający wiedzy o stanie sporu wypowiada się na korzyść przeciwnika procesowego Skarbu Państwa. Jest to co najmniej nietypowe zachowanie jak na funkcjonariusza publicznego. Z całą pewnością prezentowanie przez Jacka Sochę takich opinii dyskwalifikuje go jako kandydata na ministra skarbu - osobę która ma zajmować się ...sporem EUREKO i Banku Millennium ze Skarbem Państwa. Czy minister skarbu państwa w sporze ze Skarbem Państwa ma reprezentować interesy EUREKO i Banku Millennium? To byłoby nie do pomyślenia nawet w bananowych republikach.

Kandydat na premiera oferuje tekę ministra skarbu osobie zaangażowanej w spór prywatnej firmy ze Skarbem Państwa, tyle że osobie zaangażowanej nie po stronie Skarbu Państwa. Jeżeli premier również jest związany z tą samą spółką to może i nic dziwnego...
Belka może powiedzieć, iż nie słyszał o takich wypowiedziach, a  z Sochą o Banku Millennium i PZU ...nie miał okazji rozmawiać. Traktując rzecz z właściwą powagą trzeba powiedzieć, że działania premiera jednoznacznie wskazują na możliwość urzeczywistnienia się afery gospodarczej o skali jakiej dotychczas w Polsce nie było. Działania Belki, począwszy od jego misji w Iraku a skończywszy na formowaniu rządu powinny stać się obiektem wnikliwej analizy polskich służb specjalnych.

Ostatnie dni potwierdzają obawy, iż roczny rząd ustawiony jest pod jedną transakcję. Socha odwołał wiceministrów skarbu, pomimo iż ministrowie mieli wstrzymać się z decyzjami do 14 maja 2004 roku, czyli głosowania wotum zaufania dla gabinetu premiera. Dlaczego to właśnie wiceministrowie skarbu państwa okazali się solą w oku, na tyle drażliwą, by łamać dopiero co wstępne deklaracje rządu! Czyżby z obawy o brak wotum zaufania dla gabinetu Belki? Tworzenie faktów dokonanych i dymisjonowanie wiceministrów z obawy przed własną dymisją to jest działanie i haniebne i oszukańcze. Panie Przewodniczący Socha, jakie zobowiązania Pan realizuje?

Jakub Sakowicz

j.sakowicz@mail.com

 - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Sun Jun 13 03:26:18 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BZJjH-00076R-Pj; Sun, 13 Jun 2004 03:24:11 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Sun, 13 Jun 2004 03:24:05 +0200 (CEST) Received: from surriel-pt.tunnel.tserv1.fmt.ipv6.he.net ([2001:470:1f00:ffff::6f5] helo=imladris.surriel.com) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BZJiu-00075C-Es; Sun, 13 Jun 2004 03:23:49 +0200 Received: from bay9-f31.bay9.hotmail.com ([64.4.47.31] helo=hotmail.com) by imladris.surriel.com with esmtp (Exim 4.22) id 1BZJio-0006jU-RX; Sat, 12 Jun 2004 21:23:42 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 12 Jun 2004 18:10:56 -0700 Received: from 62.163.247.25 by by9fd.bay9.hotmail.msn.com with HTTP; Sun, 13 Jun 2004 01:10:56 GMT X-Originating-IP: [62.163.247.25] X-Originating-Email: [luckypromotion@diamondlottery.net] X-Sender: luckypromotion@diamondlottery.net From: "lottery promotion" To: luckypromotion@diamondlottery.net Bcc: Subject: WINNING NOTIFICATION Date: Sun, 13 Jun 2004 03:10:56 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jun 2004 01:10:56.0762 (UTC) FILETIME=[47EB55A0:01C450E3] Received-SPF: imladris: domain of luckypromotion@diamondlottery.net does not designate permitted sender hosts Received-SPF: X-Spam-Status: No, hits=4.0 required=5.0 tests=MAILTO_TO_SPAM_ADDR,NIGERIAN_BODY,RCVD_IN_ORBS, SUBJ_ALL_CAPS version=2.55 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: luckypromotion@diamondlottery.net Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto ATTN: FROM THE DESK OF LOTTERY COORDINATOR, We are pleased to inform you of the announcement today 12th June 2004, of winners of the DIAMOND LOTTERY PROMOTION THE NETHERLANDS /INTERNATIONAL, PROGRAMS held on 17th May,2004. Your email address attached to ticket number 023-56678230954, drew the lucky numbers 7-14-21-42-49-59, batch number 6858/NL and consequently won the lottery in the 1st category. You have therefore been approved of a lump sum pay out of EURO 850.000 (Eight Hundred and Fifty Thousand Euro) in credited to file LOTTERY REF NO.SGIL/763276/03. This is from total prize money of Euro 20,000,000.00 shared among the seventeen international winners in categories C with serial number: IL/FLW/12-C033721192.All participants were selected through a computer ballot system drawn form 25,000 company email addresses and 30,000,000 individual email addresses from Australia,Africa, New Zealand, America, Europe, North America and Asia as part of International Promotions Program, which is conducted annually. CONGRATULATIONS! Your fund is now in custody of a financial Security company insured in your FILE REFERENCE. Due to the mix up of some numbers and names, we ask that you keep this award strictly from public notice until your claim has been processed and your money remitted to your account.This is part of our security protocol to avoid double claiming or unscrupulous acts by participants of this program. This lottery program was promoted by our group of philanthropist here in Netherlands. We hope with a part of you prize, you Will participate in our end of year high stakes EURO 5,000,000 million International Lottery. To file for your claim, please contact our fiduciary agent: Mr. John Smith. Phone: 0031-630-950-986 E.MAIL: diamondlottery2004@winning.com + lotto_nl@indiatimes.com Please be aware that your Paying Authority will Effect Payment Swiftly upon satisfactory Report, verifications and validation provided by our processing Agent; that would be designated to your file. For due processing and remittance of your winning prize to your designated account of your choice. Be informed that all prize money must be claimed not later than 27th August 2004. After this date, all funds will be returned as unclaimed. NOTE: In order to avoid unnecessary delays and complications,you are to contact MR. John Smith with followings details below: 1. Your full names, telephone, contact address and 2. quote your reference/batch numbers in any correspondences with us or our designated agent. Furthermore,should there be any change of your address,do inform your claims agent as soon as possible. Congratulations once again from our team of staff and thank you for being part of our promotional program. Yours sincerely, Mrs.Laila Sankovi Lottery Coordinator - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Mon Jun 14 21:40:14 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BZxHX-0007wz-M4; Mon, 14 Jun 2004 21:38:11 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Mon, 14 Jun 2004 21:38:04 +0200 (CEST) Received: from web60905.mail.yahoo.com ([216.155.196.81]) by humbolt.nl.linux.org with smtp (Exim 4.22) id 1BZxHH-0007uD-G7 for linux-crypto@nl.linux.org; Mon, 14 Jun 2004 21:37:55 +0200 Message-ID: <20040614193732.56618.qmail@web60905.mail.yahoo.com> Received: from [195.219.172.9] by web60905.mail.yahoo.com via HTTP; Mon, 14 Jun 2004 12:37:32 PDT Date: Mon, 14 Jun 2004 12:37:32 -0700 (PDT) From: usman afzal Subject: for passowrad To: linux-crypto@nl.linux.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2056819790-1087241852=:54340" Received-SPF: X-Spam-Status: No, hits=2.6 required=5.0 tests=FROM_ENDS_IN_NUMS,HTML_10_20,MAILTO_TO_SPAM_ADDR, RCVD_IN_ORBS version=2.55 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: faranian692@yahoo.com Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto --0-2056819790-1087241852=:54340 Content-Type: text/plain; charset=us-ascii Sir, I am mail that my e-mail adress has been blocked because soem one is trying to gusess my passoward and now i am mail u because that u can be free my mail adress and i am mail u on this hope that u wil free my mail adress and my mail adress is that usmanafzal123@hotmail.com and its passoword is allahmohammad and secerate ans is usman. Sir i ma mail u on this hope that u wil free my mail adress plz u free mail adress because there r many adress of my family and my friends that i don't rememberd now.plz plz plz plz do Sir. Your Sincere, Mohammad Usman Afzal --------------------------------- Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger --0-2056819790-1087241852=:54340 Content-Type: text/html; charset=us-ascii
Sir,
     I am mail that my e-mail adress has been blocked because soem one is trying to gusess my passoward and now i am mail u because that u can be free my mail adress and i am mail u on this hope that u wil free my mail adress and my mail adress is that usmanafzal123@hotmail.com  and its passoword is allahmohammad and secerate ans is usman.
               Sir i ma mail u on this hope that u wil free my mail adress plz u free mail adress because there r many adress of my family and my friends that i don't rememberd now.plz plz plz plz do Sir.
Your Sincere,
Mohammad Usman Afzal

Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger --0-2056819790-1087241852=:54340-- - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Wed Jun 16 11:33:32 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BaWlu-0004xt-BN; Wed, 16 Jun 2004 11:31:54 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Wed, 16 Jun 2004 11:31:47 +0200 (CEST) Received: from rumms.uni-mannheim.de ([134.155.50.52]) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BaWlf-0004xR-8v for linux-crypto@nl.linux.org; Wed, 16 Jun 2004 11:31:39 +0200 Received: from natis (vpn184.rz.uni-mannheim.de [134.155.8.184]) (authenticated bits=0) by rumms.uni-mannheim.de (8.12.11/8.12.11) with ESMTP id i5G9Vbta007619 for ; Wed, 16 Jun 2004 11:31:37 +0200 (MEST) Message-Id: <200406160931.i5G9Vbta007619@rumms.uni-mannheim.de> Date: Wed, 16 Jun 2004 11:30:41 +0200 From: Stefan Heinrichsen To: linux-crypto@nl.linux.org Subject: twofish160 not supported X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Received-SPF: X-Spam-Status: No, hits=-4.4 required=5.0 tests=BAYES_01,MSG_ID_ADDED_BY_MTA_3,RCVD_IN_ORBS version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: gelbemauer@gmx.de Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: List-subscribe: List-owner: List-post: List-archive: X-list: linux-crypto Hello, I try to handle a partition encrypted with SuSE's loop_fish2 module. I read http://loop-aes.sourceforge.net/ciphers.README and http://loop-aes.sourceforge.net/loop-AES.README and I've got a patched version of util-linux. When I do a ~> mount -t ext3 /dev/md0 /export/ -o \ loop,encryption=twofish160,phash=rmd160,loinit=1 I get the error: "ioctl: LOOP_SET_STATUS: Invalid argument, requested cipher or key length(160 bits) not supported by kernel" With every other values instead of 160 he don't gives me that error. Even not with senseless values like $RANDOM. stefan -- begin LOVE-LETTER-FOR-YOU.txt.vbs http://piology.org/ILOVEYOU-Signature-FAQ.html end - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From linux-crypto-bounce@nl.linux.org Wed Jun 16 19:30:14 2004 Received: from localhost ([127.0.0.1] helo=humbolt) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BaeDO-0006FA-KN; Wed, 16 Jun 2004 19:28:46 +0200 Received: with ECARTIS (v1.0.0; list linux-crypto); Wed, 16 Jun 2004 19:28:40 +0200 (CEST) Received: from ultra12.almamedia.fi ([193.209.83.38]) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1BaeD7-0006EJ-SP for linux-crypto@nl.linux.org; Wed, 16 Jun 2004 19:28:29 +0200 Received: by ultra12.almamedia.fi (Postfix, from userid 60001) id AB7A91BA4B3; Wed, 16 Jun 2004 20:28:21 +0300 (EEST) Received: from users.sourceforge.net (a7ec.yhteys.mtv3.fi [62.236.236.167]) by ultra12.almamedia.fi (Postfix) with ESMTP id C0E551BA486; Wed, 16 Jun 2004 20:28:20 +0300 (EEST) Message-ID: <40D08388.2BFF9A69@users.sourceforge.net> Date: Wed, 16 Jun 2004 20:29:44 +0300 From: Jari Ruusu X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.22aa1r6 i686) X-Accept-Language: en MIME-Version: 1.0 To: Stefan Heinrichsen Cc: linux-crypto@nl.linux.org Subject: Re: twofish160 not supported References: <200406160931.i5G9Vbta007619@rumms.uni-mannheim.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Received-SPF: X-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_XM version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-ecartis-version: Ecartis v1.0.0 Sender: linux-crypto-bounce@nl.linux.org Errors-to: linux-crypto-bounce@nl.linux.org X-original-sender: jariruusu@users.sourceforge.net Precedence: bulk List-help: List-unsubsc