"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. Предприятие может иметь собственные и\или
купленные
сертифицированные ср-ва криптозащиты и желать пользоваться ими, а не встроенными
> > Ладно. Обсуждать развитие дятла (а не общий случай) как-то не входит
> > в мои интересы, заканчиваю :)
>
> Как показывает практика часть идей из него плавно перетекает сам знаешь куда
> ;-);-);-)
Эта идея вряд ли перетечёт. Ибо рассчитана на весьма узкое применение.
--
Хорсун Влад
--~--~---------~--~----~------------~-------~--~----~
-~----------~----~----~----~------~----~------~--~---
