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, so the architecture should be capable of phasing in new algorithms, but I don't quite see the point of designing for poor algorithms. If there's any interest, I have some ideas on how to handle unattended startup of an encrypted database that we could kick around. ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
