Hello, Vlad!
Tuesday, April 3, 2012, 1:18:05 PM, you wrote:
VK> How do you going to detect still not encrypted pages if you against
VK> "encrypted" flag ?
Well, the question is over - InterBase uses pag->pag_flags (highest
bit of this byte, i.e. x80) to indicate page is encrypted or not.
For
> I meant 12345 checksum that was fixed since InterBase 5. So, page
> checksums are not "guards" of the pages for a long time. They are just
> indicators, that if there no 12345, page can be considered as crap.
Anyway not good crypt indicator - in some rare cases it can be 12345 on
encrypted page
Hello, Vlad!
Tuesday, April 3, 2012, 1:18:05 PM, you wrote:
>> - not all db pages need to be encrypted. for example PIP, TIP, etc.
>> Performance effect of decrypting/encrypting these pages can be
>> disasterous.
VK> Where it conflicts with my proposition ?
wrote just for the case.
VK> a)
Hello, Alex!
Tuesday, April 3, 2012, 1:09:34 PM, you wrote:
AP> Ceratinly, we should not encrypt something except data, index and blob
AP> pages.
sure.
AP> Storing last encypted page sometimes is good compromise not to read
AP> whole DB I think.
well, since the databases are big enough, I need
> VK> Encryption must be resistent to the database shutdown\server restart
> and so on.
> VK> Therefore it must be restartable. As we going to add "encrypted" flag for
> each page
> VK> we can know pages that already encrypted. To not read whole database
> searching
> VK> for the not encrypt
On 04/03/12 13:03, Dmitry Kuzmenko wrote:
> Hello, Vlad!
>
> Tuesday, April 3, 2012, 12:44:07 PM, you wrote:
>
> VK> Encryption must be resistent to the database shutdown\server restart
> and so on.
> VK> Therefore it must be restartable. As we going to add "encrypted" flag for
> each page
>
Hello, Vlad!
Tuesday, April 3, 2012, 12:44:07 PM, you wrote:
VK> Encryption must be resistent to the database shutdown\server restart
and so on.
VK> Therefore it must be restartable. As we going to add "encrypted" flag for
each page
VK> we can know pages that already encrypted. To not read
On 04/03/12 12:49, Dimitry Sibiryakov wrote:
> 03.04.2012 10:44, Vlad Khorsun wrote:
>> To not read whole database searching
>> for the not encrypted pages after restart i offer to store last encrypted
>> page number
>> at header page (also, obviously, we need to store encription state on the
>>
> 03.04.2012 10:44, Vlad Khorsun wrote:
>> To not read whole database searching
>> for the not encrypted pages after restart i offer to store last encrypted
>> page number
>> at header page (also, obviously, we need to store encription state on the
>> header
>> such as "clear", "encrypted", "encr
03.04.2012 10:44, Vlad Khorsun wrote:
> To not read whole database searching
> for the not encrypted pages after restart i offer to store last encrypted
> page number
> at header page (also, obviously, we need to store encription state on the
> header
> such as "clear", "encrypted", "encryption i
> To work with encrypted database file we need a tool to encrypt database.
> I see 3 possible solutions for it. In all 3 cases some plugin dependent
> parameter may be passed to plugin. In all cases one may use decrypt
> instead encrypt to make
Encryption must be resistent to the database shut
11 matches
Mail list logo
