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 that verify the key by decrypting >> something kept >> in DB header is a very bad idea. In fact, it provides to everybody one >> surely known >> plain-text and corresponding crypto-text. Effectively it push out of >> business any >> algorithm vulnerable to known-plaintext attack. XOR-ing with any key of any >> length would >> have no use anymore. >> > In that case, I suggest that it's a very good idea. No encryption > algorithm vulnerable to plaintext -- or anything other than brute force > -- has no business being used in a database system. Such algorithms are > obfuscation, not encryption. > > But since AES-NI appears immune to everything thrown at it in 15 years > and beats the pants off all rivals in performance, why use anything > else? Maybe somebody will find an attack and we'll all have to find new > algorithms
Presence of one surely known plain-text and corresponding encrypted text will be of great help to the potential attackers in such a case. May be we should better use something not so straightforward - moreover, I'm afraid that presence of this known pair will not help some people to use good algorithm, they will just cry: "firebird is vulnerable to such simple attacks". Seriously - there are a lot of other ways to validate a key. We may store a hash of that key in the header. After getting a key server calculates a hash and compares it with one in the header. If they match this is enough protection from wrong keys. > , so the architecture should be capable of phasing in new > algorithms, but I don't quite see the point of designing for poor > algorithms. > Possible point is to try to minimize troubles in a case when good algorithm becomes poor. ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
