Re: [Firebird-devel] Security problem with encrypted databases

15.11.2015 3:05, Steve Friedl wrote: >> The attacker simply uses the same IP address as a valid client ??? > No, not at all. > > The spoofer will never receive a reply from the target to complete the > three-way handshake, and since getting this right involves knowing the > target's next TCP

Re: [Firebird-devel] Security problem with encrypted databases

On 11/15/2015 06:22 PM, Jim Starkey wrote: > On 11/15/2015 7:55 AM, Alex Peshkoff wrote: >> Presence of one surely known plain-text and corresponding encrypted >> text will be of great help to the potential attackers in such a case. > Really? Why do you think it would be a "great help." What

Re: [Firebird-devel] Security problem with encrypted databases

On 11/15/2015 7:55 AM, Alex Peshkoff wrote: > Presence of one surely known plain-text and corresponding encrypted > text will be of great help to the potential attackers in such a case. Really? Why do you think it would be a "great help." What useful information is leaked? And how would a

Re: [Firebird-devel] Security problem with encrypted databases

On 11/14/2015 5:54 PM, Dimitry Sibiryakov wrote: > 14.11.2015 23:16, Jim Starkey wrote: >> So here's a simple scheme. The basic idea of a redundant set of >> lightweight key servers running at various points in the network. When a >> database wants to start up, it runs through a list of key

Re: [Firebird-devel] Security problem with encrypted databases

Jim Starkey wrote: > When you get down to essentials, that's basically the same technology that I'm suggesting for a key server, the only difference is the certificate says a trust third party vouches for me as opposed to the key server already knowing the IPs. And, not incidentally, the key

Re: [Firebird-devel] Security problem with encrypted databases

15.11.2015 16:26, Jim Starkey wrote: > Do remember that we're talking about unattended startup. Oops, I really forgot that, sorry. -- WBR, SD. -- Firebird-Devel mailing list, web interface at

Re: [Firebird-devel] Security problem with encrypted databases

On 11/14/2015 6:21 PM, Wols Lists wrote: > On 14/11/15 22:16, Jim Starkey wrote: >> While's it possible to fake the originator IP address with UDP, I don't >> think it's possible with TCP. > The attacker simply uses the same IP address as a valid client ??? > > If the valid client is offline,

Re: [Firebird-devel] Security problem with encrypted databases

On 11/14/2015 7:03 PM, Leyne, Sean wrote: > Doesn't the need for a key server make the problem more complicated > that required? More complicated? Certainly. More complicated that required? Don't know yet. > Although I think it should be supported, via engine/config. I was > referring to a

Re: [Firebird-devel] Security problem with encrypted databases

On 11/14/2015 06:29 PM, Jim Starkey wrote: > On 11/14/2015 9:48 AM, Dimitry Sibiryakov wrote: >> 10.11.2015 10:13, Alex Peshkoff wrote: >>> Does anybody see problems with suggested approach? >>> If not - I will add a ticket to the tracker for myself. >> After a good sleeping on it, I'm sure

Re: [Firebird-devel] Security problem with encrypted databases

ces where TCP spoofing can work, so most of us security types don't seriously consider it a threat. Steve -Original Message- From: Wols Lists [mailto:antli...@youngman.org.uk] Sent: Saturday, November 14, 2015 3:22 PM To: firebird-devel@lists.sourceforge.net Subject: Re: [Firebird-devel] Secur

Re: [Firebird-devel] Security problem with encrypted databases

On 11/14/2015 9:48 AM, Dimitry Sibiryakov wrote: > 10.11.2015 10:13, Alex Peshkoff wrote: >> Does anybody see problems with suggested approach? >> If not - I will add a ticket to the tracker for myself. > After a good sleeping on it, I'm sure that verify the key by decrypting > something kept

Re: [Firebird-devel] Security problem with encrypted databases

10.11.2015 10:13, Alex Peshkoff wrote: > Does anybody see problems with suggested approach? > If not - I will add a ticket to the tracker for myself. After a good sleeping on it, I'm sure that verify the key by decrypting something kept in DB header is a very bad idea. In fact, it provides

Re: [Firebird-devel] Security problem with encrypted databases

On 11/14/2015 3:51 PM, Leyne, Sean wrote: > Jim, > >> If there's any interest, I have some ideas on how to handle unattended >> startup of an encrypted database that we could kick around. > I would like to have such a discussion, since I have found the discussion of > the whole "key holder"

Re: [Firebird-devel] Security problem with encrypted databases

14.11.2015 23:16, Jim Starkey wrote: > So here's a simple scheme. The basic idea of a redundant set of > lightweight key servers running at various points in the network. When a > database wants to start up, it runs through a list of key server > addresses looking for one that is actually

