| From: | Andrew Chernow <ac(at)esilo(dot)com> | 
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> | 
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: New types for transparent encryption | 
| Date: | 2009-07-08 02:59:48 | 
| Message-ID: | 4A540BA4.7020300@esilo.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Andrew Dunstan wrote:
> 
> 
> Andrew Chernow wrote:
>>
>>> Encrypting lots of small chunks of data with the same key is a very
>>> dangerous thing to do and it's very tricky to get right.
>>
>> Using an initialization vector (IV) is the way to go, recommend using 
>> CBC or CFB mode.  Although, an IV is never supposed to be used more 
>> than once with the same key; that can leak hints about the plaintext.  
>> Where is the randomly generated IV stored for use during decryption?
> 
> Well, you can store it along with the encrypted data. The IV doesn't 
> need to be secret, just random. I do that for one of my clients.
> 
That's correct. Duh!?! Probably the first N bytes of the cipher text.
Would the IV be regenerated every time the plaintext is updated, to avoid using 
it twice?  For instace: update t set text = 'abc' where id = 1 .  ISTM that the 
IV for OLD.text should be thrown away.
Where would the key come from? Where would it be stored? What cipher is used?
-- 
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2009-07-08 03:46:28 | Re: *_collapse_limit, geqo_threshold | 
| Previous Message | Andrew Dunstan | 2009-07-08 02:49:09 | Re: New types for transparent encryption |