Re: pgcrypto functions fail for asymmetric encryption/decryption - Mailing list pgsql-general

From Stefan Niantschur
Subject Re: pgcrypto functions fail for asymmetric encryption/decryption
Date
Msg-id 200712032254.05064.sniantschur@web.de
Whole thread Raw
In response to Re: pgcrypto functions fail for asymmetric encryption/decryption  ("Marko Kreen" <markokr@gmail.com>)
List pgsql-general
Am Montag, 3. Dezember 2007 schrieben Sie:
> On 12/3/07, Stefan Niantschur <sniantschur@web.de> wrote:
> > I finally made it. I created a brand-new key, reworked the query and
> > voila.
> >
> > It seems that the GnuPG key has to be created with
> > paramter --cipher-algo=blowfish before it can be used together with
> > pgcrypto. The generated key with the default settings failed for some
> > reason.
>
> Well, that really does not explain why the old keys failed.
> And you have no guarantee you wont get some failures in the
> future.  If the key cipher would have been unsupported, you
> should have gotten errors not random corruptions.
>
> I really suggest you run regression tests for both PostgreSQL
> and pgcrypto.  This should sanity-check your build and runtime
> environment.
>
> Also, as I understand you are experimenting with test keys?
> Could you send both public and private keys to me, fully.
> You can send privately if you wish.  If they are not test
> keys, then only public key and pgpdump output of private key,
> if should not inlude any secret info.
> (http://www.mew.org/~kazu/proj/pgpdump/)
>
> I really like to understand whats going on...

Funny thing is, that I now can also use the old keys which have not been
working before. It seems that my initial query has been way too weird. Now
with the shorter (and correct) version even the old keys do work.

In my initial version of the query I did lots of armor/dearmor calls which
were very likely in the wrong place. So, your hint that the use of these
calls is excessive helped me to correct the query.

Running regression tests is not so easy as the distribution I use does not
support it. It seems that they had some trouble to build the software with
the regressions target in make.

Best Regards

pgsql-general by date:

Previous
From: Erik Jones
Date:
Subject: Moving pgstat.stat and pgstat.tmp
Next
From: "Merlin Moncure"
Date:
Subject: Re: PL/pgSQL and SETOF