Re: pgcrypto: PGP signatures - Mailing list pgsql-hackers

From Marko Tiikkaja
Subject Re: pgcrypto: PGP signatures
Date
Msg-id 540DF3BA.7030700@joh.to
Whole thread Raw
In response to Re: pgcrypto: PGP signatures  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On 2014-09-08 7:30 PM, Jeff Janes wrote:
> On Fri, Sep 5, 2014 at 4:38 AM, Marko Tiikkaja <marko@joh.to> wrote:
>> I've also changed the behaviour when passing a message with a signature to
>> the decrypt functions which don't verify signatures.  They now report
>> "ERROR:  Wrong key or corrupt data" instead of decrypting and silently
>> ignoring the signature.  The behaviour is now backwards compatible, but I
>> see two ways we could possibly possibly improve this:
>>    1) Produce a better error message (I'm sure most people don't know about
>> the hidden debug=1 setting)
>>    2) Provide an option to ignore the signature if decrypting the data is
>> desirable even if the signature can't be verified
>>
>
>
> If i understand the sequence here: The current git HEAD is that
> pgp_pub_decrypt would throw an error if given a signed and encrypted
> message, and earlier version of your patch changed that to decrypt the
> message and ignore the signature, and the current version went back to
> throwing an error.

You got that right, yes.

> I think I prefer the middle of those behaviors.  The original behavior
> seems like a bug to me, and I don't think we need to be backwards
> compatible with bugs.  Why should a function called "decrypt" care if the
> message is also signed?  That is not its job.

Yeah, that seems reasonable, I guess.  I'm kind of torn between the two 
behaviours to be honest.  But perhaps it would make sense to change the 
previous behaviour (i.e. go back to way this patch was earlier) and 
document that somewhere.

> There seems to be a memory leak in pgp_sym_decrypt_verify that does not
> exist in pgp_sym_decrypt.  It is about 58 bytes per decryption.

Interesting.  Thanks!  I'll have a look.


.marko



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: implement subject alternative names support for SSL connections
Next
From: Alvaro Herrera
Date:
Subject: Re: BRIN indexes - TRAP: BadArgument