On Fri, 8 Jun 2018 17:50:26 +0200
Dimitry Sibiryakov wrote:
> 08.06.2018 17:47, Hristo Stefanov wrote:
> > It has 4 cores but the openssl benchmark is single threaded. Here
> > are the repeated benchmarks with the openssl process pinned to a
> > single core on the Intel(R) Core(TM) i5-2500 CPU:
08.06.2018 17:47, Hristo Stefanov wrote:
It has 4 cores but the openssl benchmark is single threaded. Here are
the repeated benchmarks with the openssl process pinned to a single
core on the Intel(R) Core(TM) i5-2500 CPU:
It doesn't matter for speculative execution. Run 4 benchmarks in parall
On Fri, 8 Jun 2018 17:30:15 +0200
Dimitry Sibiryakov wrote:
> 08.06.2018 17:19, Hristo Stefanov wrote:
> > After running some benchmarks of CBC and XTS mode it turns out XTS
> > is about 4 times faster on the following hardware:
> >
> > Intel(R) Core(TM) i5-2500 CPU
>
It has 4 cores but the
08.06.2018 17:19, Hristo Stefanov wrote:
After running some benchmarks of CBC and XTS mode it turns out XTS is
about 4 times faster on the following hardware:
Intel(R) Core(TM) i5-2500 CPU
There is no wonder at: your CPU has 4 cores and CBC cannot be parallelized. The
difference should be l
> Any ODS will have some kind of internal headers in the beginning of
> data just because there is no way to get rid of them.
OK.
After running some benchmarks of CBC and XTS mode it turns out XTS is
about 4 times faster on the following hardware:
Intel(R) Core(TM) i5-2500 CPU and Debian 9:
$
08.06.2018 15:44, Hristo Stefanov wrote:
With future ODS changes this may not be the case.
Any ODS will have some kind of internal headers in the beginning of data just because
there is no way to get rid of them.
--
WBR, SD.
-
>
>This is applicable only to cases when first encrypted block in
> sequence contains classified information. First encrypted block on
> Firebird pages contains pointers to records or other internal
> structures which are not classified and their knowledge won't help to
> get any useful info
08.06.2018 14:25, Hristo Stefanov wrote:
Yes CBC mode does that but since it is applied using the same IV and the
same key multiple times it is open to chosen-plaintext attacks as noted
here:
https://defuse.ca/cbcmodeiv.htm
A more real world example is given here:
https://stackoverflow.com/que
> >> – Encrypted size == initial size
>
>I don't understand why this is considered as an issue.
Because you cannot add additional information needed for proper
operation of some modes such as the IV used in CBC mode or the tag and
IV in the authenticated AES-GCM mode.
>
>AES crypt plu
> 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/
---
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
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
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
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
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 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: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: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 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 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: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 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 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 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 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.
-
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
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 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
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
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
30 matches
Mail list logo
