Skip site navigation (1) Skip section navigation (2)

Re: pgcrypto & strong ciphers limitation

From: "Marko Kreen" <markokr(at)gmail(dot)com>
To: "Zdenek Kotala" <Zdenek(dot)Kotala(at)sun(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, "Stefan Kaltenbrunner" <stefan(at)kaltenbrunner(dot)cc>
Subject: Re: pgcrypto & strong ciphers limitation
Date: 2007-07-24 19:05:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 7/24/07, Zdenek Kotala <Zdenek(dot)Kotala(at)sun(dot)com> wrote:
> Marko Kreen wrote:
> > NAK.  The fix is broken because it uses EVP interface.  EVP is not
> > a general-purpose interface because not all valid keys for cipher
> > pass thru it.  Only key-lengths used in SSL will work...
> I'm not openssl expert, but if you look how to EVP call for setkey is
> implemented you can see that finally is call BF_set_key. Only there is
> one extra layer  see

I glanced into evp.h for 0.9.7 and 0.9.6j and remembered that
there were 2 things EVP forced - key length and padding.

When I replied to you I remembered things bit wrong, there are
indeed way for changing key size even in 0.9.6, but not for
padding.  EVP_CIPHER_CTX_set_padding() appers in only in 0.9.7.

I suspect as I could not work around forced padding I did not
research key size issue very deeply.

So we can revisit the issue when we are ready to drop
support for 0.9.6x.

> > Could you rework the fix that it uses the BF_* interface,
> > does a test-encoding with full-length key and compares it to
> > expected result.  And does it just once, not on each call.
> OK. I can do, but it is not general solution. Because it will work only
> in our case, because we know 128 is a restricted limit.

It _is_ a general solution if you test with a 448 bit key.

Using BF_ API but testing via EVP_ API is unobvious first,
in addition leaving the user depending whether the molesters
got all the details right.

When everything uses EVP then indeed, we can test via EVP.

> > I must admit the internal API for ciphers is clumsy and could
> > need rework to something saner.  This shows here.
> >
> >> I attach patch which fix both issues, but main problem is there that old
> >> openssl API is used and supported key lengths are hardcoded. I think we
> >> can add to TODO list rewrite pgcrypto to use evp openssl interface.
> >
> > pgcrypto _was_ written using EVP, but I needed to rewrite it
> > when I found out EVP supports only key lengths used in SSL.
> Is it still correct? It seems that blowfish accepts all key range, but

Yes, seems since 0.9.7 we could work with EVP.

> How I mention I'm not openssl guru and documentation is very bad :(.

It's somewhat lacking, yes.  User is forced to read their source
which isn't very nice either...


In response to


pgsql-hackers by date

Next:From: Gregory StarkDate: 2007-07-24 19:27:12
Subject: Re: strange buildfarm failure on lionfish
Previous:From: Tom LaneDate: 2007-07-24 17:56:14
Subject: Re: strange buildfarm failure on lionfish

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group