2013-03-04 6 views
0

Кто-нибудь знает, как правильно подготовиться к вводу типа данных BYTEA в postgresql? У меня есть зашифрованная строка, созданная из libmcrypt. Я хочу сохранить шифрование в столбце таблицы, определяемом как «cdata bytea not null»Подготовка, хранение, получение зашифрованных данных в PostgreSQL

У меня есть ядро, отлично работающее с командной строкой, но теперь я хочу хранить шифрование в РСУБД, как описано в файлах. Фрагмент кода, является продолжением:

int rs; 
char buffer[1]; 
char dbuffer[1024]; 
datafile = "This is my house"; // assume this to be a file 
crypt_key[] = "123456789"; // 32 bytes 
crypt_iv[] = "11111111111111111111111111111111"; // 32 bytes 
mfd = mcrypt_module_open(MCRYPT_RIJNDAEL_256, NULL, "cfb", NULL); // assume success 
mcrypt_generic_init(mfd, crypt_Key, 32,crypt_iv); // assume success 

while(readInputFile(datafile,buffer,sizeof(buffer),&bytes) == cgiFormSuccess) { 
     mcrypt_generic(mfd,buffer,sizeof(buffer)); // buffer size s/b 1 
     dbuffer[i++] = *buffer; 
     dbuffer[i] = '\0'; // Time spent on string sanity 
} // processed each byte is now encrypted 

// Now I wish to prepare dbuffer for table insertion 
sb = PQescapeByteaConn(dbconn,dbuffer,(size_t)strlen(dbuffer),&rs); 

// Perform Insertion --> cdata::BYTEA 
sprintf(query,"INSERT INTO crypto (uid,crypt_key,crypt_iv,cdata,cfile)" 
        "VALUES('%s','%s','%s','%s','%s')", 
     ebs->uid,ebs->crkey,ebs->crivs,sb,credf); // cfile == original filename 
ebs->r=db_func_query(ebs->r,query,0,proc); // Please assume DB command success 

// Expected output sb == \x...some hex, dbuffer == encrypted bytes. sb is now in bytea table column. 
###################################### 
// Prepare to decrypt the cdata::bytea column 

sprintf(query,"DECLARE %s CURSOR FOR SELECT crypt_iv,cdata,cfile " // not sure if cursor s/b regular or binary for this 
        "FROM crypto WHERE uid='%s' AND crypt_iv='%s' AND action=true", 
     VCURSOR,ebs->uid,ebs->crkey); 

db_func_txn_begin(ebs->r,proc); 
ebs->r = db_func_query(ebs->r,query,1,proc); // process the query and assume it delivers the row 
if(totalrow) { 
    nFields = PQnfields(ebs->r); 
    char* results[nFields]; 
    for(i = 0;i < totalrow;i++) { 
      for(j = 0;j < nFields;j++) 
       results[j] = PQgetvalue(ebs->r,i,j); 
      strcpy(crypt_iv,results[0]); 
      strcpy(dbuffer,results[1]); 
      strcpy(cfile,results[2]); 
} 
mcrypt_generic_init(mfd, crypt_Key, 32,crypt_iv); // assume success 
sb = PQunescapeBytea(dataBuf,&rs); 

for(i = 0;i < rs+1;i++) { 
    mdecrypt_generic(mfd,sb[i],1); // buffer size s/b 1 
    dbuffer[i] = sb[i]; 
    dbuffer[i+1] = '\0'; // Time spent on string sanity 
} 

// Expected output sb == reverse of PQescapeByteaConn, dbuffer == unencrypted bytes. 

Там надо быть способ успешно вставки и запроса зашифрованные строки для расшифровки.

Заранее спасибо.

+0

Перекресток от pgsql-хакеров: http://www.postgresql.org/message-id/[email protected] Читатели, которые найдут это позже, должны посмотреть на эту тему, если есть соответствующая информация, размещенная там позже. –

+0

Кстати, этот код действительно должен использовать интерфейс параметризованного запроса libpq, чтобы убедиться, что он безопасен от любых возможных рисков SQL-инъекций, а также для упрощения отладки и ускорения. –

+0

Процедура обработки процедуры db, которую вы называете, является просто оболочкой для моего вызова библиотеки libpq, чтобы сократить количество написанных строк, и она работает уже много лет без какого-либо известного или сообщаемого компрометации. Тем не менее, я пытаюсь найти ответ на двоичную проблему строки, которую я имею с зашифрованным выходом, и, я считаю, метод подготовки, который я использую. Этот код отлично работает с файловыми вводами-выводами, но не с вызовом вставки БД. Я разрабатываю это для PSQL версии 9.2.3 – Rico

ответ

0

Проблема решена. Вы можете избежать использования только текстового столбца, пока вы избегаете вывода mcrypted string. Bytea является более чистым, но для расшифровки явно требуется больше строк кода и PGunescapeBytea.