Re: [Firebird-devel] Security problem with encrypted databases

Jim, > If there's any interest, I have some ideas on how to handle unattended > startup of an encrypted database that we could kick around. I would like to have such a discussion, since I have found the discussion of the whole "key holder" discussion a little obtuse and seemingly mixing remote

Re: [Firebird-devel] Security problem with encrypted databases

> >> If there's any interest, I have some ideas on how to handle > >> unattended startup of an encrypted database that we could kick around. > > I would like to have such a discussion, since I have found the discussion of > the whole "key holder" discussion a little obtuse and seemingly mixing >

Re: [Firebird-devel] Security problem with encrypted databases

10.11.2015 10:13, Alex Peshkoff wrote: > Does anybody see problems with suggested approach? It cannot detect partially written or physically corrupted page. -- WBR, SD. -- Firebird-Devel mailing list, web

Re: [Firebird-devel] Security problem with encrypted databases

10.11.2015 10:28, Alex Peshkoff wrote: > Agree, but it's not-related to the wrong/correct crypt key IMHO, one solution solving several problems at once is better that separate solutions for every single problem. -- WBR, SD.

Re: [Firebird-devel] Security problem with encrypted databases

On 11/10/2015 12:20 PM, Dimitry Sibiryakov wrote: > 10.11.2015 10:13, Alex Peshkoff wrote: >> Does anybody see problems with suggested approach? > It cannot detect partially written or physically corrupted page. > Agree, but it's not-related to the wrong/correct crypt key

Re: [Firebird-devel] Security problem with encrypted databases

10.11.2015 10:31, Vlad Khorsun wrote: > b) questionable itself Ask DK for corruption statistics. If a page is corrupted, server may crash trying to parse it. To prevent that you'll have to put a lot of checks on every parsing step. IMHO, it is simpler and faster to check integrity of

Re: [Firebird-devel] Security problem with encrypted databases

10.11.2015 11:39, Dimitry Sibiryakov wrote: > 10.11.2015 10:31, Vlad Khorsun wrote: >> b) questionable itself > > Ask DK for corruption statistics. Good argument ! Note, it's up to you to proof your point :) > If a page is corrupted, server may crash trying to parse it. To prevent >

Re: [Firebird-devel] Security problem with encrypted databases

On 11/09/2015 11:08 PM, Roman Simakov wrote: > Key correctness can be checked by engine via crypto-plugin... Does anybody see problems with suggested approach? If not - I will add a ticket to the tracker for myself. --

Re: [Firebird-devel] Security problem with encrypted databases

10.11.2015 11:20, Dimitry Sibiryakov wrote: > 10.11.2015 10:13, Alex Peshkoff wrote: >> Does anybody see problems with suggested approach? > > It cannot detect partially written or physically corrupted page. > This task a) have no relation with encryption b) questionable itself Regards,

Re: [Firebird-devel] Security problem with encrypted databases

On 11/07/2015 07:16 PM, Adriano dos Santos Fernandes wrote: > Em 07/11/2015 13:11, Dimitry Sibiryakov escreveu: >> 07.11.2015 15:57, Vlad Khorsun wrote: >>> I'd say it will be good to have ability to validate encryption key when >>> it is passed into the engine. I.e. not at every page read >>

Re: [Firebird-devel] Security problem with encrypted databases

I just would like to support Vlad solution. It's enough to crypt well known data and decrypt it by provided key. If result is not well known data -> key is bad. It's not necessary to apply that key for the database pages and get surprises as well as not necessary to validate every page. It's

Re: [Firebird-devel] Security problem with encrypted databases

2015-11-09 21:08 GMT+03:00 Dimitry Sibiryakov : > In Firebird, crypto-plugin has no access to header page and engine at all. Key correctness can check engine via crypto-plugin after attachment. -- Roman Simakov

Re: [Firebird-devel] Security problem with encrypted databases

09.11.2015 19:05, Roman Simakov wrote: > It's another question where to store such validation data. Just > clumplet on header page? New version will use it, old just skip. In Firebird, crypto-plugin has no access to header page and engine at all. -- WBR, SD.

Re: [Firebird-devel] Security problem with encrypted databases

Key correctness can be checked by engine via crypto-plugin... 2015-11-09 21:21 GMT+03:00 Roman Simakov : > 2015-11-09 21:08 GMT+03:00 Dimitry Sibiryakov : >> In Firebird, crypto-plugin has no access to header page and engine at all. > > Key correctness

Re: [Firebird-devel] Security problem with encrypted databases

