Re: [Firebird-devel] Key holder is not used if keyCallback() returned 0
On 05/14/18 15:58, Dimitry Sibiryakov wrote: 14.05.2018 14:28, Alex Peshkoff via Firebird-devel wrote: Number of combination growth as N^2 at least. Writing of separate plugins for each possible use case is... boring. What combinations? Key holder may need to establish connection to client or may not. I see 2 cases here. Ok, you are right, it is not N^2, just N*2. A keyholder that pass-through key directly from application. A keyholder that contain key itself. A keyholder that contain encrypted key and require passphrase from application. A keyholder that reads key from predefined file. A keyholder that reads key from file defined from application. A keyholder that reads key from predefined file and require passphrase from application A keyholder that reads key from file defined by application and require passphrase. Add here more places where key can be stored in and you'll get snowball. When you must write each of these plugins or put all plugins into single module and add records about each of them into plugins.conf (because otherwise it won't work) or explain to an ordinary user how to configure this zoo for each encrypted database separately, you will feel pity that CORE-4482 is never going to be implemented. I certainly agree that there may be a lot of types of key holders but I've just said that some key holders may need tp talk to client, others - not. What about particular kinds of KH certainly we can have an unlimited number of them - just generate new private/public keys pair for data exchange or treat each password as separate kind of KH. :-) But I do not see how is it related with generic part of data exchange rules when transferring a key. PPS. Also I can't imagine people having 7 types of KH on single server :) -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Key holder is not used if keyCallback() returned 0
14.05.2018 14:28, Alex Peshkoff via Firebird-devel wrote: Number of combination growth as N^2 at least. Writing of separate plugins for each possible use case is... boring. What combinations? Key holder may need to establish connection to client or may not. I see 2 cases here. Ok, you are right, it is not N^2, just N*2. A keyholder that pass-through key directly from application. A keyholder that contain key itself. A keyholder that contain encrypted key and require passphrase from application. A keyholder that reads key from predefined file. A keyholder that reads key from file defined from application. A keyholder that reads key from predefined file and require passphrase from application A keyholder that reads key from file defined by application and require passphrase. Add here more places where key can be stored in and you'll get snowball. When you must write each of these plugins or put all plugins into single module and add records about each of them into plugins.conf (because otherwise it won't work) or explain to an ordinary user how to configure this zoo for each encrypted database separately, you will feel pity that CORE-4482 is never going to be implemented. -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Key holder is not used if keyCallback() returned 0
On 05/14/18 13:15, Dimitry Sibiryakov wrote: 14.05.2018 11:57, Alex Peshkoff via Firebird-devel wrote: If key holder is expected to work with both types of keys secrtainly it should try to talk to client. One written only for use of non-client keys should not. Wjat a problem? Number of combination growth as N^2 at least. Writing of separate plugins for each possible use case is... boring. What combinations? Key holder may need to establish connection to client or may not. I see 2 cases here. c) Key plugin is refused by application as a fake one. It's normal error from server's POV. I'm even not sure is it good idea to notify fake plugin that it's attack was detected ;-) Ok, but how can application inform server that this key holder is wrong? Return empty reply. This empty sting will be passed to key holder which can return 1 and still be in use. I see no code in the server that would recognize empty string returned from callback as "switch to the next key holder" instruction. Because it's not servers job to decide try remaining holders or not. Server completely trusts key holders regarding it. If some key holder answered 'yes, I can provide keys' it's enough. BTW, empty reply (why do you call it string? that's not string but binary data) is a definite sign of problems at the client side or network. When delivery or other problems happen reply is empty, and it may be generated by basic FB software. But client when it recognizes key holder can send non-empty data containing any message. For example: hey, I understood your request but for some reasons (appears fake, just wrong, etc.) will not send you a key. I want to emphasize once more - this is information for key holder plugin running, server itself knows nothing except an answer from current key holder which is just a flag meaning continue with next key holder or not. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Key holder is not used if keyCallback() returned 0
14.05.2018 11:57, Alex Peshkoff via Firebird-devel wrote: If key holder is expected to work with both types of keys secrtainly it should try to talk to client. One written only for use of non-client keys should not. Wjat a problem? Number of combination growth as N^2 at least. Writing of separate plugins for each possible use case is... boring. c) Key plugin is refused by application as a fake one. It's normal error from server's POV. I'm even not sure is it good idea to notify fake plugin that it's attack was detected ;-) Ok, but how can application inform server that this key holder is wrong? Return empty reply. This empty sting will be passed to key holder which can return 1 and still be in use. I see no code in the server that would recognize empty string returned from callback as "switch to the next key holder" instruction. -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Key holder is not used if keyCallback() returned 0
On 05/14/18 12:52, Dimitry Sibiryakov wrote: 14.05.2018 11:42, Alex Peshkoff via Firebird-devel wrote: Returning to your cases: a) ICryptKeyCallback::callback() returned zero because application key not needed Well written key holder will not try to talk to client at all if it already has a key... No matter how key holder is written: it has no idea which crypt plugin and database it is loaded for at the point when keyCallback is called. There is no information to decide if it has needed key or the key it has is not for this database. If key holder is expected to work with both types of keys secrtainly it should try to talk to client. One written only for use of non-client keys should not. Wjat a problem? c) Key plugin is refused by application as a fake one. It's normal error from server's POV. I'm even not sure is it good idea to notify fake plugin that it's attack was detected ;-) Ok, but how can application inform server that this key holder is wrong? Return empty reply. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Key holder is not used if keyCallback() returned 0
14.05.2018 11:42, Alex Peshkoff via Firebird-devel wrote: Returning to your cases: a) ICryptKeyCallback::callback() returned zero because application key not needed Well written key holder will not try to talk to client at all if it already has a key... No matter how key holder is written: it has no idea which crypt plugin and database it is loaded for at the point when keyCallback is called. There is no information to decide if it has needed key or the key it has is not for this database. c) Key plugin is refused by application as a fake one. It's normal error from server's POV. I'm even not sure is it good idea to notify fake plugin that it's attack was detected ;-) Ok, but how can application inform server that this key holder is wrong? -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Key holder is not used if keyCallback() returned 0
On 05/10/18 18:36, Dimitry Sibiryakov wrote: 10.05.2018 17:20, Alex Peshkoff via Firebird-devel wrote: BTW, is there a way to distinguish cases when a) ICryptKeyCallback::callback() returned zero because application key not needed b) Application callback is not set Both cases are normal - return non-zro here. Not in the case if an application callback is required for keyholder to work. c) Key plugin is refused by application as a fake one. In this case it's good to raise an error in status parameter. How? ICryptKeyCallback::callback() has no status parameter. Sorry - I've meant first interface you've asked about. I meant the case when user application don't want to work with _this_ key holder and want server to try a next one if available. No matter what key holders are installed application is using same way to decide will it talk to key holder talking to it currently - and the ony criteria is _can_ it talk to such key holder or not. If it can continue conversation with key holder it sends next portion of data, if not - send empty reply with zero length. If conversation is not complete (and therefore key is not transfered) next key holder will be tried by server. Returning to your cases: a) ICryptKeyCallback::callback() returned zero because application key not needed Well written key holder will not try to talk to client at all if it already has a key... b) Application callback is not set Server does not know in advance is there callback at client or not. I.e. it will anyway send request to client and get empty answer from it. I agree that something might be optimized here knowing the reason of error return (next KeyHolders might get error as an answer at once). May be in next protocol version... c) Key plugin is refused by application as a fake one. It's normal error from server's POV. I'm even not sure is it good idea to notify fake plugin that it's attack was detected ;-) -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Key holder is not used if keyCallback() returned 0
10.05.2018 17:20, Alex Peshkoff via Firebird-devel wrote: BTW, is there a way to distinguish cases when a) ICryptKeyCallback::callback() returned zero because application key not needed b) Application callback is not set Both cases are normal - return non-zro here. Not in the case if an application callback is required for keyholder to work. c) Key plugin is refused by application as a fake one. In this case it's good to raise an error in status parameter. How? ICryptKeyCallback::callback() has no status parameter. I meant the case when user application don't want to work with _this_ key holder and want server to try a next one if available. -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Key holder is not used if keyCallback() returned 0
On 04/14/18 13:14, Dimitry Sibiryakov wrote: Hello, All. What is a meaning of return value of keyCallback() routine? It is declared as int, not FB_BOOLEAN, so I guess it is not a flag "use me". But it looks like the engine give up if zero is returned even if no error is set in status. Documentation tells nothing about that. Format of callback was added before introduction of FB_BOOLEAN and unfortunately skipped later when moving to cloop. So it has K&R style of zero/not-zero int usage. BTW, is there a way to distinguish cases when a) ICryptKeyCallback::callback() returned zero because application key not needed b) Application callback is not set Both cases are normal - return non-zro here. c) Key plugin is refused by application as a fake one. In this case it's good to raise an error in status parameter. In cases a) and b) key holder still must be in use providing encryption key from internal sources. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Key holder is not used if keyCallback() returned 0
Hello, All. What is a meaning of return value of keyCallback() routine? It is declared as int, not FB_BOOLEAN, so I guess it is not a flag "use me". But it looks like the engine give up if zero is returned even if no error is set in status. Documentation tells nothing about that. BTW, is there a way to distinguish cases when a) ICryptKeyCallback::callback() returned zero because application key not needed b) Application callback is not set c) Key plugin is refused by application as a fake one. In cases a) and b) key holder still must be in use providing encryption key from internal sources. -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
