X-Original-To: pgsql-php-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 23B3ED1B1AE for ; Fri, 30 Jul 2004 06:40:34 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 36582-01 for ; Fri, 30 Jul 2004 09:40:32 +0000 (GMT) Received: from nameit.healthnet.lu (nameit.healthnet.lu [158.64.36.4]) by svr1.postgresql.org (Postfix) with ESMTP id 09DDAD1B1A1 for ; Fri, 30 Jul 2004 06:40:24 -0300 (ADT) Received: from control.dmz.chl.lu (drill.healthnet.lu [158.64.36.2]) by nameit.healthnet.lu (Postfix) with SMTP id 93DE23E830A for ; Fri, 30 Jul 2004 11:40:26 +0200 (CEST) Received: from 172.20.1.24 by control.dmz.chl.lu (InterScan E-Mail VirusWall NT); Fri, 30 Jul 2004 11:43:10 +0200 Received: from gentoo (pret040pcc.inf.chl.lu [172.20.54.4]) by gwia.inf.chl.lu; Fri, 30 Jul 2004 11:40:04 +0200 Date: Fri, 30 Jul 2004 11:43:31 +0200 From: Daniel Struck To: Bruno Wolff III Cc: Greg Stark , Mitch Pirtle , pgsql-php@postgresql.org Subject: Re: [ADMIN] Secure DB Systems - How to Message-Id: <20040730114331.38845c7f@gentoo> In-Reply-To: <20040729180010.GA23523@wolff.to> References: <20040709152722.GA20935@wolff.to> <20040713113557.31e9d6dc@localhost> <20040713123817.GB3710@wolff.to> <20040713151838.0004cb8e@localhost> <40F3EC4A.1060101@spacemonkeylabs.com> <20040727134133.676ab9cf@localhost> <20040727194905.GA20499@wolff.to> <87brhzsx9x.fsf@stark.xeocode.com> <20040729180010.GA23523@wolff.to> Organization: gwia.inf.chl.lu X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200407/46 X-Sequence-Number: 2871 > IVs act to make the key appear longer. This is especially useful when hum= ans > are picking passphrases that are used to generate the key. If you control > what the actual keys are, then you can make dictionary attacks impractica= l. > However, there still would be the problem that identical items in the > database would be identical. Which, depnding on your application, might > be a problem because of information leakage. I don't think this is true for CBC mode. Here the first block of plaintext = is XORed with the IV then encrypted with a block ciper like AES for example= . The next plaintext block is than XORed with the previous cyphertext and s= o on. So IV in CBC is used to make the encrypted cyphertext unique. You can find some info in chapter 9.3 of "Appplied Cryptopgraphy" from Bruc= e Schneier. In my application I do use a different IV for every encrypted plaintext: $td =3D mcrypt_module_open('rijndael-128', '', 'cbc', ''); $iv =3D base64_encode(mcrypt_create_iv(mcrypt_enc_get_iv_size($td), MCRYPT_= DEV_URANDOM)); I do use base64 as it is easier to store it in the database. The plaintext is then encrypted using: $ciphertext =3D "encrypt_iv('" . $plaintext . "','" . $password] . "',decod= e('$iv','base64'),'aes')"; The IV is then stored together with the ciphertext in the database. Daniel --=20 Retrovirology Laboratory Luxembourg Centre Hospitalier de Luxembourg 4, rue E. Barbl=E9 L-1210 Luxembourg phone: +352-44116105 fax: +352-44116113 web: http://www.retrovirology.lu e-mail: struck.d@retrovirology.lu