Re: LIBPQ Implementation Requiring BYTEA Data - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: LIBPQ Implementation Requiring BYTEA Data
Date
Msg-id 51341FDC.1030009@2ndquadrant.com
Whole thread Raw
In response to LIBPQ Implementation Requiring BYTEA Data  (Cliff_Bytes <creid@eclipssolutions.com>)
Responses Re: LIBPQ Implementation Requiring BYTEA Data
List pgsql-hackers
On 03/04/2013 11:54 AM, Cliff_Bytes wrote:
> Hello All
>
> First, I am new to this great forum.
>
> I have a challenge on my hand as follows.  I am a long time libpq user but
> have never used the BYTEA data type nor its related functions until now.  I
> have am writing an interface for a web based application written in C using
> libmcrypt and, of course, libpq.
>
> My problem seems to be proper preparation of encrypted data for insert into
> a BYTEA column.  For insertion, I properly process a file (byte-by-byte)
> through mcrypt, then I use PQescapeByteaConn as (snippet) follows:
>
> *while(readInputFile(file,buffer,sizeof(buffer),&bytes) == Success) {
>                                mcrypt_generic(mfd,buffer,sizeof(buffer)); 
> // buffer size == 1 byte
>                                dbuffer[i++] = *buffer;
>                                dbuffer[i] = '\0';  // Time spent on string
> sanity
> }
> close(inputFile);
> sb = PQescapeByteaConn(dbconn,dbuffer,(size_t)strlen(dbuffer),&rl);
> sprintf(query,"INSERT INTO crypto(uid,tdkey,ivkey,cdata,cfile)"  //cdata is
> a bytea column
>                   "VALUES('%s','%s','%s','%s','%s')",
>           ebs->uid,ebs->crkey,ebs->crivs,sb,credf);
> ebs->r=db_func_query(ebs->r,query,0,proc);
> *
>
> What I insert into the bytea column is \x748a590ffdb8dc748dd3fba...
>
> Now sb returns these same bits consistently each time I run the same file
> through mcrypt, using the same key/salt combo which I expect.  However, I
> cannot verify whether the the data inserted is what it should be since I
> cannot decrypt.  I've tried using PQunescapeBytea(data,&size) for the
> decrypt preparation expecting pretty much the reverse of PQescapeByteaConn
> but end up with garbage.
You probably need to supply a self-contained, compileable test case.
Right now there's no sign that this isn't an issue elsewhere in the
application/client code.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services




pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Next
From: Greg Smith
Date:
Subject: Re: Enabling Checksums