08.11.2015 18:11, Vlad Khorsun wrote: > 08.11.2015 17:01, Dimitry Sibiryakov wrote: >> >08.11.2015 15:53, Vlad Khorsun wrote: >>> >> Only reliable way to validate encryption key is to use it in >>> >> encryption, for example: >>> >>encrypt something using correct key and decrypt using key to

Re: [Firebird-devel] Security problem with encrypted databases

08.11.2015 15:53, Vlad Khorsun wrote: > Only reliable way to validate encryption key is to use it in encryption, > for example: > encrypt something using correct key and decrypt using key to validate and > compare results. It is nice, but if you have a correct key and an user provided

Re: [Firebird-devel] Security problem with encrypted databases

08.11.2015 17:01, Dimitry Sibiryakov wrote: > 08.11.2015 15:53, Vlad Khorsun wrote: >> Only reliable way to validate encryption key is to use it in >> encryption, for example: >> encrypt something using correct key and decrypt using key to validate and >> compare results. > > It is

Re: [Firebird-devel] Security problem with encrypted databases

08.11.2015 11:58, Vlad Khorsun wrote: > Are you going to say that encryption is useless if algorithm is known ? No. How did you read that? >> > I'd suggest to reserve last four bytes on every page and put CRC32 >> > checksum there. This >> >way we can be protected from both wrong

Re: [Firebird-devel] Security problem with encrypted databases

08.11.2015 13:03, Dimitry Sibiryakov wrote: > 08.11.2015 11:58, Vlad Khorsun wrote: >> Are you going to say that encryption is useless if algorithm is known ? > > No. How did you read that? Only reliable way to validate encryption key is to use it in encryption, for example: encrypt

Re: [Firebird-devel] Security problem with encrypted databases

07.11.2015 17:11, Dimitry Sibiryakov wrote: > 07.11.2015 15:57, Vlad Khorsun wrote: >> I'd say it will be good to have ability to validate encryption key when >> it is passed into the engine. I.e. not at every page read > > Say, a malefactor has algorithm, but not a key (which is usual

Re: [Firebird-devel] Security problem with encrypted databases

08.11.2015 18:31, Vlad Khorsun wrote: > I have correct encryption key when user first encrypt database. It is > possible to encrypt > something known to the engine by this key and store somewhere. Next time this > encrypted data > could be used to verify user-supplied key. > > BTW, this

Re: [Firebird-devel] Security problem with encrypted databases

08.11.2015 19:13, Dimitry Sibiryakov wrote: > 08.11.2015 18:11, Vlad Khorsun wrote: >> 08.11.2015 17:01, Dimitry Sibiryakov wrote: 08.11.2015 15:53, Vlad Khorsun wrote: >> Only reliable way to validate encryption key is to use it in >> encryption, for example: >> encrypt

Re: [Firebird-devel] Security problem with encrypted databases

08.11.2015 18:55, Vlad Khorsun wrote: >> One problem: crypto-plugin has no idea which database it works with. >> And no interface >> >to find it out at hand. All it has is an array of bytes to decrypt and a >> >key got from a >> >holder. > It have key name, IIRC Crypto-plugin

Re: [Firebird-devel] Security problem with encrypted databases

08.11.2015 19:43, Dimitry Sibiryakov wrote: > 08.11.2015 18:31, Vlad Khorsun wrote: >> I have correct encryption key when user first encrypt database. It is >> possible to encrypt >> something known to the engine by this key and store somewhere. Next time >> this encrypted data >> could be

Re: [Firebird-devel] Security problem with encrypted databases

07.11.2015 15:57, Vlad Khorsun wrote: > I'd say it will be good to have ability to validate encryption key when > it is passed into the engine. I.e. not at every page read Say, a malefactor has algorithm, but not a key (which is usual situation in OSS world). In this case it is easy to

Re: [Firebird-devel] Security problem with encrypted databases

07.11.2015 15:11, Dimitry Sibiryakov wrote: > Hello, All. > > Because currently there is no checksum on db pages (even a fake one), Here you wrong - pag_pageno is used for basic validation instead of old checksum's. > there is no way > to check if a page was decrypted right. Here

[Firebird-devel] Security problem with encrypted databases

Hello, All. Because currently there is no checksum on db pages (even a fake one), there is no way to check if a page was decrypted right. As the result, any application that provide a wrong key, crash the engine and whole server. Any thoughts?.. -- WBR, SD.

Re: [Firebird-devel] Security problem with encrypted databases

Em 07/11/2015 13:11, Dimitry Sibiryakov escreveu: > 07.11.2015 15:57, Vlad Khorsun wrote: >> I'd say it will be good to have ability to validate encryption key when >> it is passed into the engine. I.e. not at every page read > >Say, a malefactor has algorithm, but not a key (which is