Re: [PATCHES] pgcrypto: fix for broken solaris openssl, v03
Marko Kreen wrote: solaris openssl refuses to handle keys longer than 128bits. * aes will crash on longer keys * blowfish will silently cut the key which can result data corruption to fix it: - test errors from AES functions - bf errors cannot be tested, do test encryption - change aes compat macros to static function so they can return values Tested on Solaris Nevada and works fine. More general appriaches that also fix the problems are: - test all ciphers on first use and test fails then disable completely. This is nice as it could detect much braded range of errors. Problem with this approach is that its too big overhead for small gain, as it cannot still 100% guarantee that everything is working correctly. - Use EVP functions for encryption as they have better error handling. So crippled openssl can report via regular means that something is not supported. +1 for EVP solution. Thank you very much Zdenek ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] pgcrypto: fix for broken solaris openssl, v03
Tom Lane wrote: Marko Kreen [EMAIL PROTECTED] writes: solaris openssl refuses to handle keys longer than 128bits. ... So something like the current patch should be still applied as a near-term fix. Applied to HEAD and 8.2. I wasn't sure if there was interest in patching further back, or if the patch was meant to work further back. Let me know if you're not happy. PostgreSQL 8.1 is shipped with Solaris. We are interesting it to have backport in 8.1. I tested patch on 8.1.10 and Solaris nevada and works fine. Thanks Zdenek ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] pgcrypto: fix for broken solaris openssl, v03
Zdenek Kotala [EMAIL PROTECTED] writes: Tom Lane wrote: Applied to HEAD and 8.2. I wasn't sure if there was interest in patching further back, or if the patch was meant to work further back. Let me know if you're not happy. PostgreSQL 8.1 is shipped with Solaris. We are interesting it to have backport in 8.1. I tested patch on 8.1.10 and Solaris nevada and works fine. OK, applied to 8.1 too. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] pgcrypto: fix for broken solaris openssl, v03
Tom Lane wrote: Zdenek Kotala [EMAIL PROTECTED] writes: Tom Lane wrote: Applied to HEAD and 8.2. I wasn't sure if there was interest in patching further back, or if the patch was meant to work further back. Let me know if you're not happy. PostgreSQL 8.1 is shipped with Solaris. We are interesting it to have backport in 8.1. I tested patch on 8.1.10 and Solaris nevada and works fine. OK, applied to 8.1 too. Thanks. Zdenek ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] pgcrypto: fix for broken solaris openssl, v03
solaris openssl refuses to handle keys longer than 128bits. * aes will crash on longer keys * blowfish will silently cut the key which can result data corruption to fix it: - test errors from AES functions - bf errors cannot be tested, do test encryption - change aes compat macros to static function so they can return values (Original patch by Zdenek Kotala) I really dislike the patch, as it too specific for the crippled openssl in solaris. But still something should be done because of the possible silent corruption. More general appriaches that also fix the problems are: - test all ciphers on first use and test fails then disable completely. This is nice as it could detect much braded range of errors. Problem with this approach is that its too big overhead for small gain, as it cannot still 100% guarantee that everything is working correctly. - Use EVP functions for encryption as they have better error handling. So crippled openssl can report via regular means that something is not supported. Problem with this is that it can be done only from 0.9.7 onwards. Which pushes the solution to 8.4. So something like the current patch should be still applied as a near-term fix. But I'm starting to think that the blowfish check should be #ifdef __solaris__ only. Has anyone good reasons why it should apply to everyone? -- marko solaris-fix-v03.diff Description: Binary data ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] pgcrypto: fix for broken solaris openssl, v03
Marko Kreen [EMAIL PROTECTED] writes: solaris openssl refuses to handle keys longer than 128bits. ... So something like the current patch should be still applied as a near-term fix. Applied to HEAD and 8.2. I wasn't sure if there was interest in patching further back, or if the patch was meant to work further back. Let me know if you're not happy. But I'm starting to think that the blowfish check should be #ifdef __solaris__ only. Has anyone good reasons why it should apply to everyone? As long as we've got to have the code, we may as well use it --- it's possible that Sun isn't the only vendor who got worried about the crypto export laws. Your caching of the result should be enough to ensure that the overhead is negligible. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] pgcrypto (v02)
There is updated version of patch. See comments bellow:
Marko Kreen wrote:
On 7/27/07, Zdenek Kotala [EMAIL PROTECTED] wrote:
I attach pgcrypto patch which fix two problems on system without strong
crypto support (e.g. default Solaris 10 installation):
1) postgres crashes when AES cipher uses long key
2) Blowfish silently cut longer keys. It could bring problem when
crypted data are transfered from one server to another with strong keys
support.
Couple of style nitpicks:
* please use hex arrays, instead octal-quoted strings. easier on the eye.
fixed
* use memcmp() instead of for() loop.
fixed
* 16 byte bufs for 8 bytes is confusing.
I think it must be 16 because block size is 16 bytes. I'm not sure if 8
bytes could not cause buffer overflow.
This patch was discussed there:
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00762.php
This patch is applicable also on 8.2, 8.1 (and maybe older) version of
postgresql.
OpenSSL autoconfiguration was added in 8.1, so patching older
versions is not that critical.
Zdenek
Index: contrib/pgcrypto/openssl.c
===
RCS file: /zfs_data/cvs_pgsql/cvsroot/pgsql/contrib/pgcrypto/openssl.c,v
retrieving revision 1.30
diff -c -r1.30 openssl.c
*** contrib/pgcrypto/openssl.c 2006/10/04 00:29:46 1.30
--- contrib/pgcrypto/openssl.c 2007/08/07 10:35:24
***
*** 375,385
--- 375,424
/* Blowfish */
+ /* Check if strong crypto is supported. Some openssl installation could support only short keys
+ and unfortunatelly BF_sef_key does not return any error value. This function tests if is possible
+ use strong key.
+ */
+ static
+ int bf_check_supported_key_len()
+ {
+ static unsigned char key[] = {0xf0,0xe1,0xd2,0xc3,0xb4,0xa5,0x96,0x87,0x78,0x69,0x5a,0x4b,
+ 0x3c,0x2d,0x1e,0x0f,0x00,0x11,0x22,0x33,0x44,0x55,0x66,0x77,
+ 0x04,0x68,0x91,0x04,0xc2,0xfd,0x3b,0x2f,0x58,0x40,0x23,0x64,
+ 0x1a,0xba,0x61,0x76,0x1f,0x1f,0x1f,0x1f,0x0e,0x0e,0x0e,0x0e,
+ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff};
+
+ static unsigned char data[16] = {0xfe,0xdc,0xba,0x98,0x76,0x54,0x32,0x10};
+ static unsigned char res[] = {0xc0,0x45,0x04,0x01,0x2e,0x4e,0x1f,0x53};
+ static unsigned char out[16];
+ BF_KEY bf_key;
+ int n;
+
+ /* encrypt and th 448bits key and verify output */
+ BF_set_key(bf_key,56, key);
+ BF_ecb_encrypt( data, out, bf_key, BF_ENCRYPT);
+
+ if( memcmp(out, res, 8) != 0)
+ return 0; /* Output does not match - strong cipher is not supported */
+ return 1;
+ }
+
static int
bf_init(PX_Cipher * c, const uint8 *key, unsigned klen, const uint8 *iv)
{
ossldata *od = c-ptr;
+ static int bf_is_strong = -1;
+
+ /* Test if key len is supported. BF_set_key silently cut large keys and it could be
+ be a problem when user transfer crypted data from one server to another. */
+
+ if( bf_is_strong == -1)
+ bf_is_strong = bf_check_supported_key_len();
+
+ if( !bf_is_strong klen16 )
+ return PXE_KEY_TOO_BIG;
+ /* Key len is supported. We can use it. */
BF_set_key(od-u.bf.key, klen, key);
if (iv)
memcpy(od-iv, iv, BF_BLOCK);
***
*** 692,705
return 0;
}
! static void
ossl_aes_key_init(ossldata * od, int type)
{
if (type == AES_ENCRYPT)
! AES_set_encrypt_key(od-key, od-klen * 8, od-u.aes_key);
else
! AES_set_decrypt_key(od-key, od-klen * 8, od-u.aes_key);
! od-init = 1;
}
static int
--- 731,755
return 0;
}
! static int
ossl_aes_key_init(ossldata * od, int type)
{
+ int err;
+ /* Strong key support could miss on some openssl installation, we must
+ check return value, from set key function.
+ */
if (type == AES_ENCRYPT)
! err = AES_set_encrypt_key(od-key, od-klen * 8, od-u.aes_key);
else
! err = AES_set_decrypt_key(od-key, od-klen * 8, od-u.aes_key);
!
! if (err == 0)
! {
! od-init = 1;
! return 0;
! }
! od-init = 0;
! return PXE_KEY_TOO_BIG;
}
static int
***
*** 709,717
unsigned bs = gen_ossl_block_size(c);
ossldata *od = c-ptr;
const uint8 *end = data + dlen - bs;
if (!od-init)
! ossl_aes_key_init(od, AES_ENCRYPT);
for (; data = end; data += bs, res += bs)
AES_ecb_encrypt(data, res, od-u.aes_key, AES_ENCRYPT);
--- 759,769
unsigned bs = gen_ossl_block_size(c);
ossldata *od = c-ptr;
const uint8 *end = data + dlen - bs;
+ int err;
if (!od-init)
! if( 0 != (err = ossl_aes_key_init(od, AES_ENCRYPT) ))
! return err;
for (; data = end; data += bs, res += bs)
AES_ecb_encrypt(data, res, od-u.aes_key, AES_ENCRYPT);
***
*** 725,733
unsigned bs = gen_ossl_block_size(c);
ossldata *od = c-ptr;
const uint8 *end = data + dlen - bs;
if (!od-init)
! ossl_aes_key_init(od, AES_DECRYPT);
for (; data = end; data += bs, res += bs)
AES_ecb_encrypt(data, res, od-u.aes_key,
Re: [PATCHES] pgcrypto
On 7/27/07, Zdenek Kotala [EMAIL PROTECTED] wrote: I attach pgcrypto patch which fix two problems on system without strong crypto support (e.g. default Solaris 10 installation): 1) postgres crashes when AES cipher uses long key 2) Blowfish silently cut longer keys. It could bring problem when crypted data are transfered from one server to another with strong keys support. Couple of style nitpicks: * please use hex arrays, instead octal-quoted strings. easier on the eye. * use memcmp() instead of for() loop. * 16 byte bufs for 8 bytes is confusing. This patch was discussed there: http://archives.postgresql.org/pgsql-hackers/2007-07/msg00762.php This patch is applicable also on 8.2, 8.1 (and maybe older) version of postgresql. OpenSSL autoconfiguration was added in 8.1, so patching older versions is not that critical. -- marko ps. I looked into use of EVP, and I'm not that optimistic anymore. EVP has 3 differenct name for AES different keys, but only one for CAST5, which also supports different key lengths. Plus Blowfish is tagged as VARIABLE_LENGTH. So it seems per-algo support code cannot be avoided, which makes whole EVP usage rather pointless. The situation could be simplified by dropping encrypt()/decrypt() functions, which allow users to specify final keys. But that would be a nasty event, 8.4 is too early for that... ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] pgcrypto merge cleanup
On Tue, 2006-07-18 at 16:06 +0300, Marko Kreen wrote: - Few README fixes - Keep imath Id string, put $PostgreSQL$ separately. Applied, thanks. -Neil ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] pgcrypto merge cleanup
- Few README fixes - Keep imath Id string, put $PostgreSQL$ separately. -- marko Index: contrib/pgcrypto/README.pgcrypto === RCS file: /opt/cvs/pgsql/contrib/pgcrypto/README.pgcrypto,v retrieving revision 1.15 diff -u -c -r1.15 README.pgcrypto *** contrib/pgcrypto/README.pgcrypto 13 Jul 2006 04:15:24 - 1.15 --- contrib/pgcrypto/README.pgcrypto 18 Jul 2006 13:02:27 - *** *** 36,48 `configure` script. The options that affect it are `--with-zlib` and `--with-openssl`. ! Without zlib, the PGP functions will not support compressed data inside ! PGP encrypted packets. ! Without OpenSSL, public-key encryption does not work, as pgcrypto does ! not yet contain math functions for large integers. ! There are some other differences with and without OpenSSL: ``-` Functionalitybuilt-in OpenSSL --- 36,49 `configure` script. The options that affect it are `--with-zlib` and `--with-openssl`. ! When compiled with zlib, PGP encryption functions are able to ! compress data before encrypting. ! When compiled with OpenSSL there will be more algorithms available. ! Also public-key encryption functions will be faster as OpenSSL ! has more optimized BIGNUM functions. ! Summary of functionality with and without OpenSSL: ``-` Functionalitybuilt-in OpenSSL *** *** 421,427 Options are named to be similar to GnuPG. Values should be given after an equal sign; separate options from each other with commas. Example: ! pgp_sym_encrypt(data, psw, 'compress-also=1, cipher-algo=aes256') All of the options except `convert-crlf` apply only to encrypt functions. Decrypt functions get the parameters from PGP data. --- 422,428 Options are named to be similar to GnuPG. Values should be given after an equal sign; separate options from each other with commas. Example: ! pgp_sym_encrypt(data, psw, 'compress-algo=1, cipher-algo=aes256') All of the options except `convert-crlf` apply only to encrypt functions. Decrypt functions get the parameters from PGP data. *** *** 571,577 --- Those functions only run a cipher over data, they don't have any advanced ! features of PGP encryption. In addition, they have some major problems: 1. They use user key directly as cipher key. 2. They don't provide any integrity checking, to see --- 572,578 --- Those functions only run a cipher over data, they don't have any advanced ! features of PGP encryption. Therefore they have some major problems: 1. They use user key directly as cipher key. 2. They don't provide any integrity checking, to see Index: contrib/pgcrypto/imath.c === RCS file: /opt/cvs/pgsql/contrib/pgcrypto/imath.c,v retrieving revision 1.3 diff -u -c -r1.3 imath.c *** contrib/pgcrypto/imath.c 16 Jul 2006 02:44:00 - 1.3 --- contrib/pgcrypto/imath.c 16 Jul 2006 10:58:02 - *** *** 3,9 Name: imath.c Purpose: Arbitrary precision integer arithmetic routines. Author: M. J. Fromberger http://www.dartmouth.edu/~sting/ ! Info: $PostgreSQL$ Copyright (C) 2002 Michael J. Fromberger, All Rights Reserved. --- 3,9 Name: imath.c Purpose: Arbitrary precision integer arithmetic routines. Author: M. J. Fromberger http://www.dartmouth.edu/~sting/ ! Info: Id: imath.c 21 2006-04-02 18:58:36Z sting Copyright (C) 2002 Michael J. Fromberger, All Rights Reserved. *** *** 27,32 --- 27,33 CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */ + /* $PostgreSQL$ */ #include postgres.h #include px.h Index: contrib/pgcrypto/imath.h === RCS file: /opt/cvs/pgsql/contrib/pgcrypto/imath.h,v retrieving revision 1.3 diff -u -c -r1.3 imath.h *** contrib/pgcrypto/imath.h 16 Jul 2006 02:44:01 - 1.3 --- contrib/pgcrypto/imath.h 16 Jul 2006 11:00:17 - *** *** 2,8 Name: imath.h Purpose: Arbitrary precision integer arithmetic routines. Author: M. J. Fromberger http://www.dartmouth.edu/~sting/ ! Info: $PostgreSQL$ Copyright (C) 2002 Michael J. Fromberger, All Rights Reserved. --- 2,8 Name: imath.h Purpose: Arbitrary precision integer arithmetic routines. Author: M. J. Fromberger http://www.dartmouth.edu/~sting/ ! Info: Id: imath.h 21 2006-04-02 18:58:36Z sting Copyright (C) 2002 Michael J. Fromberger, All Rights Reserved. *** *** 26,31 --- 26,32 CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */ + /*
Re: [PATCHES] pgcrypto: fix memory leak in openssl.c
On 2/18/06, Marko Kreen [EMAIL PROTECTED] wrote: pgcrypto crypt()/md5 and hmac() leak memory when compiled against OpenSSL as openssl.c digest -reset will do two DigestInit calls against a context. This happened to work with OpenSSL 0.9.6 but not with 0.9.7+. Ugh, seems I read the old code slightly wrong. The leak happens also with regular digest(), although it will leak only 1 context instance, not the 1000+ as the crypt-md5 does. And on 8.1 there is pgp_sym_encrypt that also does lots of resets on one context, like crypt-md5. In addition it does regular digest() in several places. So if compiled against OpenSSL, its leaking everywhere. The positive side is that only 8.1 has openssl autoconfiguration, older versions default to builtin algorithms that can be changed only by editing Makefile, thus most packages are hopefully safe. -- marko ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] pgcrypto: fix memory leak in openssl.c
Marko Kreen [EMAIL PROTECTED] writes: On 2/18/06, Marko Kreen [EMAIL PROTECTED] wrote: pgcrypto crypt()/md5 and hmac() leak memory when compiled against OpenSSL as openssl.c digest -reset will do two DigestInit calls against a context. This happened to work with OpenSSL 0.9.6 but not with 0.9.7+. Ugh, seems I read the old code slightly wrong. The leak happens also with regular digest(), although it will leak only 1 context instance, not the 1000+ as the crypt-md5 does. I'm confused --- does this mean that the patch you sent recently needs further work? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] pgcrypto: fix memory leak in openssl.c
On 2/20/06, Tom Lane [EMAIL PROTECTED] wrote: Marko Kreen [EMAIL PROTECTED] writes: On 2/18/06, Marko Kreen [EMAIL PROTECTED] wrote: pgcrypto crypt()/md5 and hmac() leak memory when compiled against OpenSSL as openssl.c digest -reset will do two DigestInit calls against a context. This happened to work with OpenSSL 0.9.6 but not with 0.9.7+. Ugh, seems I read the old code slightly wrong. The leak happens also with regular digest(), although it will leak only 1 context instance, not the 1000+ as the crypt-md5 does. I'm confused --- does this mean that the patch you sent recently needs further work? No, it's fine. As I did not 'fix' old code but replaced it. It's just that I gave wrong answer to the question 'who is affected?' -- marko ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] pgcrypto: fix memory leak in openssl.c
On Sat, 2006-02-18 at 02:23 +0200, Marko Kreen wrote: Attached are one patch for 7.3, 7.4, 8.0 branches and another for 8.1 and HEAD. Thanks, patches applied to the appropriate branches. -Neil ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] pgcrypto: fix memory leak in openssl.c
pgcrypto crypt()/md5 and hmac() leak memory when compiled against
OpenSSL as openssl.c digest -reset will do two DigestInit calls
against a context. This happened to work with OpenSSL 0.9.6
but not with 0.9.7+.
Reason for the messy code was that I tried to avoid creating
wrapper structure to transport algorithm info and tried to use
OpenSSL context for it. The fix is to create wrapper structure.
It also uses newer digest API to avoid memory allocations
on reset with newer OpenSSLs.
Attached are one patch for 7.3, 7.4, 8.0 branches and another
for 8.1 and HEAD.
Thanks to Daniel Blaisdell for reporting it.
--
marko
Index: contrib/pgcrypto/openssl.c
===
RCS file: /opt/cvs/pgsql/contrib/pgcrypto/openssl.c,v
retrieving revision 1.12.4.1
diff -u -c -r1.12.4.1 openssl.c
*** contrib/pgcrypto/openssl.c 12 Mar 2005 06:55:14 - 1.12.4.1
--- contrib/pgcrypto/openssl.c 17 Feb 2006 23:31:29 -
***
*** 36,95
#include openssl/evp.h
/*
* Hashes
*/
static unsigned
digest_result_size(PX_MD * h)
{
! return EVP_MD_CTX_size((EVP_MD_CTX *) h-p.ptr);
}
static unsigned
digest_block_size(PX_MD * h)
{
! return EVP_MD_CTX_block_size((EVP_MD_CTX *) h-p.ptr);
}
static void
digest_reset(PX_MD * h)
{
! EVP_MD_CTX *ctx = (EVP_MD_CTX *) h-p.ptr;
! const EVP_MD *md;
! md = EVP_MD_CTX_md(ctx);
!
! EVP_DigestInit(ctx, md);
}
static void
digest_update(PX_MD * h, const uint8 *data, unsigned dlen)
{
! EVP_MD_CTX *ctx = (EVP_MD_CTX *) h-p.ptr;
! EVP_DigestUpdate(ctx, data, dlen);
}
static void
digest_finish(PX_MD * h, uint8 *dst)
{
! EVP_MD_CTX *ctx = (EVP_MD_CTX *) h-p.ptr;
! const EVP_MD *md = EVP_MD_CTX_md(ctx);
!
! EVP_DigestFinal(ctx, dst, NULL);
! /*
! * Some builds of 0.9.7x clear all of ctx in EVP_DigestFinal.
! * Fix it by reinitializing ctx.
! */
! EVP_DigestInit(ctx, md);
}
static void
digest_free(PX_MD * h)
{
! EVP_MD_CTX *ctx = (EVP_MD_CTX *) h-p.ptr;
! px_free(ctx);
px_free(h);
}
--- 36,124
#include openssl/evp.h
/*
+ * Backwards compatibility code for digest.
+ */
+ #if OPENSSL_VERSION_NUMBER 0x00907000L
+
+ static void EVP_MD_CTX_init(EVP_MD_CTX *ctx)
+ {
+ memset(ctx, 0, sizeof(*ctx));
+ }
+
+ static int EVP_MD_CTX_cleanup(EVP_MD_CTX *ctx)
+ {
+ memset(ctx, 0, sizeof(*ctx));
+ return 1;
+ }
+
+ static int EVP_DigestInit_ex(EVP_MD_CTX *ctx, const EVP_MD *md, void *engine)
+ {
+ EVP_DigestInit(ctx, md);
+ return 1;
+ }
+
+ static int EVP_DigestFinal_ex(EVP_MD_CTX *ctx, unsigned char *res, unsigned int *len)
+ {
+ EVP_DigestFinal(ctx, res, len);
+ return 1;
+ }
+
+ #endif
+
+ /*
* Hashes
*/
+
+ typedef struct OSSLDigest {
+ const EVP_MD *algo;
+ EVP_MD_CTX ctx;
+ } OSSLDigest;
+
static unsigned
digest_result_size(PX_MD * h)
{
! OSSLDigest *digest = (OSSLDigest *)h-p.ptr;
! return EVP_MD_CTX_size(digest-ctx);
}
static unsigned
digest_block_size(PX_MD * h)
{
! OSSLDigest *digest = (OSSLDigest *)h-p.ptr;
! return EVP_MD_CTX_block_size(digest-ctx);
}
static void
digest_reset(PX_MD * h)
{
! OSSLDigest *digest = (OSSLDigest *)h-p.ptr;
! EVP_DigestInit_ex(digest-ctx, digest-algo, NULL);
}
static void
digest_update(PX_MD * h, const uint8 *data, unsigned dlen)
{
! OSSLDigest *digest = (OSSLDigest *)h-p.ptr;
! EVP_DigestUpdate(digest-ctx, data, dlen);
}
static void
digest_finish(PX_MD * h, uint8 *dst)
{
! OSSLDigest *digest = (OSSLDigest *)h-p.ptr;
! EVP_DigestFinal_ex(digest-ctx, dst, NULL);
}
static void
digest_free(PX_MD * h)
{
! OSSLDigest *digest = (OSSLDigest *)h-p.ptr;
! EVP_MD_CTX_cleanup(digest-ctx);
! px_free(digest);
px_free(h);
}
***
*** 101,108
px_find_digest(const char *name, PX_MD ** res)
{
const EVP_MD *md;
- EVP_MD_CTX *ctx;
PX_MD *h;
if (!px_openssl_initialized)
{
--- 130,137
px_find_digest(const char *name, PX_MD ** res)
{
const EVP_MD *md;
PX_MD *h;
+ OSSLDigest *digest;
if (!px_openssl_initialized)
{
***
*** 114,121
if (md == NULL)
return -1;
! ctx = px_alloc(sizeof(*ctx));
! EVP_DigestInit(ctx, md);
h = px_alloc(sizeof(*h));
h-result_size = digest_result_size;
--- 143,154
if (md == NULL)
return -1;
! digest = px_alloc(sizeof(*digest));
! digest-algo = md;
!
! EVP_MD_CTX_init(digest-ctx);
! if (EVP_DigestInit_ex(digest-ctx, digest-algo, NULL) == 0)
! return -1;
h = px_alloc(sizeof(*h));
h-result_size = digest_result_size;
***
*** 124,130
h-update = digest_update;
h-finish = digest_finish;
h-free = digest_free;
! h-p.ptr = (void *) ctx;
*res = h;
return 0;
--- 157,163
h-update = digest_update;
h-finish = digest_finish;
h-free = digest_free;
! h-p.ptr = (void *) digest;
*res = h;
return 0;
Re: [PATCHES] pgcrypto: bug in gen_salt (md5/xdes)
Marko Kreen [EMAIL PROTECTED] writes: There is a signedness bug in Openwall gen_salt code that pgcrypto uses. This makes the salt space for md5 and xdes algorithms a lot smaller. Salts for blowfish and standard des are unaffected. Attached is upstream fix for it. This applies all the way from 7.2 to 8.1 and HEAD. Please apply this to all active branches. Applied back to 7.3 ... we are not maintaining 7.2 anymore. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] pgcrypto: bug in gen_salt (md5/xdes)
There is a signedness bug in Openwall gen_salt code that
pgcrypto uses. This makes the salt space for md5 and xdes
algorithms a lot smaller.
Salts for blowfish and standard des are unaffected.
Attached is upstream fix for it. This applies all the
way from 7.2 to 8.1 and HEAD. Please apply this to all
active branches.
--
marko
Index: contrib/pgcrypto/crypt-gensalt.c
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/crypt-gensalt.c,v
retrieving revision 1.6
diff -u -c -r1.6 crypt-gensalt.c
*** contrib/pgcrypto/crypt-gensalt.c 15 Oct 2005 02:49:06 - 1.6
--- contrib/pgcrypto/crypt-gensalt.c 2 Jan 2006 22:27:35 -
***
*** 62,70
output[2] = _crypt_itoa64[(count 6) 0x3f];
output[3] = _crypt_itoa64[(count 12) 0x3f];
output[4] = _crypt_itoa64[(count 18) 0x3f];
! value = (unsigned long) input[0] |
! ((unsigned long) input[1] 8) |
! ((unsigned long) input[2] 16);
output[5] = _crypt_itoa64[value 0x3f];
output[6] = _crypt_itoa64[(value 6) 0x3f];
output[7] = _crypt_itoa64[(value 12) 0x3f];
--- 62,70
output[2] = _crypt_itoa64[(count 6) 0x3f];
output[3] = _crypt_itoa64[(count 12) 0x3f];
output[4] = _crypt_itoa64[(count 18) 0x3f];
! value = (unsigned long)(unsigned char) input[0] |
! ((unsigned long)(unsigned char) input[1] 8) |
! ((unsigned long)(unsigned char) input[2] 16);
output[5] = _crypt_itoa64[value 0x3f];
output[6] = _crypt_itoa64[(value 6) 0x3f];
output[7] = _crypt_itoa64[(value 12) 0x3f];
***
*** 90,98
output[0] = '$';
output[1] = '1';
output[2] = '$';
! value = (unsigned long) input[0] |
! ((unsigned long) input[1] 8) |
! ((unsigned long) input[2] 16);
output[3] = _crypt_itoa64[value 0x3f];
output[4] = _crypt_itoa64[(value 6) 0x3f];
output[5] = _crypt_itoa64[(value 12) 0x3f];
--- 90,98
output[0] = '$';
output[1] = '1';
output[2] = '$';
! value = (unsigned long)(unsigned char) input[0] |
! ((unsigned long)(unsigned char) input[1] 8) |
! ((unsigned long)(unsigned char) input[2] 16);
output[3] = _crypt_itoa64[value 0x3f];
output[4] = _crypt_itoa64[(value 6) 0x3f];
output[5] = _crypt_itoa64[(value 12) 0x3f];
***
*** 101,109
if (size = 6 output_size = 3 + 4 + 4 + 1)
{
! value = (unsigned long) input[3] |
! ((unsigned long) input[4] 8) |
! ((unsigned long) input[5] 16);
output[7] = _crypt_itoa64[value 0x3f];
output[8] = _crypt_itoa64[(value 6) 0x3f];
output[9] = _crypt_itoa64[(value 12) 0x3f];
--- 101,109
if (size = 6 output_size = 3 + 4 + 4 + 1)
{
! value = (unsigned long)(unsigned char) input[3] |
! ((unsigned long)(unsigned char) input[4] 8) |
! ((unsigned long)(unsigned char) input[5] 16);
output[7] = _crypt_itoa64[value 0x3f];
output[8] = _crypt_itoa64[(value 6) 0x3f];
output[9] = _crypt_itoa64[(value 12) 0x3f];
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] pgcrypto doc polish
Marko Kreen marko@l-t.ee writes: Few small things: [ snip ] Applied, thanks. I also fixed a few small grammatical problems in the text. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[PATCHES] pgcrypto doc polish
Few small things: - Mention pgcrypto.sql - Mention asciidoc. To hint that occasional weird formatting is not random. - Clarify few senctences. - Remove anything related to MySQL password(). It was interesting to look at, but it should not be mentioned in serious conversation. Also, they have replaced it in 4.1 with SHA1, so the crap implementation is best forgotten. -- marko Index: contrib/pgcrypto/README.pgcrypto === RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/README.pgcrypto,v retrieving revision 1.13 diff -u -c -r1.13 README.pgcrypto *** contrib/pgcrypto/README.pgcrypto13 Aug 2005 02:06:20 - 1.13 --- contrib/pgcrypto/README.pgcrypto1 Nov 2005 22:56:42 - *** *** 3,8 --- 3,10 = Marko Kreen marko@l-t.ee + // Note: this document is in asciidoc format. + 1. Installation - *** *** 17,22 --- 19,31 for the module. They make sure the functions here produce correct results. + Next, to get the function into particular database, run commands in + file pgcrypto.sql, which should be installed into shared files directory. + + Example using psql: + + psql -d DBNAME -f pgcrypto.sql + 2. Notes -- *** *** 248,254 crypt-des 3628377 days 19 years sha1 5902234 days 12 years md5 2345086 1 day 3 years - password 143781000 25 mins 18 days * The machine used is 1.5GHz Pentium 4. --- 257,262 *** *** 256,263 John the Ripper v1.6.38 `-test` output. * MD5 numbers are from mdcrack 1.2. * SHA1 numbers are from lcrack-20031130-beta. - * MySQL password() numbers are from my own tests. - (http://grue.l-t.ee/~marko/src/mypass/) * `crypt-bf` numbers are taken using simple program that loops over 1000 8-character passwords. That way I can show the speed with different number of rounds. For reference: `john -test` shows 213 --- 264,269 *** *** 268,276 Note that the try all combinations is not a realistic exercise. Usually password cracking is done with the help of dictionaries, which contain both regular words and various mutations of them. So, even ! somewhat word-like passwords will be cracked much faster than the above numbers suggest, and a 6-character non-word like password may escape ! cracking. Or may not. 5. PGP encryption --- 274,282 Note that the try all combinations is not a realistic exercise. Usually password cracking is done with the help of dictionaries, which contain both regular words and various mutations of them. So, even ! somewhat word-like passwords could be cracked much faster than the above numbers suggest, and a 6-character non-word like password may escape ! cracking. Or not. 5. PGP encryption ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] pgcrypto BYTE_ORDER fix for stable branches
Recently was uncovered that pgcrypto does not include
right header file to get BYTE_ORDER define on Cygwin
and MINGW, and the missing define does not result in
build failures, but random combinations of little and
big-endian code sections.
This patch adds missing sys/param.h include for md5.c,
sha1.c and rijndael.c plus also check to catch undefined
BYTE_ORDER.
The patch applies cleanly and is tested on branches
for versions 7.2, 7.3, 7.4 and 8.0. There are also
no failures on buildfarm for HEAD, where this patch
is already included.
--
marko
Index: contrib/pgcrypto/md5.c
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/md5.c,v
retrieving revision 1.9
diff -u -c -r1.9 md5.c
*** contrib/pgcrypto/md5.c 29 Nov 2001 19:40:37 - 1.9
--- contrib/pgcrypto/md5.c 13 Jul 2005 14:14:07 -
***
*** 31,40
*/
#include postgres.h
- #include px.h
#include md5.h
#define SHIFT(X, s) (((X) (s)) | ((X) (32 - (s
#define F(X, Y, Z) (((X) (Y)) | ((~X) (Z)))
--- 31,47
*/
#include postgres.h
+ #include sys/param.h
+
+ #include px.h
#include md5.h
+ /* sanity check */
+ #if !defined(BYTE_ORDER) || (BYTE_ORDER != LITTLE_ENDIAN BYTE_ORDER !=
BIG_ENDIAN)
+ #error Define BYTE_ORDER to be equal to either LITTLE_ENDIAN or BIG_ENDIAN
+ #endif
+
#define SHIFT(X, s) (((X) (s)) | ((X) (32 - (s
#define F(X, Y, Z) (((X) (Y)) | ((~X) (Z)))
Index: contrib/pgcrypto/rijndael.c
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/rijndael.c,v
retrieving revision 1.9
diff -u -c -r1.9 rijndael.c
*** contrib/pgcrypto/rijndael.c 5 Sep 2002 21:08:26 - 1.9
--- contrib/pgcrypto/rijndael.c 13 Jul 2005 14:15:43 -
***
*** 38,48
*/
! #include postgres.h
#include px.h
#include rijndael.h
#define PRE_CALC_TABLES
#define LARGE_TABLES
--- 38,56
*/
! #include postgres.h
!
! #include sys/param.h
!
#include px.h
#include rijndael.h
+ /* sanity check */
+ #if !defined(BYTE_ORDER) || (BYTE_ORDER != LITTLE_ENDIAN BYTE_ORDER !=
BIG_ENDIAN)
+ #error Define BYTE_ORDER to be equal to either LITTLE_ENDIAN or BIG_ENDIAN
+ #endif
+
#define PRE_CALC_TABLES
#define LARGE_TABLES
Index: contrib/pgcrypto/sha1.c
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/sha1.c,v
retrieving revision 1.11
diff -u -c -r1.11 sha1.c
*** contrib/pgcrypto/sha1.c 29 Nov 2001 19:40:37 - 1.11
--- contrib/pgcrypto/sha1.c 13 Jul 2005 14:15:05 -
***
*** 36,53
*/
#include postgres.h
#include px.h
#include sha1.h
/* sanity check */
! #if BYTE_ORDER != BIG_ENDIAN
! #if BYTE_ORDER != LITTLE_ENDIAN
! #define unsupported 1
#endif
- #endif
-
- #ifndef unsupported
/* constant table */
static uint32 _K[] = {0x5a827999, 0x6ed9eba1, 0x8f1bbcdc, 0xca62c1d6};
--- 36,52
*/
#include postgres.h
+
+ #include sys/param.h
+
#include px.h
#include sha1.h
/* sanity check */
! #if !defined(BYTE_ORDER) || (BYTE_ORDER != LITTLE_ENDIAN BYTE_ORDER !=
BIG_ENDIAN)
! #error Define BYTE_ORDER to be equal to either LITTLE_ENDIAN or BIG_ENDIAN
#endif
/* constant table */
static uint32 _K[] = {0x5a827999, 0x6ed9eba1, 0x8f1bbcdc, 0xca62c1d6};
***
*** 347,350
#endif
}
- #endif /* unsupported */
--- 346,348
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
[PATCHES] pgcrypto warnings for Sun's cc
This patch removes a couple of warnings Sun's cc reports in
contrib/pgcrypto.
cc -Xa -v -g -KPIC -I. -I../../src/include -I/usr/local/include -c -o sha2.o
sha2.c
sha2.c, line 173: warning: storage class after type is obsolescent
sha2.c, line 193: warning: storage class after type is obsolescent
sha2.c, line 205: warning: storage class after type is obsolescent
sha2.c, line 249: warning: storage class after type is obsolescent
sha2.c, line 261: warning: storage class after type is obsolescent
Kris JurkaIndex: contrib/pgcrypto/sha2.c
===
RCS file: /projects/cvsroot/pgsql/contrib/pgcrypto/sha2.c,v
retrieving revision 1.3
diff -c -r1.3 sha2.c
*** contrib/pgcrypto/sha2.c 11 Jul 2005 15:40:38 - 1.3
--- contrib/pgcrypto/sha2.c 12 Jul 2005 18:00:03 -
***
*** 170,176
/*** SHA-XYZ INITIAL HASH VALUES AND CONSTANTS /
/* Hash constant words K for SHA-256: */
! const static uint32 K256[64] = {
0x428a2f98UL, 0x71374491UL, 0xb5c0fbcfUL, 0xe9b5dba5UL,
0x3956c25bUL, 0x59f111f1UL, 0x923f82a4UL, 0xab1c5ed5UL,
0xd807aa98UL, 0x12835b01UL, 0x243185beUL, 0x550c7dc3UL,
--- 170,176
/*** SHA-XYZ INITIAL HASH VALUES AND CONSTANTS /
/* Hash constant words K for SHA-256: */
! static const uint32 K256[64] = {
0x428a2f98UL, 0x71374491UL, 0xb5c0fbcfUL, 0xe9b5dba5UL,
0x3956c25bUL, 0x59f111f1UL, 0x923f82a4UL, 0xab1c5ed5UL,
0xd807aa98UL, 0x12835b01UL, 0x243185beUL, 0x550c7dc3UL,
***
*** 190,196
};
/* Initial hash value H for SHA-256: */
! const static uint32 sha256_initial_hash_value[8] = {
0x6a09e667UL,
0xbb67ae85UL,
0x3c6ef372UL,
--- 190,196
};
/* Initial hash value H for SHA-256: */
! static const uint32 sha256_initial_hash_value[8] = {
0x6a09e667UL,
0xbb67ae85UL,
0x3c6ef372UL,
***
*** 202,208
};
/* Hash constant words K for SHA-384 and SHA-512: */
! const static uint64 K512[80] = {
0x428a2f98d728ae22ULL, 0x7137449123ef65cdULL,
0xb5c0fbcfec4d3b2fULL, 0xe9b5dba58189dbbcULL,
0x3956c25bf348b538ULL, 0x59f111f1b605d019ULL,
--- 202,208
};
/* Hash constant words K for SHA-384 and SHA-512: */
! static const uint64 K512[80] = {
0x428a2f98d728ae22ULL, 0x7137449123ef65cdULL,
0xb5c0fbcfec4d3b2fULL, 0xe9b5dba58189dbbcULL,
0x3956c25bf348b538ULL, 0x59f111f1b605d019ULL,
***
*** 246,252
};
/* Initial hash value H for SHA-384 */
! const static uint64 sha384_initial_hash_value[8] = {
0xcbbb9d5dc1059ed8ULL,
0x629a292a367cd507ULL,
0x9159015a3070dd17ULL,
--- 246,252
};
/* Initial hash value H for SHA-384 */
! static const uint64 sha384_initial_hash_value[8] = {
0xcbbb9d5dc1059ed8ULL,
0x629a292a367cd507ULL,
0x9159015a3070dd17ULL,
***
*** 258,264
};
/* Initial hash value H for SHA-512 */
! const static uint64 sha512_initial_hash_value[8] = {
0x6a09e667f3bcc908ULL,
0xbb67ae8584caa73bULL,
0x3c6ef372fe94f82bULL,
--- 258,264
};
/* Initial hash value H for SHA-512 */
! static const uint64 sha512_initial_hash_value[8] = {
0x6a09e667f3bcc908ULL,
0xbb67ae8584caa73bULL,
0x3c6ef372fe94f82bULL,
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] pgcrypto warnings for Sun's cc
Kris Jurka [EMAIL PROTECTED] writes: This patch removes a couple of warnings Sun's cc reports in contrib/pgcrypto. Applied, thanks. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] pgcrypto: OpenSSL/DES cleanup
Patch applied. Thanks. --- Marko Kreen wrote: As Kris Jurka found out, pgcrypto does not work with OpenSSL 0.9.6x. The DES functions use the older 'des_' API, but the newer 3DES functions use the 0.9.7x-only 'DES_' API. I think I just used /usr/include/openssl/des.h for reference when implementing them, and had upgraded OpenSSL in the meantime. Following patch converts DES also to newer API and provides compatibility functions for OpenSSL 0.9.7. I chose this route because: - openssl.c uses few DES functions. - compatibility for old 'des_' API is going away at some point of time from OpenSSL. - as seen from macros, new API is saner - Thus pgcrypto supports any OpenSSL version from 0.9.5 to 1.0 Tested with OpenSSL 0.9.6c and 0.9.7e. -- marko PS. It's nice to see that the 'autoconfiguration' already pays back. [ Attachment, skipping... ] ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] pgcrypto volatility and strictness changes
Michael Fuhr wrote: This patch updates the DDL for contrib/pgcrypto to create all functions as STRICT, and all functions except gen_salt() as IMMUTABLE. gen_salt() is VOLATILE. Barring any objections, I'll apply this tomorrow. -Neil ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] pgcrypto: OpenSSL/DES cleanup
As Kris Jurka found out, pgcrypto does not work with
OpenSSL 0.9.6x. The DES functions use the older 'des_'
API, but the newer 3DES functions use the 0.9.7x-only
'DES_' API.
I think I just used /usr/include/openssl/des.h for reference
when implementing them, and had upgraded OpenSSL in the
meantime.
Following patch converts DES also to newer API and provides
compatibility functions for OpenSSL 0.9.7.
I chose this route because:
- openssl.c uses few DES functions.
- compatibility for old 'des_' API is going away at some point
of time from OpenSSL.
- as seen from macros, new API is saner
- Thus pgcrypto supports any OpenSSL version from 0.9.5 to 1.0
Tested with OpenSSL 0.9.6c and 0.9.7e.
--
marko
PS. It's nice to see that the 'autoconfiguration' already pays
back.
Index: contrib/pgcrypto/openssl.c
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/openssl.c,v
retrieving revision 1.20
diff -u -c -r1.20 openssl.c
*** contrib/pgcrypto/openssl.c 5 Jul 2005 18:15:36 - 1.20
--- contrib/pgcrypto/openssl.c 7 Jul 2005 09:18:37 -
***
*** 48,53
--- 48,73
#endif
/*
+ * Compatibility with older OpenSSL API for DES.
+ */
+ #if OPENSSL_VERSION_NUMBER 0x00907000L
+ #define DES_key_schedule des_key_schedule
+ #define DES_cblock des_cblock
+ #define DES_set_key(k, ks) \
+ des_set_key((k), *(ks))
+ #define DES_ecb_encrypt(i, o, k, e) \
+ des_ecb_encrypt((i), (o), *(k), (e))
+ #define DES_ncbc_encrypt(i, o, l, k, iv, e) \
+ des_ncbc_encrypt((i), (o), (l), *(k), (iv), (e))
+ #define DES_ecb3_encrypt(i, o, k1, k2, k3, e) \
+ des_ecb3_encrypt((des_cblock *)(i), (des_cblock *)(o), \
+ *(k1), *(k2), *(k3), (e))
+ #define DES_ede3_cbc_encrypt(i, o, l, k1, k2, k3, iv, e) \
+ des_ede3_cbc_encrypt((i), (o), \
+ (l), *(k1), *(k2), *(k3), (iv), (e))
+ #endif
+
+ /*
* Hashes
*/
static unsigned
***
*** 175,185
} bf;
struct
{
! des_key_schedule key_schedule;
} des;
struct
{
! des_key_schedule k1, k2, k3;
} des3;
CAST_KEYcast_key;
#ifdef GOT_AES
--- 195,205
} bf;
struct
{
! DES_key_schedule key_schedule;
} des;
struct
{
! DES_key_schedule k1, k2, k3;
} des3;
CAST_KEYcast_key;
#ifdef GOT_AES
***
*** 315,325
ossl_des_init(PX_Cipher * c, const uint8 *key, unsigned klen, const uint8 *iv)
{
ossldata *od = c-ptr;
! des_cblock xkey;
memset(xkey, 0, sizeof(xkey));
memcpy(xkey, key, klen 8 ? 8 : klen);
! des_set_key(xkey, od-u.des.key_schedule);
memset(xkey, 0, sizeof(xkey));
if (iv)
--- 335,345
ossl_des_init(PX_Cipher * c, const uint8 *key, unsigned klen, const uint8 *iv)
{
ossldata *od = c-ptr;
! DES_cblock xkey;
memset(xkey, 0, sizeof(xkey));
memcpy(xkey, key, klen 8 ? 8 : klen);
! DES_set_key(xkey, od-u.des.key_schedule);
memset(xkey, 0, sizeof(xkey));
if (iv)
***
*** 338,346
ossldata *od = c-ptr;
for (i = 0; i dlen / bs; i++)
! des_ecb_encrypt((des_cblock *) (data + i * bs),
! (des_cblock *) (res + i * bs),
! od-u.des.key_schedule, 1);
return 0;
}
--- 358,366
ossldata *od = c-ptr;
for (i = 0; i dlen / bs; i++)
! DES_ecb_encrypt((DES_cblock *) (data + i * bs),
! (DES_cblock *) (res + i * bs),
! od-u.des.key_schedule, 1);
return 0;
}
***
*** 353,361
ossldata *od = c-ptr;
for (i = 0; i dlen / bs; i++)
! des_ecb_encrypt((des_cblock *) (data + i * bs),
! (des_cblock *) (res + i * bs),
! od-u.des.key_schedule, 0);
return 0;
}
--- 373,381
ossldata *od = c-ptr;
for (i = 0; i dlen / bs; i++)
! DES_ecb_encrypt((DES_cblock *) (data + i * bs),
! (DES_cblock *) (res + i * bs),
! od-u.des.key_schedule, 0);
return 0;
}
***
***
Re: [PATCHES] pgcrypto: OpenSSL/DES cleanup
On Thu, Jul 07, 2005 at 12:25:53PM +0300, Marko Kreen wrote: Tested with OpenSSL 0.9.6c and 0.9.7e. I just applied this patch to my system running HEAD and OpenSSL 0.9.8; all regression tests passed. BTW, OpenSSL 0.9.8 has been released: http://www.mail-archive.com/openssl-announce@openssl.org/msg00063.html -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] pgcrypto volatility and strictness changes
Michael Fuhr wrote: This patch updates the DDL for contrib/pgcrypto to create all functions as STRICT, and all functions except gen_salt() as IMMUTABLE. gen_salt() is VOLATILE. Applied, thanks. -Neil ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] pgcrypto volatility and strictness changes
This patch updates the DDL for contrib/pgcrypto to create all functions as STRICT, and all functions except gen_salt() as IMMUTABLE. gen_salt() is VOLATILE. Although the functions are now STRICT, I left their PG_ARGISNULL() checks in place as a protective measure for users who install the new code but use old (non-STRICT) catalog entries (e.g., restored from a dump). Per recent discussion in pgsql-hackers. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ Index: contrib/pgcrypto/pgcrypto.sql.in === RCS file: /projects/cvsroot/pgsql/contrib/pgcrypto/pgcrypto.sql.in,v retrieving revision 1.9 diff -c -r1.9 pgcrypto.sql.in *** contrib/pgcrypto/pgcrypto.sql.in14 May 2003 03:25:56 - 1.9 --- contrib/pgcrypto/pgcrypto.sql.in5 Jul 2005 14:11:45 - *** *** 4,74 CREATE OR REPLACE FUNCTION digest(text, text) RETURNS bytea AS 'MODULE_PATHNAME', 'pg_digest' ! LANGUAGE 'C'; CREATE OR REPLACE FUNCTION digest(bytea, text) RETURNS bytea AS 'MODULE_PATHNAME', 'pg_digest' ! LANGUAGE 'C'; CREATE OR REPLACE FUNCTION digest_exists(text) RETURNS bool AS 'MODULE_PATHNAME', 'pg_digest_exists' ! LANGUAGE 'C'; CREATE OR REPLACE FUNCTION hmac(text, text, text) RETURNS bytea AS 'MODULE_PATHNAME', 'pg_hmac' ! LANGUAGE 'C'; CREATE OR REPLACE FUNCTION hmac(bytea, bytea, text) RETURNS bytea AS 'MODULE_PATHNAME', 'pg_hmac' ! LANGUAGE 'C'; CREATE OR REPLACE FUNCTION hmac_exists(text) RETURNS bool AS 'MODULE_PATHNAME', 'pg_hmac_exists' ! LANGUAGE 'C'; CREATE OR REPLACE FUNCTION crypt(text, text) RETURNS text AS 'MODULE_PATHNAME', 'pg_crypt' ! LANGUAGE 'C'; CREATE OR REPLACE FUNCTION gen_salt(text) RETURNS text AS 'MODULE_PATHNAME', 'pg_gen_salt' ! LANGUAGE 'C'; CREATE OR REPLACE FUNCTION gen_salt(text, int4) RETURNS text AS 'MODULE_PATHNAME', 'pg_gen_salt_rounds' ! LANGUAGE 'C'; CREATE OR REPLACE FUNCTION encrypt(bytea, bytea, text) RETURNS bytea AS 'MODULE_PATHNAME', 'pg_encrypt' ! LANGUAGE 'C'; CREATE OR REPLACE FUNCTION decrypt(bytea, bytea, text) RETURNS bytea AS 'MODULE_PATHNAME', 'pg_decrypt' ! LANGUAGE 'C'; CREATE OR REPLACE FUNCTION encrypt_iv(bytea, bytea, bytea, text) RETURNS bytea AS 'MODULE_PATHNAME', 'pg_encrypt_iv' ! LANGUAGE 'C'; CREATE OR REPLACE FUNCTION decrypt_iv(bytea, bytea, bytea, text) RETURNS bytea AS 'MODULE_PATHNAME', 'pg_decrypt_iv' ! LANGUAGE 'C'; CREATE OR REPLACE FUNCTION cipher_exists(text) RETURNS bool AS 'MODULE_PATHNAME', 'pg_cipher_exists' ! LANGUAGE 'C'; --- 4,74 CREATE OR REPLACE FUNCTION digest(text, text) RETURNS bytea AS 'MODULE_PATHNAME', 'pg_digest' ! LANGUAGE 'C' IMMUTABLE STRICT; CREATE OR REPLACE FUNCTION digest(bytea, text) RETURNS bytea AS 'MODULE_PATHNAME', 'pg_digest' ! LANGUAGE 'C' IMMUTABLE STRICT; CREATE OR REPLACE FUNCTION digest_exists(text) RETURNS bool AS 'MODULE_PATHNAME', 'pg_digest_exists' ! LANGUAGE 'C' IMMUTABLE STRICT; CREATE OR REPLACE FUNCTION hmac(text, text, text) RETURNS bytea AS 'MODULE_PATHNAME', 'pg_hmac' ! LANGUAGE 'C' IMMUTABLE STRICT; CREATE OR REPLACE FUNCTION hmac(bytea, bytea, text) RETURNS bytea AS 'MODULE_PATHNAME', 'pg_hmac' ! LANGUAGE 'C' IMMUTABLE STRICT; CREATE OR REPLACE FUNCTION hmac_exists(text) RETURNS bool AS 'MODULE_PATHNAME', 'pg_hmac_exists' ! LANGUAGE 'C' IMMUTABLE STRICT; CREATE OR REPLACE FUNCTION crypt(text, text) RETURNS text AS 'MODULE_PATHNAME', 'pg_crypt' ! LANGUAGE 'C' IMMUTABLE STRICT; CREATE OR REPLACE FUNCTION gen_salt(text) RETURNS text AS 'MODULE_PATHNAME', 'pg_gen_salt' ! LANGUAGE 'C' VOLATILE STRICT; CREATE OR REPLACE FUNCTION gen_salt(text, int4) RETURNS text AS 'MODULE_PATHNAME', 'pg_gen_salt_rounds' ! LANGUAGE 'C' VOLATILE STRICT; CREATE OR REPLACE FUNCTION encrypt(bytea, bytea, text) RETURNS bytea AS 'MODULE_PATHNAME', 'pg_encrypt' ! LANGUAGE 'C' IMMUTABLE STRICT; CREATE OR REPLACE FUNCTION decrypt(bytea, bytea, text) RETURNS bytea AS 'MODULE_PATHNAME', 'pg_decrypt' ! LANGUAGE 'C' IMMUTABLE STRICT; CREATE OR REPLACE FUNCTION encrypt_iv(bytea, bytea, bytea, text) RETURNS bytea AS 'MODULE_PATHNAME', 'pg_encrypt_iv' ! LANGUAGE 'C' IMMUTABLE STRICT; CREATE OR REPLACE FUNCTION decrypt_iv(bytea, bytea, bytea, text) RETURNS bytea AS 'MODULE_PATHNAME', 'pg_decrypt_iv' ! LANGUAGE 'C' IMMUTABLE STRICT; CREATE OR REPLACE FUNCTION cipher_exists(text) RETURNS bool AS 'MODULE_PATHNAME', 'pg_cipher_exists' ! LANGUAGE 'C' IMMUTABLE STRICT; ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] pgcrypto: openssl digest fix
Marko Kreen wrote: Ah, ofcourse. The patch seems rather large to be applying to 7.3 and 7.2 -- but it's your contrib/ module, so I'll assume you're pretty confident this doesn't cause any regressions... I'll apply the patch to 7.3 and 7.2 stable branches tomorrow. -Neil ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] pgcrypto: openssl digest fix
On Sun, Mar 13, 2005 at 09:43:02PM +1100, Neil Conway wrote: Marko Kreen wrote: Ah, ofcourse. The patch seems rather large to be applying to 7.3 and 7.2 -- but it's your contrib/ module, so I'll assume you're pretty confident this doesn't cause any regressions... The patch itself is simply cvs diff -r1.10 -r1.11 openssl.c, so there should not be any recent typos in it. Now I also tested it with both REL7_3_STABLE and REL7_2_STABLE and found no problems. So I think its fine. I'll apply the patch to 7.3 and 7.2 stable branches tomorrow. Cool. -- marko ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] pgcrypto: openssl digest fix
On Sat, Mar 12, 2005 at 05:59:24PM +1100, Neil Conway wrote: Marko Kreen wrote: Please apply this also to stable branches (8.0 / 7.4). Should it be backpatched to 7.3 and 7.2 as well? It would be nice. I didn't know there are releases of those planned as well. Now looking into it, 7.3 and 7.2 branch are missing the OpenSSL EVP cipher functions removal patch - which is even more nasty as it does not crash but silently corrupts data. 'make installcheck' detects it, but if somebody forgets to run it... (Thankfully encrypt()/decrypt() are not used much.) Would you apply this one aswell? I see that the original patch (openssl.c r1.11) applies to both branches without problems. It is a bit larger than this one tho'. -- marko ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] pgcrypto: openssl digest fix
Some builds (depends on crypto engine support?) of OpenSSL
0.9.7x have EVP_DigestFinal function which which clears all of
EVP_MD_CTX. This makes pgcrypto crash in functions which
re-use one digest context several times: hmac() and crypt()
with md5 algorithm.
Following patch fixes it by carring the digest info around
EVP_DigestFinal and re-initializing cipher.
Please apply this also to stable branches (8.0 / 7.4).
Note that this can be blamed on OpenSSL 0.9.7x backwards-
compatibility functions: 0.9.6x and new 0.9.7x API
(EVP_DigestFinal_ex) do clear the secret data but keep the
general algorithm info.
But still, the fact is that pgcrypto was relying on
undocumented beheviour.
--
marko
Index: contrib/pgcrypto/openssl.c
===
RCS file: /opt/cvs2/pgsql/contrib/pgcrypto/openssl.c,v
retrieving revision 1.13
diff -u -c -r1.13 openssl.c
*** contrib/pgcrypto/openssl.c 29 Nov 2003 22:39:28 - 1.13
--- contrib/pgcrypto/openssl.c 11 Mar 2005 15:39:34 -
***
*** 73,80
--- 73,87
digest_finish(PX_MD * h, uint8 *dst)
{
EVP_MD_CTX *ctx = (EVP_MD_CTX *) h-p.ptr;
+ const EVP_MD *md = EVP_MD_CTX_md(ctx);
EVP_DigestFinal(ctx, dst, NULL);
+
+ /*
+* Some builds of 0.9.7x clear all of ctx in EVP_DigestFinal.
+* Fix it by reinitializing ctx.
+*/
+ EVP_DigestInit(ctx, md);
}
static void
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] pgcrypto: openssl digest fix
Marko Kreen wrote: Some builds (depends on crypto engine support?) of OpenSSL 0.9.7x have EVP_DigestFinal function which which clears all of EVP_MD_CTX. This makes pgcrypto crash in functions which re-use one digest context several times: hmac() and crypt() with md5 algorithm. Following patch fixes it by carring the digest info around EVP_DigestFinal and re-initializing cipher. Applied to HEAD, REL8_0_STABLE and REL7_4_STABLE. Thanks for the patch. Please apply this also to stable branches (8.0 / 7.4). Should it be backpatched to 7.3 and 7.2 as well? -Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] pgcrypto: Makefile check
Neil Conway [EMAIL PROTECTED] writes: This patch makes the pgcrypto Makefile check that a recognized random source has been defined. If no such source is defined, pgcrypto will compile successfully but will be unusable. Oh? +$(error Unrecognized random source: $(random)) Doesn't look like a successful compile to me. What's worse, this would also cause maintenance operations (like make clean) to fail. (I see little point in this anyway given that the makefile defaults to random = silly further up.) regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] pgcrypto: Makefile check
Perhaps I wasn't clear: the *present* behavior of pgcrypto is to compile successfully but ... be unusable if an invalid random source is defined. This is prone to error. That patch changes this behavior to refuse to compile if an invalid random source has been defined. On Mon, 2004-11-22 at 10:46 -0500, Tom Lane wrote: +$(error Unrecognized random source: $(random)) Doesn't look like a successful compile to me. Right, that's the whole point. What's worse, this would also cause maintenance operations (like make clean) to fail. I don't think this is a problem (an invalid random source is effectively a misconfiguration and could only be the result of user error). But if you like I can change the patch so that we error out when attempting to compile random.c (I see little point in this anyway given that the makefile defaults to random = silly further up.) This patch was specifically motivated by a user who was confused when they edited the Makefile, compiled pgcrypto, and couldn't use it -- as it turned out the random source was defined with trailing whitespace. I think the Makefile syntax is sufficiently esoteric that some error checking would be helpful. -Neil ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] pgcrypto: Makefile check
Neil Conway [EMAIL PROTECTED] writes: Perhaps I wasn't clear: the *present* behavior of pgcrypto is to compile successfully but ... be unusable if an invalid random source is defined. This is prone to error. That patch changes this behavior to refuse to compile if an invalid random source has been defined. Ah, got it. I don't think this is a problem (an invalid random source is effectively a misconfiguration and could only be the result of user error). But if you like I can change the patch so that we error out when attempting to compile random.c Please do; I dislike makefiles that won't make clean ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] pgcrypto: Makefile check
On Mon, 2004-11-22 at 19:10 -0500, Tom Lane wrote: Please do; I dislike makefiles that won't make clean ... Attached is a revised patch. Will apply in a few hours barring any objections. -Neil # # patch contrib/pgcrypto/random.c # from [2815b119334369b864e6b39fe21832b299fd235c] #to [3c5f5c8fffc36fac3076296a3bab1a2bfdb7a20b] # --- contrib/pgcrypto/random.c +++ contrib/pgcrypto/random.c @@ -35,7 +35,7 @@ #include px.h -#ifdef RAND_DEV +#if defined(RAND_DEV) #include errno.h #include fcntl.h @@ -77,9 +77,8 @@ close(fd); return res; } -#endif /* RAND_DEV */ -#ifdef RAND_SILLY +#elif defined(RAND_SILLY) int px_get_random_bytes(uint8 *dst, unsigned count) @@ -90,9 +89,8 @@ *dst++ = random(); return i; } -#endif /* RAND_SILLY */ -#ifdef RAND_OPENSSL +#elif defined(RAND_OPENSSL) #include openssl/evp.h #include openssl/blowfish.h @@ -125,4 +123,6 @@ return -1; } +#else +#error Invalid random source +#endif -#endif /* RAND_OPENSSL */ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[PATCHES] pgcrypto: Makefile check
This patch makes the pgcrypto Makefile check that a recognized random source has been defined. If no such source is defined, pgcrypto will compile successfully but will be unusable. (An alternative place to do the check would be in random.c; comments on which location is preferrable are welcome.) Barring any objections I will apply this to HEAD later tonight. -Neil # # patch contrib/pgcrypto/Makefile # from [c549a19bc0a0ff6582bb02e37d2db011c1e0cf01] #to [709404895862b1734a4c1af7ca0f9fb423097c0a] # --- contrib/pgcrypto/Makefile +++ contrib/pgcrypto/Makefile @@ -48,13 +48,17 @@ ifeq ($(random), dev) CRYPTO_CFLAGS += -DRAND_DEV=$(random_dev) -endif +else ifeq ($(random), openssl) CRYPTO_CFLAGS += -DRAND_OPENSSL -endif +else ifeq ($(random), silly) CRYPTO_CFLAGS += -DRAND_SILLY +else +$(error Unrecognized random source: $(random)) endif +endif +endif SRCS += pgcrypto.c px.c px-hmac.c px-crypt.c misc.c \ crypt-gensalt.c random.c ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] pgcrypto: make const array static
On Mon, 2004-10-04 at 15:23, Neil Conway wrote: This one-line patches merges a micro-opt from upstream (OpenBSD) sources: we can make a read-only local array static and reduce the size of the generated object file slightly. Patch applied. -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[PATCHES] pgcrypto: make const array static
This one-line patches merges a micro-opt from upstream (OpenBSD)
sources: we can make a read-only local array static and reduce the
size of the generated object file slightly.
Barring any objections, I intend to apply this patch today or tomorrow.
-Neil
Index: contrib/pgcrypto/blf.c
===
RCS file: /Users/neilc/local/cvs/pgsql-server/contrib/pgcrypto/blf.c,v
retrieving revision 1.5
diff -c -r1.5 blf.c
*** contrib/pgcrypto/blf.c 29 Jan 2002 15:40:45 - 1.5
--- contrib/pgcrypto/blf.c 3 Oct 2004 16:07:31 -
***
*** 126,132
/* P-box and S-box tables initialized with digits of Pi */
! const blf_ctx initstate =
{{
{
--- 126,132
/* P-box and S-box tables initialized with digits of Pi */
! static const blf_ctx initstate =
{{
{
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
