"Oleg LOA" ... > >> Влад, при чём тут исходники и знание ключа? Исходники blowfish или ase > >> лежат в инте открытыми. > > > > Исходники дятла я имел в виду. > > И что? Что тебе дадут исходники?
Если линковать YaP в приложение - ничего. Но об этом ты позже сказал :) > >> Более того ты ключ из проги не выдернешь просто так даже подменой YaP > >> gds32.dll c > >> подменой attach_database, т.к. она влинковывывается в приложение ;-);-);-) > > А вот это - правильно. Линковать намертво. Но тогда isc_dpb_encrypt_key > > нах не нужен. > > Ибо приложение может спокойно само экспортировать encrypt\decrypt > > Гм, зачем лишний геморрой клиеyту? Так клиент добавил > Params.Add('encrypt_key=blabla'); и > получил что хотел ;-);-);-). Причём стойкость такой реализации весьма высока > против взлома, > т.к. закрывается сверху фемидой. Про фемиду не понято. Клиент имеет право хотеть применить свои алгоритмы шифрования. А что ты делал с утилитами ? gbak\gfix etc ? Добавлял пар-р ком. строки ? Или ничего ? > > Всяко бывает. И навязывать свой, "единственно правильный" подход низзя. > > У юзера вполне могут быть БД из разных источников на одном сервере. > > Гм со своими плугинами....ты себе представляешь админа которому говорят что > нужно лепить > на сервак исполняемсый файлы ото всяких там "источников". Зачем устраивать > этот зоопарк. Это ничем не отличается от udf. Предприятие может иметь собственные и\или купленные сертифицированные ср-ва криптозащиты и желать пользоваться ими, а не встроенными > > Ладно. Обсуждать развитие дятла (а не общий случай) как-то не входит > > в мои интересы, заканчиваю :) > > Как показывает практика часть идей из него плавно перетекает сам знаешь куда > ;-);-);-) Эта идея вряд ли перетечёт. Ибо рассчитана на весьма узкое применение. -- Хорсун Влад --~--~---------~--~----~------------~-------~--~----~ -~----------~----~----~----~------~----~------~--~---