10.11.2015 9:57, Alex Peshkoff wrote:
> In that case encrypting something from page header seems to be bad idea.
For encryption algorithms that are vulnerable to known-plaintext attack -
yes.
Fortunately, AES is not one of them.
--
WBR, SD.
--
On 11/09/2015 08:05 PM, Dimitry Sibiryakov wrote:
> 09.11.2015 18:00, Jim Starkey wrote:
>> It matters because if every page is encrypted with the same key and
>> initial state, information can be learned by building a table of first
>> blocks. If two pages have the same encryption, then an attack
09.11.2015 18:00, Jim Starkey wrote:
> It matters because if every page is encrypted with the same key and
> initial state, information can be learned by building a table of first
> blocks. If two pages have the same encryption, then an attacker knows
> that those pages have common prologs. This
On 11/9/2015 11:15 AM, Dimitry Sibiryakov wrote:
> 09.11.2015 16:49, Jim Starkey wrote:
>> For CBC mode, the initialization vector is XORed into the first block of
>> plaintext. Without this (or something like it), the first 16 bytes of
>> every page would have the same encryption, allowing a mapp
09.11.2015 16:49, Jim Starkey wrote:
> For CBC mode, the initialization vector is XORed into the first block of
> plaintext. Without this (or something like it), the first 16 bytes of
> every page would have the same encryption, allowing a mapping from
> cryptotext to presumed plaintext, possibly
On 11/9/2015 7:37 AM, Dimitry Sibiryakov wrote:
> 08.11.2015 20:12, Jim Starkey wrote:
>> Use the page number for the initialization vector.
> It is also pointless.
For CBC mode, the initialization vector is XORed into the first block of
plaintext. Without this (or something like it), the fi
08.11.2015 20:12, Jim Starkey wrote:
> Use the page number for the initialization vector.
It is also pointless.
--
WBR, SD.
--
Presto, an open source distributed SQL query engine for big data, initially
developed
On 11/8/2015 12:25 PM, Dimitry Sibiryakov wrote:
> 08.11.2015 17:18, Jim Starkey wrote:
>> Keep in mind that you will need to use something other than ECB mode.
> Sure. But still there is a problem with first block and initialization
> vector. That's
> why I would like to have some place for a
08.11.2015 17:18, Jim Starkey wrote:
> Keep in mind that you will need to use something other than ECB mode.
Sure. But still there is a problem with first block and initialization
vector. That's
why I would like to have some place for a random salt. But if everybody think
that it is a
stupi
On 11/8/2015 7:14 AM, Dimitry Sibiryakov wrote:
> 08.11.2015 12:34, James Starkey wrote:
>> Or have I missed sonething?
> RC4 is a stream cipher. For data pages it works much worse.
> Hardware-accelerated AES is an interesting idea, thanks.
>
You're absolutely right about stream ciphers for
08.11.2015 12:34, James Starkey wrote:
> Or have I missed sonething?
RC4 is a stream cipher. For data pages it works much worse.
Hardware-accelerated AES is an interesting idea, thanks.
--
WBR, SD.
--
Firebird-
On Sunday, November 8, 2015, Dimitry Sibiryakov wrote:
> 08.11.2015 12:08, Vlad Khorsun wrote:
> .
>
>Faster cryptoalgorithms are vulnerable to attack by known text. To make
> analysis
> harder, some random salt used to be appended in the beginning.
>
>
Really? Can you give an example of a
08.11.2015 12:08, Vlad Khorsun wrote:
> Looks like you have questionable (or wrong) design in mind and going to
> force it to us.
Nope. Since I have my playground named Avalerion, I have no will to force
anything to you.
> More details could help to understand you.
Faster cryptoalgor
07.11.2015 16:54, Dimitry Sibiryakov wrote:
> 07.11.2015 15:49, Vlad Khorsun wrote:
>>> Is it too late to include most of page header into encrypted part of
>>> a page, leaving
unencrypted only page type and flags?
>> For what ? IIRC, pag_scn and pag_pageno is required for physical
07.11.2015 15:49, Vlad Khorsun wrote:
>> Is it too late to include most of page header into encrypted part of a
>> page, leaving
>> >unencrypted only page type and flags?
> For what ? IIRC, pag_scn and pag_pageno is required for physical backup
> to be not encrypted
To make pag_reser
07.11.2015 14:57, Dimitry Sibiryakov wrote:
> Hello, All.
>
> Is it too late to include most of page header into encrypted part of a
> page, leaving
> unencrypted only page type and flags?
For what ? IIRC, pag_scn and pag_pageno is required for physical backup to
be not encrypted
Reg
Hello, All.
Is it too late to include most of page header into encrypted part of a page,
leaving
unencrypted only page type and flags?
--
WBR, SD.
--
Firebird-Devel mailing list, web interface at
https://lis
17 matches
Mail list logo
