Hello,
The reason to want to use XTS[1] mode is to avoid the same ciphertext be
produced for the same plaintext due to using the same initialization
vector for each page if for example CBC mode is used (due to inability
to store the IV inside a page).
XTS mode can be used in Firebird if we treat
Forgot to add the link to wikipedia:
[1]
https://en.wikipedia.org/wiki/Disk_encryption_theory#XEX-based_tweaked-codebook_mode_with_ciphertext_stealing_(XTS)
On Thu, 7 Jun 2018 15:37:10 +0300
Hristo Stefanov wrote:
> Hello,
>
> The reason to want to use XTS[1] mode is to avoid the same cipherte
07.06.2018 14:37, Hristo Stefanov wrote:
[*] Not always true currently. There is a DbCrypt plugin sanity routine
that passes a 16 byte chunk to test encryption and decryption and a
routine for calculating a digital signature which passes a multiple of
16 byte chunk that is way shorter than the mi
On Thu, 7 Jun 2018 14:49:35 +0200
Dimitry Sibiryakov wrote:
>
>Don't forget about backup file encryption which is currently under
> development by Alex.
>
This is one of the reasons to ask for official support - so that it can
be kept in mind when developing new features.
>AES is cons
07.06.2018 16:11, Hristo Stefanov wrote:
The main advantage of using XTS would be that the ciphertext would be
bound to its location which eliminates repeating ciphertext which
otherwise helps for identifying patterns within the database file.
Patterns of encrypted pages are well known from s
07.06.2018 16:29, Hristo Stefanov wrote:
I meant primarily patterns in the data pages of a database file.
Patterns in data are fuzzed by record compression. BLOBs may be troublesome if someone
is stupid enough to keep in a database bitmaps instead of JPEGs.
--
WBR, SD.
-
Read here
(https://www.tabsoverspaces.com/233727-firebirdclient-version-6-0-entity-framework-core-2-x-provider-entity-framework-6-provider)
and here (https://github.com/FirebirdSQL/NETProvider/releases/tag/6.0.0.0).
--
Mgr. Jiří Činčura
https://www.tabsoverspaces.com/
-
On Thu, 7 Jun 2018 16:34:26 +0200
Dimitry Sibiryakov wrote:
>
>Patterns in data are fuzzed by record compression. BLOBs may be
> troublesome if someone is stupid enough to keep in a database bitmaps
> instead of JPEGs.
>
Record compression is RLE based (AFAIK) and doesn't fuzz the data if
07.06.2018 17:30, Hristo Stefanov wrote:
Record compression is RLE based (AFAIK) and doesn't fuzz the data if
there are no successive repetitions in the same field which I imagine is
mostly true for some kinds of data including English text.
English text has no patterns divisible to 16 bytes,
On Thu, 7 Jun 2018 17:41:51 +0200
Dimitry Sibiryakov wrote:
>
>English text has no patterns divisible to 16 bytes, AFAIK.
>
An example is logging data which typically contains a lot of
repetitive text between records and contains English text. Looking at
the ciphertext you can guess if th
07.06.2018 18:19, Hristo Stefanov wrote:
For example you have reached a server in corporate network
At this point encryption cannot protect database anymore because you can easily get
unencrypted data or even encryption key from working connections no matter what block
chaining is used.
-
On 07.06.2018 19:24, Dimitry Sibiryakov wrote:
07.06.2018 18:19, Hristo Stefanov wrote:
For example you have reached a server in corporate network
At this point encryption cannot protect database anymore because you
can easily get unencrypted data or even encryption key from working
connec
07.06.2018 18:40, Alex Peshkoff via Firebird-devel wrote:
Ability to easily get ncryption key from working connections mean badly written
KeyHolder.
No matter how well is written KeyHolder, thanks to CLOOP signatures it is very easy to
identify and hijack encrypt/decrypt routines of crypt p
On 07.06.2018 20:01, Dimitry Sibiryakov wrote:
07.06.2018 18:40, Alex Peshkoff via Firebird-devel wrote:
Ability to easily get ncryption key from working connections mean
badly written KeyHolder.
No matter how well is written KeyHolder, thanks to CLOOP signatures
it is very easy to identify
07.06.2018 19:08, Alex Peshkoff via Firebird-devel wrote:
As I've already said if one has access to server's RAM there are a lot of ways to get both
unencrypted data & keys.
But that's 'slightly' different level compared with intercepting of network
messages.
Yes, but this is exactly what H
On 07.06.2018 20:40, Dimitry Sibiryakov wrote:
07.06.2018 19:08, Alex Peshkoff via Firebird-devel wrote:
As I've already said if one has access to server's RAM there are a
lot of ways to get both unencrypted data & keys.
But that's 'slightly' different level compared with intercepting of
networ
07.06.2018 19:47, Alex Peshkoff via Firebird-devel wrote:
Access to server's file system and server's RAM are rather different things.
Not quite so. If someone can write a library into plugins subdir - memory is
accessible. Of course, no write access to FS makes things a little harder.
--
On 07.06.2018 21:16, Dimitry Sibiryakov wrote:
07.06.2018 19:47, Alex Peshkoff via Firebird-devel wrote:
Access to server's file system and server's RAM are rather different
things.
Not quite so. If someone can write a library into plugins subdir -
memory is accessible. Of course, no write
On 07.06.2018 21:28, Alex Peshkoff via Firebird-devel wrote:
On 07.06.2018 21:16, Dimitry Sibiryakov wrote:
07.06.2018 19:47, Alex Peshkoff via Firebird-devel wrote:
Access to server's file system and server's RAM are rather different
things.
Not quite so. If someone can write a library int
So to summarize the current opinion is that there is no use of adding
support for XTS mode of operation for ciphers in DbCrypt plugins even
though such a mode is a slightly better fit with better security
guarantees ?
I started the discussion because of this presentation:
https://www.firebirdsql.o
07.06.2018 22:52, Hristo Stefanov wrote:
I started the discussion because of this presentation:
https://www.firebirdsql.org/file/community/conference-2016/encrypting-firebird-databases.pdf
with the following quote:
Known issue:
– Encrypted size == initial size
I don't understand why this i
> As I've already said if one has access to server's RAM there are a lot
> of ways to get both unencrypted data & keys.
Unless HSM is used. Then the key is not in RAM.
--
Mgr. Jiří Činčura
https://www.tabsoverspaces.com/
---
22 matches
Mail list logo
