Re[40]: Шифрование баз данных
От: WindJammer  
Дата: 26.07.01 04:02
Оценка: -1
Здравствуйте The Lex, вы писали:

TL>Надеюсь Вы понимаете, что подобного кода можно написать неисчислимое количество вариантов. Суть от этого особо не изменится. Как и его ценность.

Да.

TL>Меня же интересует не технология шифрования некоторых массивов данных, например, строк, а технология применения Вашего великолепного класса в самой базе данных.

Перед записью шифровать, после чтения расшифровывать, перед передачей подстроки поиска ее преобразовывать.
TL>Каким образом Вы производите подключение всего этого к файлу *.mdb?
Чего всего к mdb?
TL>Каким образом происходит работа клиента с базой данных?
Через ADO, например.
TL>Возможна ли работа с базой данных посредством самого Access?
Нет



E-yes, достаточно точно описал проблему. Он написал, что нельзя шифровать строки самостоятельно, поскольку используется контекстный поиск. Я предложил шифровать строки самостоятельно, а при контекстном поиске подставлять предварительно преобразованный запрос.
Все дальнейше обсуждение возникло только благодаря пытливому уму Алекса. С целью показать, что практика отличается от теории, что за несколько часов можно добавить в приложение функции шифрования, взлом которых... (повторяться не буду). Я ни разу не сказал, что это мое ной-хау, я почеркивал, что это элементарнейшая технология. /* это комментарии к вашей ирони */
Шифрование баз данных
От: e-yes Россия http://e-yes.nm.ru
Дата: 11.05.01 20:58
Оценка:
Как защитить базу данных Access (.mdb) от пиратского использования?
Стандартное шифрование от MS не подходит (сами знаете;).
Шифровать поля самостоятельно — тоже не выход (используется контекстный поиск).
Неужели придется отказаться от DAO?
Damn I'm good
Re: Шифрование баз данных
От: WindJammer  
Дата: 12.05.01 08:17
Оценка:
Здравствуйте e-yes, вы писали:

EY>Шифровать поля самостоятельно — тоже не выход (используется контекстный поиск).

Почему? Перед тем как искать подстроку зашифруйте и ее тем же методом.
Re: Шифрование баз данных
От: Feudor  
Дата: 11.07.01 07:20
Оценка:
Здравствуйте e-yes, вы писали:

EY>Шифровать поля самостоятельно — тоже не выход (используется контекстный поиск).


Можно, наконец, шифровать не поля, а заголовок *.mdb
In the land of the blind the one-eyed man is king.
Tom Waits.
Re[2]: Шифрование баз данных
От: Alex Ostapenko Россия  
Дата: 11.07.01 11:43
Оценка:
Здравствуйте WindJammer, вы писали:

WJ>Здравствуйте e-yes, вы писали:


EY>>Шифровать поля самостоятельно — тоже не выход (используется контекстный поиск).

WJ>Почему? Перед тем как искать подстроку зашифруйте и ее тем же методом.


:))))) Видимо ты очень слабо представляешь себе нормальные блочные шифры. То, что ты предлагаешь, годиться только для чего-нибудь типа ксора.
Re[3]: Шифрование баз данных
От: WindJammer  
Дата: 13.07.01 07:29
Оценка:
Здравствуйте Alex Ostapenko, вы писали:

AO>:))))) Видимо ты очень слабо представляешь себе нормальные блочные шифры. То, что ты предлагаешь, годиться только для чего-нибудь типа ксора.


Жаль, что человек столь сильно представляющий себе нормальные блочные шифры, так и не проявил себя советом в тему...

Случаи бывают разные, иногда даже простого ксора хватит для защиты от пиратского использования, в то же время, как затраты на реализацию такого метода минимальны. e-yes не уточнял, какая степень защиты ему нужна. И не писал, что хочет нормальные блочные шифры.
Re[4]: Шифрование баз данных
От: Alex Ostapenko Россия  
Дата: 13.07.01 07:54
Оценка:
Здравствуйте WindJammer, вы писали:

WJ>Здравствуйте Alex Ostapenko, вы писали:


AO>>:))))) Видимо ты очень слабо представляешь себе нормальные блочные шифры. То, что ты предлагаешь, годиться только для чего-нибудь типа ксора.


WJ>Жаль, что человек столь сильно представляющий себе нормальные блочные шифры, так и не проявил себя советом в тему...


А мне жаль, что ты проявил себя советом не в тему. Я не люблю давать советы, которые нафиг никому не нужны. Не вижу я нормального способа шифровать акцесные данные, чтобы при этом еще и поиск работал.

WJ>Случаи бывают разные, иногда даже простого ксора хватит для защиты от пиратского использования, в то же время, как


Щаз. Пираты отнюдь не дураки. Ломают и говаздо более навороченные защиты.

>затраты на реализацию такого метода минимальны. e-yes не уточнял, какая степень защиты ему нужна. И не писал, что хочет


Польза от него тоже минимальна.

>нормальные блочные шифры.


Когда речь идет о шифровании, одним из наиболее важных параметров всегда является надежность шифра. Xor — под этот критерий ну никак не попадает.
Re[5]: Шифрование баз данных
От: Корнилов Григорий Петрович http://kornilow.newmail.ru
Дата: 13.07.01 08:15
Оценка:
Здравствуйте Alex Ostapenko, вы писали:

AO>Здравствуйте WindJammer, вы писали:

WJ>>Здравствуйте Alex Ostapenko, вы писали:

А толковый совет по теме ...
Ну а пиз..ь — не мешки ворочать.
Re[6]: Шифрование баз данных
От: Alex Ostapenko Россия  
Дата: 13.07.01 08:42
Оценка:
Здравствуйте Корнилов Григорий Петрович, вы писали:

КГП>Здравствуйте Alex Ostapenko, вы писали:


AO>>Здравствуйте WindJammer, вы писали:

WJ>>>Здравствуйте Alex Ostapenko, вы писали:

КГП>А толковый совет по теме ...

КГП>Ну а пиз..ь — не мешки ворочать.

Мда, еще более тяжелый случай.
Re[5]: Шифрование баз данных
От: WindJammer  
Дата: 13.07.01 08:45
Оценка:
Здравствуйте Alex Ostapenko, вы писали:


AO>Не вижу я нормального способа шифровать акцесные данные, чтобы при этом еще и поиск работал.


С этого надо было и начинать, а точнее и вовсе не надо было.



AO>Щаз. Пираты отнюдь не дураки. Ломают и говаздо более навороченные защиты.


AO>Когда речь идет о шифровании, одним из наиболее важных параметров всегда является надежность шифра. Xor — под этот критерий ну никак не попадает.


Все верно, только все еще и относительно. Про овчинку и ее выделку слышал когда-нибудь?


А что касается шифрования БД Access (с поиском контекстным), то сделать это вполне реально, несмотря на то, что ты не видишь способа. Кода совсем немного потребуется, впределах 1 дня работы. Результат шифр с одним ключом, работать при контекстном поиске будет медленнее, но на взлом потребуется "некоторое время" и опыт... По-крайней мере мою БД зашифрованную таким способом взломаной не видел, она конечно не тысячи долларов стоит, но сотню другую за нее реально платили.
Re[6]: Шифрование баз данных
От: Alex Ostapenko Россия  
Дата: 13.07.01 09:10
Оценка:
Здравствуйте WindJammer, вы писали:

WJ>Здравствуйте Alex Ostapenko, вы писали:



AO>>Не вижу я нормального способа шифровать акцесные данные, чтобы при этом еще и поиск работал.


WJ>С этого надо было и начинать, а точнее и вовсе не надо было.


Это в первую очередь к тебе самому относится.


AO>>Щаз. Пираты отнюдь не дураки. Ломают и говаздо более навороченные защиты.


AO>>Когда речь идет о шифровании, одним из наиболее важных параметров всегда является надежность шифра. Xor — под этот критерий ну никак не попадает.


WJ>Все верно, только все еще и относительно. Про овчинку и ее выделку слышал когда-нибудь?

Знаешь, я видел (и не только видел, но и ломал) не одну защиту, построенную по такому принципу. И уж лучше бы ее авторы не тратили свое время на ее написание.

WJ>А что касается шифрования БД Access (с поиском контекстным), то сделать это вполне реально, несмотря на то, что ты не


Смотри внимательно. Я сказал _нормального_ способа. Если он тебе известен, то будь добр, изложи его. А не лей воду.

>идишь способа. Кода совсем немного потребуется, впределах 1 дня работы. Результат шифр с одним ключом, работать при >онтекстном поиске будет медленнее, но на взлом потребуется "некоторое время" и опыт... По-крайней мере мою БД

>ашифрованную таким способом взломаной не видел, она конечно не тысячи долларов стоит, но сотню другую за нее реально >латили.

Алгоритм шифрования в студию. Тогда будем говорить, сколько опыта и времени понадобиться на его взлом.
Твой пример ровным счетом ни о чем не говорит. Очень вероятно, что твоя база просто мало кому нужна, соответсвенно и браться за нее никто не будет.
Re[7]: Шифрование баз данных
От: WindJammer  
Дата: 13.07.01 09:30
Оценка:
Здравствуйте Alex Ostapenko, вы писали:

AO>Смотри внимательно. Я сказал _нормального_ способа. Если он тебе известен, то будь добр, изложи его. А не лей воду.


Ну так и ты воду не лей, а поясни свое понимание слова _нормальный_

AO>Алгоритм шифрования в студию. Тогда будем говорить, сколько опыта и времени понадобиться на его взлом.

AO>Твой пример ровным счетом ни о чем не говорит. Очень вероятно, что твоя база просто мало кому нужна, соответсвенно и браться за нее никто не будет.

Я указал порядковые цифры в денежном измерении. За БД платили люди из своего кармана, а не взламывали ее легким движением руки.


А что касается "Алгоритм шифрования в студию", у меня есть встречное предложение — "взлом в студию". Я дам свою БД, в понедельник например (если найду), а ты ее взломаешь, вот мы и оценим, сколько нужно времени высоко квалифицированного специалиста на взлом моего алгоритма. Только скажи заранее, что ты согласен и время есть.
Re[8]: Шифрование баз данных
От: Alex Ostapenko Россия  
Дата: 13.07.01 09:46
Оценка:
Здравствуйте WindJammer, вы писали:

AO>>Алгоритм шифрования в студию. Тогда будем говорить, сколько опыта и времени понадобиться на его взлом.

AO>>Твой пример ровным счетом ни о чем не говорит. Очень вероятно, что твоя база просто мало кому нужна, соответсвенно и браться за нее никто не будет.

WJ>Я указал порядковые цифры в денежном измерении. За БД платили люди из своего кармана, а не взламывали ее легким движением руки.



WJ>А что касается "Алгоритм шифрования в студию", у меня есть встречное предложение — "взлом в студию". Я дам свою БД, в понедельник например (если найду), а ты ее взломаешь, вот мы и оценим, сколько нужно времени высоко квалифицированного специалиста на взлом моего алгоритма. Только скажи заранее, что ты согласен и время есть.


Давай. Ближе к следующим выходным. На чем, кстати, написана программа, работающая с базой?
Re[9]: Шифрование баз данных
От: WindJammer  
Дата: 13.07.01 10:07
Оценка:
Здравствуйте Alex Ostapenko, вы писали:

AO>Давай. Ближе к следующим выходным. На чем, кстати, написана программа, работающая с базой?


Давай к следующим.
Программа на VC++.
Написана давно, тогда я только DAO знал. Могу и на ADO, для технологии шифрования разницы нет, кода и там и там не много.
Re[10]: Шифрование баз данных
От: Alex Ostapenko Россия  
Дата: 13.07.01 10:28
Оценка:
Здравствуйте WindJammer, вы писали:

WJ>Здравствуйте Alex Ostapenko, вы писали:


AO>>Давай. Ближе к следующим выходным. На чем, кстати, написана программа, работающая с базой?


WJ>Давай к следующим.


OK.

WJ>Программа на VC++.

WJ>Написана давно, тогда я только DAO знал. Могу и на ADO, для технологии шифрования разницы нет, кода и там и там не много.

Монопенисуально.:) Давай как есть.
Re[11]: Шифрование баз данных
От: IT Россия linq2db.com
Дата: 13.07.01 12:11
Оценка:
AO>>>Давай. Ближе к следующим выходным. На чем, кстати, написана программа, работающая с базой?
WJ>>Давай к следующим.
AO>OK.
WJ>>Программа на VC++.
WJ>>Написана давно, тогда я только DAO знал. Могу и на ADO, для технологии шифрования разницы нет, кода и там и там не много.
AO>Монопенисуально.:) Давай как есть.

Well, well, well...
Это уже интересно :) Как будем проверять достоверность и сроки взлома?
Если нам не помогут, то мы тоже никого не пощадим.
Re[12]: Шифрование баз данных
От: Alex Ostapenko Россия  
Дата: 13.07.01 12:17
Оценка:
Здравствуйте IT, вы писали:

AO>>>>Давай. Ближе к следующим выходным. На чем, кстати, написана программа, работающая с базой?

WJ>>>Давай к следующим.
AO>>OK.
WJ>>>Программа на VC++.
WJ>>>Написана давно, тогда я только DAO знал. Могу и на ADO, для технологии шифрования разницы нет, кода и там и там не много.
AO>>Монопенисуально.:) Давай как есть.

IT>Well, well, well...

IT>Это уже интересно :) Как будем проверять достоверность и сроки взлома?

Ну, с достоверностью проблем вроде нет. Автор ведь знает, что должно получаться.
Со сроками придется верить мне на слово. :)
Re[13]: Шифрование баз данных
От: IT Россия linq2db.com
Дата: 13.07.01 20:27
Оценка:
IT>>Well, well, well...
IT>>Это уже интересно :) Как будем проверять достоверность и сроки взлома?

AO>Ну, с достоверностью проблем вроде нет. Автор ведь знает, что должно получаться.

AO>Со сроками придется верить мне на слово. :)

Как выигрыш делить будем?
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Шифрование баз данных
От: Корнилов Григорий Петрович http://kornilow.newmail.ru
Дата: 14.07.01 12:22
Оценка:
Здравствуйте IT, вы писали:

Все это лажа.
Вот если бы MS SQL Server имел sp_Like..., которую вызывал бы при конструкции Like, передавая параметром строку — а на выходе да/нет !
И вообще — принцип сделай (настрой) сам свой сервер когда-нибудь будет работать ?
Где бы взять перечень sp_..., которыми обрабатывает MS SQL Server запросы, да попереопределять их ...
Re[15]: Шифрование баз данных
От: IT Россия linq2db.com
Дата: 15.07.01 03:23
Оценка:
КГП>Где бы взять перечень sp_..., которыми обрабатывает MS SQL Server запросы, да попереопределять их ...

Знамо где... в M$.
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: Шифрование баз данных
От: Корнилов Григорий Петрович http://kornilow.newmail.ru
Дата: 15.07.01 13:22
Оценка:
Здравствуйте IT, вы писали:

КГП>>Где бы взять перечень sp_..., которыми обрабатывает MS SQL Server запросы, да попереопределять их ...


IT>Знамо где... в M$.


Если это про MSDN, то там нет описания sp_... extended.Или хотя бы параметры и смысл (поподробнее чем название).
Re[15]: Шифрование баз данных
От: Alex Ostapenko Россия  
Дата: 16.07.01 08:14
Оценка:
Здравствуйте Корнилов Григорий Петрович, вы писали:

КГП>Здравствуйте IT, вы писали:


КГП>Все это лажа.

КГП>Вот если бы MS SQL Server имел sp_Like..., которую вызывал бы при конструкции Like, передавая параметром строку — а на выходе да/нет !

ТО это был бы уже не SQL Server, а херня какая-то. Минимум, получился бы тормоз.
Если уж так хочется свой like, то напиши свою xp_черте-че с собственной логикой и вызывай ее вместо select'а.

КГП>И вообще — принцип сделай (настрой) сам свой сервер когда-нибудь будет работать ?


Скорее всего никогда. :)

КГП>Где бы взять перечень sp_..., которыми обрабатывает MS SQL Server запросы, да попереопределять их ...


Не думаю, что программисты из MS такие идиоты, чтобы запросы обрабатывать через sp.
Re[16]: Шифрование баз данных
От: Корнилов Григорий Петрович http://kornilow.newmail.ru
Дата: 17.07.01 05:12
Оценка:
Здравствуйте Alex Ostapenko, вы писали:

AO>ТО это был бы уже не SQL Server, а херня какая-то. Минимум, получился бы тормоз.


Грубо и спорно. Нужные sp_ сервер загружает готовой функцией и вызывает ее при необходимости.
Причин для потери времени не вижу.

AO>Если уж так хочется свой like, то напиши свою xp_черте-че с собственной логикой и вызывай ее вместо select'а.


А вот это предложение убого.

AO>Скорее всего никогда. :)


Никогда не говори 'никогда'.

AO>Не думаю, что программисты из MS такие идиоты, чтобы запросы обрабатывать через sp.


Не 'чтобы'. а 'что'.
Re[17]: Шифрование баз данных
От: Alex Ostapenko Россия  
Дата: 17.07.01 05:47
Оценка:
Здравствуйте Корнилов Григорий Петрович, вы писали:

AO>>ТО это был бы уже не SQL Server, а херня какая-то. Минимум, получился бы тормоз.


КГП>Грубо и спорно. Нужные sp_ сервер загружает готовой функцией и вызывает ее при необходимости.

КГП>Причин для потери времени не вижу.

Грубо — да. Спорить тут вроде бессмысленно.
Причина №1: Откомпилированный алгоритм всегда быстрее скрипта. А sp в машинный код однозначно не компилируется.
Причина №2: Фиксированный алгоритм можно хорошо соптимизировать, чего не сделаешь в предлагаемом варианте.

AO>>Если уж так хочется свой like, то напиши свою xp_черте-че с собственной логикой и вызывай ее вместо select'а.


КГП>А вот это предложение убого.


Может оно и убого, но действенно. Идея ломать всю логику сервера из-за того, что кому-то не понравился встроенный select мне кажется гораздо более убогой.

AO>>Скорее всего никогда. :)


КГП>Никогда не говори 'никогда'.


:) Я не оптимист.

AO>>Не думаю, что программисты из MS такие идиоты, чтобы запросы обрабатывать через sp.


КГП>Не 'чтобы'. а 'что'.


К чему это?
Re[18]: Шифрование баз данных
От: Корнилов Григорий Петрович http://kornilow.newmail.ru
Дата: 17.07.01 10:30
Оценка:
Здравствуйте Alex Ostapenko, вы писали:

AO>Причина №1: Откомпилированный алгоритм всегда быстрее скрипта. А sp в машинный код однозначно не компилируется.


А MS SQL Server расширенные sp_ разве использует по другому? К тому же он кеширует sp_

AO>Может оно и убого, но действенно. Идея ломать всю логику сервера из-за того, что кому-то не понравился встроенный select мне кажется гораздо более убогой.


Нет, не ломать логику — а настраивать логику

AO>К чему это?


К дождю ...
Re[19]: Шифрование баз данных
От: Alex Ostapenko Россия  
Дата: 17.07.01 10:42
Оценка:
Здравствуйте Корнилов Григорий Петрович, вы писали:

AO>>Причина №1: Откомпилированный алгоритм всегда быстрее скрипта. А sp в машинный код однозначно не компилируется.


КГП>А MS SQL Server расширенные sp_ разве использует по другому? К тому же он кеширует sp_


Как "по другому"? Он их переводит в некое внутреннее представление, но никак не в машинный код. А что толку с этого кеширования? Ну не нужно лишний раз строить execution plan, и все.

AO>>Может оно и убого, но действенно. Идея ломать всю логику сервера из-за того, что кому-то не понравился встроенный select мне кажется гораздо более убогой.


КГП>Нет, не ломать логику — а настраивать логику


Это смотря с какой стороны смотреть.

AO>>К чему это?


КГП>К дождю ...


Да, от дождичка я бы не отказался. Жара уже порядком достала. :)
Re[20]: Шифрование баз данных
От: The Lex Украина  
Дата: 18.07.01 11:44
Оценка:
Так что там насчет взлома? Получилось или нет? :) Мне с профессиональной точки зрения интересно...
Голь на выдумку хитра, однако...
Re[21]: Шифрование баз данных
От: IT Россия linq2db.com
Дата: 18.07.01 12:08
Оценка:
TL>Так что там насчет взлома? Получилось или нет? :) Мне с профессиональной точки зрения интересно...

Да, да, да... Просим, просим...
;o)
Если нам не помогут, то мы тоже никого не пощадим.
Re[22]: Шифрование баз данных
От: Аноним  
Дата: 19.07.01 05:40
Оценка:
Здравствуйте IT, вы писали:

TL>>Так что там насчет взлома? Получилось или нет? :) Мне с профессиональной точки зрения интересно...


IT>Да, да, да... Просим, просим...

IT>o)

Обойдётеся — у нас интернет отрубили (БелИнфоСофт)
Re[23]: Шифрование баз данных
От: Alex Ostapenko Россия  
Дата: 19.07.01 06:07
Оценка:
Здравствуйте Аноним, вы писали:

А>Здравствуйте IT, вы писали:


TL>>>Так что там насчет взлома? Получилось или нет? :) Мне с профессиональной точки зрения интересно...


IT>>Да, да, да... Просим, просим...

IT>>o)

Да мы вроде как договаривались начать в конце этой недели, но теперь видимо и это не получится. :)


А>Обойдётеся — у нас интернет отрубили (БелИнфоСофт)


Ну и ладно, у меня похоже выходные все равну будут заняты. :)
Re[23]: Шифрование баз данных
От: IT Россия linq2db.com
Дата: 19.07.01 10:52
Оценка:
IT>>Да, да, да... Просим, просим...
IT>>o)

А>Обойдётеся — у нас интернет отрубили (БелИнфоСофт)


А этот пост ты голубиной почтой отправлял, что ли? ;)
Или ты там защиту улучшаешь? 8)
Если нам не помогут, то мы тоже никого не пощадим.
Re[24]: Шифрование баз данных
От: WindJammer  
Дата: 19.07.01 11:21
Оценка:
Здравствуйте Alex Ostapenko, вы писали:

Здравствуйте IT, вы писали:


1. "Аноним" — это не я (но IT его знает).
2. Инет действительно отрубили, но у нас еще остались дыры.
3. БД готова, какие вопросы? Я же еще в понедельник предлагал. Алгоритм шифрования не меняю, рихтую клиента для промотра шифрованной БД.


Теперь к делу.
to Alex Ostapenko:
Выходные подошли готов к работе? Уточняй дату/время.

to IT:
А как насчет места на rsdn.ru, чтобы было куда закачать БД? Может не только Alex Ostapenko захочет потренироваться?
Re[24]: Шифрование баз данных
От: Аноним  
Дата: 19.07.01 11:35
Оценка:
Здравствуйте IT, вы писали:

IT>>>Да, да, да... Просим, просим...

IT>>>o)

А>>Обойдётеся — у нас интернет отрубили (БелИнфоСофт)


IT>А этот пост ты голубиной почтой отправлял, что ли? ;)

IT>Или ты там защиту улучшаешь? 8)

1) Защита всегда дешевле нападения (взлома), даже в футболе .
2) В Белгороде уже 2 Интернеткафе
3) Это был я — KGP
Re[25]: Шифрование баз данных
От: Alex Ostapenko Россия  
Дата: 19.07.01 12:14
Оценка:
Здравствуйте WindJammer, вы писали:

WJ>Здравствуйте Alex Ostapenko, вы писали:


WJ>Здравствуйте IT, вы писали:



WJ>1. "Аноним" — это не я (но IT его знает).

WJ>2. Инет действительно отрубили, но у нас еще остались дыры.
WJ>3. БД готова, какие вопросы? Я же еще в понедельник предлагал. Алгоритм шифрования не меняю, рихтую клиента для промотра шифрованной БД.


WJ>Теперь к делу.

WJ>to Alex Ostapenko:
WJ>Выходные подошли готов к работе? Уточняй дату/время.

Пиши мне на мыло lexey@isa.ru. Обговорим. Сколько база весит?

WJ>to IT:

WJ>А как насчет места на rsdn.ru, чтобы было куда закачать БД? Может не только Alex Ostapenko захочет потренироваться?

Честно говоря, мне эта "тренировка" нафиг не нужна. Я на это пошел, чтобы не показаться голословным. :)
Re[25]: Шифрование баз данных
От: Alex Ostapenko Россия  
Дата: 19.07.01 12:15
Оценка:
Здравствуйте Аноним, вы писали:

А>1) Защита всегда дешевле нападения (взлома), даже в футболе .


Как оказывается, далеко не всегда. :)
Re[26]: Шифрование баз данных
От: WindJammer  
Дата: 20.07.01 06:05
Оценка:
Здравствуйте Alex Ostapenko, вы писали:


AO>Пиши мне на мыло lexey@isa.ru. Обговорим. Сколько база весит?

Базу выслал.
Ждем-с. Ориентировочные сроки есть?

/*
Жаль, что rsdn.ru так и не нашел места для БД.
Может у них тоже инет отвалился?
*/


AO>Честно говоря, мне эта "тренировка" нафиг не нужна. Я на это пошел, чтобы не показаться голословным. :)


Тут ни чем помочь не могу. Не надо было встревать с комментариями.
Re[27]: Шифрование баз данных
От: Alex Ostapenko Россия  
Дата: 20.07.01 06:59
Оценка:
Здравствуйте WindJammer, вы писали:

WJ>Здравствуйте Alex Ostapenko, вы писали:



AO>>Пиши мне на мыло lexey@isa.ru. Обговорим. Сколько база весит?

WJ>Базу выслал.

Базу получил.

WJ>Ждем-с. Ориентировочные сроки есть?


А где программа просмотра? Голая база мне нафиг не нужна.

WJ>/*

WJ>Жаль, что rsdn.ru так и не нашел места для БД.
WJ>Может у них тоже инет отвалился?
WJ>*/

Такую базу я могу и у себя выложить, если хочешь.

AO>>Честно говоря, мне эта "тренировка" нафиг не нужна. Я на это пошел, чтобы не показаться голословным. :)


WJ>Тут ни чем помочь не могу. Не надо было встревать с комментариями.


А я помощи у тебя и не прошу. Я всего лишь констатирую факт.:)
Re[28]: Шифрование баз данных
От: WindJammer  
Дата: 20.07.01 11:06
Оценка:
Здравствуйте Alex Ostapenko, вы писали:

AO>А где программа просмотра? Голая база мне нафиг не нужна.

/* это было прогнозируемо */
Выслал.
Re[29]: Шифрование баз данных
От: Alex Ostapenko Россия  
Дата: 20.07.01 18:28
Оценка:
Здравствуйте WindJammer, вы писали:

WJ>Здравствуйте Alex Ostapenko, вы писали:


AO>>А где программа просмотра? Голая база мне нафиг не нужна.

WJ>/* это было прогнозируемо */
WJ>Выслал.

Посмотрел я на это чудо. Вот наш ответ Чемберлену: :)
1) Складывается четкая картина того, что инспользован шифр многоалфавитной замены с периодом равным длине пароля. На такой базе, если пароль не слишком короткий, его хрен вскроешь, т.к. данных для набора нужной статистики маловато. На паре тысячей записей взлом уже вполне реален.
2) Что-то я в упор не наблюдаю работающего контекстного поиска. :) Я в общем-то догадываюсь, как ты его собирался делать — что в стиле LIKE enc_str(pass,pattern) OR LIKE '%+enc_str(shift(pass),pattern)+%' OR... (число OR'ов равно длине пароля). Но это, ИМХО, полнейший изврат. Для приличной по размеру базы это очень неслабо увеличивает расходы на выборку, да еще и фильтровать результаты самому еще раз придется.

В общем, как защита от дурака для баз малого размера оно вполне годится, но не более.
Re[30]: Шифрование баз данных
От: WindJammer  
Дата: 21.07.01 06:47
Оценка:
Здравствуйте Alex Ostapenko, вы писали:

AO>Посмотрел я на это чудо. Вот наш ответ Чемберлену: :)

AO>1) Складывается четкая картина того, что инспользован шифр многоалфавитной замены с периодом равным длине пароля. На такой базе, если пароль не слишком короткий, его хрен вскроешь, т.к. данных для набора нужной статистики маловато. На паре тысячей записей взлом уже вполне реален.
AO>2) Что-то я в упор не наблюдаю работающего контекстного поиска. :) Я в общем-то догадываюсь, как ты его собирался делать — что в стиле LIKE enc_str(pass,pattern) OR LIKE '%+enc_str(shift(pass),pattern)+%' OR... (число OR'ов равно длине пароля). Но это, ИМХО, полнейший изврат. Для приличной по размеру базы это очень неслабо увеличивает расходы на выборку, да еще и фильтровать результаты самому еще раз придется.



Контекстный поиск в высланном exe был отключен. Так сложилось, что дома он у меня работал, а на работе нет, я решил разобраться и не успел к твоему требованию прислать exe-шник.
Контекстный поиск действительно будет сильно ограничен размерами полей и искомой подстроки. Фильтровать результаты его поиска не обязательно, это как запрос делать. Сейчас я делаю один запрос, возвращающий полностью соответствующую выборку. Но количество OR там будет равно <длина пароля> ((<Макс. Длина строки в БД> — <длина определенных символов в подстроке поиска (не %)>)^<Количество знаков %>).
Т.е. поиск действительно ограничен, но он есть.

Ну и, кратко твои итоги:
1. БД не вскрыта.
2. Обещано легкое вскрытие при более других объемах.
3. Технология контекстного поиска названа «полнейшим извратом». /*Лично мне в твоих репликах всегда нравилась конкретность, как с классификатором «нормальный».*/


Мои реплики:
1. Я не говорил, что БД нельзя взломать не при каких размерах.
2. Я не говорил, что быстродействие контекстного поиска не снизится.
3. Я не говорил, что нет проблем с масштабируемостью этого решения.
4. Я говорил, что реализация технологии займет около 1 дня кодирования, что значит дешево.
5. Оценку метода шифрования можно производить только исходя из условий, ограничений и требований. e-yes не описывал условия. Если не считать, что БД – Access, из чего можно косвенно вывести, что система дешевая и не большая.





AO>В общем, как защита от дурака для баз малого размера оно вполне годится, но не более.

Ну, зачем же так самокритично. Ну, подлый я, дал маленькую БД, зачем же так убиваться, по этому поводу. :)
Re[31]: Шифрование баз данных
От: Alex Ostapenko Россия  
Дата: 21.07.01 08:21
Оценка:
Здравствуйте WindJammer, вы писали:

WJ>Здравствуйте Alex Ostapenko, вы писали:


AO>>Посмотрел я на это чудо. Вот наш ответ Чемберлену: :)

AO>>1) Складывается четкая картина того, что инспользован шифр многоалфавитной замены с периодом равным длине пароля. На такой базе, если пароль не слишком короткий, его хрен вскроешь, т.к. данных для набора нужной статистики маловато. На паре тысячей записей взлом уже вполне реален.
AO>>2) Что-то я в упор не наблюдаю работающего контекстного поиска. :) Я в общем-то догадываюсь, как ты его собирался делать — что в стиле LIKE enc_str(pass,pattern) OR LIKE '%+enc_str(shift(pass),pattern)+%' OR... (число OR'ов равно длине пароля). Но это, ИМХО, полнейший изврат. Для приличной по размеру базы это очень неслабо увеличивает расходы на выборку, да еще и фильтровать результаты самому еще раз придется.



WJ>Контекстный поиск в высланном exe был отключен. Так сложилось, что дома он у меня работал, а на работе нет, я решил разобраться и не успел к твоему требованию прислать exe-шник.

WJ>Контекстный поиск действительно будет сильно ограничен размерами полей и искомой подстроки. Фильтровать результаты его поиска не обязательно, это как запрос делать. Сейчас я делаю один запрос, возвращающий полностью соответствующую выборку. Но количество OR там будет равно <длина пароля> ((<Макс. Длина строки в БД> — <длина определенных символов в подстроке поиска (не %)>)^<Количество знаков %>).

8-( )
Простейшая прикидка: пароль — 10 символов, длина строки текса — 40 символов, запрос вида %blabla%.
Число OR'ов по твоей формуле = 10*(40-6)^2= 10240?!!. (челюсть медленно падает на пол).

WJ>Т.е. поиск действительно ограничен, но он есть.

Если ЭТО поиск, то я балерина.


WJ>Ну и, кратко твои итоги:

WJ>1. БД не вскрыта.

Увы, статистические методы не работают при таком объеме данных.

WJ>2. Обещано легкое вскрытие при более других объемах.

Угу. Более других — это раз в 20 больше строк, что для нормальной базы совсем небольшое число.

WJ>3. Технология контекстного поиска названа «полнейшим извратом». /*Лично мне в твоих репликах всегда нравилась конкретность, как с классификатором «нормальный».*/


Подобную идею "нормального" поиска я выбросил в первый же момент.

WJ>

WJ>Мои реплики:
WJ>1. Я не говорил, что БД нельзя взломать не при каких размерах.

Причем тут ни при каких? Для базы, даже для акцесной, 2000 строк текста по 20 символов — это не размер.

WJ>2. Я не говорил, что быстродействие контекстного поиска не снизится.


Снизится?! Да оно вообще будет никаким. Гораздо быстрее будет расшифровать всю базу в память и натравить на нее regexp.

WJ>3. Я не говорил, что нет проблем с масштабируемостью этого решения.

WJ>4. Я говорил, что реализация технологии займет около 1 дня кодирования, что значит дешево.

Угу, написать полное считывание базы в память, ее дешифрование и поиск по памяти — те же 1-2 дня работы. Но при этом можно наложить нормальную криптуху и работать оно будет быстрее.

WJ>5. Оценку метода шифрования можно производить только исходя из условий, ограничений и требований.


Это единственное, с чем можно тут согласиться.

e-yes не описывал условия. Если не считать, что БД – Access, из чего можно косвенно вывести, что
система дешевая и не большая.

Ниоткуда это не следует. Мне попадались системы, использующие mdb для сбора логов. Базы там легко получались мегов по 5-10. И стоили эти системы отнюдь не кисло (по паре штук баксов), вот только шифровать там данные никому в голову не приходило.

AO>>В общем, как защита от дурака для баз малого размера оно вполне годится, но не более.

WJ>Ну, зачем же так самокритично. Ну, подлый я, дал маленькую БД, зачем же так убиваться, по этому поводу. :)

Я бы на твоем месте поплакал и пошел бы переквалифицироваться в управдомы. Разработчик систем защиты из тебя похоже вообще никакой.
Re[32]: Шифрование баз данных
От: IT Россия linq2db.com
Дата: 21.07.01 13:28
Оценка:
AO>Я бы на твоем месте поплакал и пошел бы переквалифицироваться в управдомы. Разработчик систем защиты из тебя похоже вообще никакой.

Alex, плиз, соблюдаем корректность.
Если нам не помогут, то мы тоже никого не пощадим.
Re[33]: Шифрование баз данных
От: Alex Ostapenko Россия  
Дата: 21.07.01 17:59
Оценка:
Здравствуйте IT, вы писали:

AO>>Я бы на твоем месте поплакал и пошел бы переквалифицироваться в управдомы. Разработчик систем защиты из тебя похоже вообще никакой.


IT>Alex, плиз, соблюдаем корректность.


OK. Прошу прощения, не сдержался.
Я со своей стороны топик закрываю. WildJammer, если у тебя есть желание еще поспорить, переходи в мыло.
Re[32]: Шифрование баз данных
От: WindJammer  
Дата: 21.07.01 19:08
Оценка:
Здравствуйте Alex Ostapenko, вы писали:


AO>8-( )

AO>Простейшая прикидка: пароль — 10 символов, длина строки текса — 40 символов, запрос вида %blabla%.
AO>Число OR'ов по твоей формуле = 10*(40-6)^2= 10240?!!. (челюсть медленно падает на пол).
Sorry, челюсть можешь медленно подобрать. Немного я общелкнулся в своей формуле. На длину пароля умножать не надо, да в степень чуть поменьше возводить.



WJ>>Ну и, кратко твои итоги:

WJ>>1. БД не вскрыта.

AO>Увы, статистические методы не работают при таком объеме данных.


WJ>>2. Обещано легкое вскрытие при более других объемах.

AO>Угу. Более других — это раз в 20 больше строк, что для нормальной базы совсем небольшое число.
Ok. Предлагаю все-таки установить размеры при которых статические методы сработаю в данном случае. В 20 раз больше это 2тыс. Предлагаю для оценки БД в 10 тыс., так что бы по мелочам не размениваться. Как, согласен?



WJ>>4. Я говорил, что реализация технологии займет около 1 дня кодирования, что значит дешево.


AO>Угу, написать полное считывание базы в память, ее дешифрование и поиск по памяти — те же 1-2 дня работы. Но при этом можно наложить нормальную криптуху и работать оно будет быстрее.


Вот видишь, прошло чуть более недели, а ты уже смог что-то и сам предложить на вопрос e-yes, а сначала говорил не вижу, не вижу... Хотя 1-2 дня, сомнительно…


AO>Ниоткуда это не следует. Мне попадались системы, использующие mdb для сбора логов. Базы там легко получались мегов по 5-10. И стоили эти системы отнюдь не кисло (по паре штук баксов), вот только шифровать там данные никому в голову не приходило.

Вообще-то, я бы не сказал, что 5-10мегов это мног, как и пара штук баксов, MS SQL полторы-то стоит.

AO>>>В общем, как защита от дурака для баз малого размера оно вполне годится, но не более.

WJ>>Ну, зачем же так самокритично. Ну, подлый я, дал маленькую БД, зачем же так убиваться, по этому поводу. :)

AO>Я бы на твоем месте поплакал и пошел бы переквалифицироваться в управдомы. Разработчик систем защиты из тебя похоже вообще никакой.

Ты же сам написал: "...как защита от дурака для баз малого размера оно вполне годится...", базу я тебе послал малого размера, ты ее не сломал, защита устояла, отсюда и следующий вывод...
Re[34]: Шифрование баз данных
От: WindJammer  
Дата: 22.07.01 10:05
Оценка:
AO>Я со своей стороны топик закрываю. WildJammer, если у тебя есть желание еще поспорить, переходи в мыло.


Что и требовалось доказать.



Если вам не противостоят серьезные организации и ваш продукт, который вы защищаете, не имеет широкого распространения, то даже самых примитивных мер будет достаточно, чтобы защититься. Теоретиков много, а вот практиков нет.
Re[34]: Шифрование баз данных
От: Корнилов Григорий Петрович http://kornilow.newmail.ru
Дата: 23.07.01 06:55
Оценка:
Здравствуйте Alex Ostapenko, вы писали:

AO>Я со своей стороны топик закрываю. WildJammer, если у тебя есть желание еще поспорить, переходи в мыло.


Жаль, что мы так и не услышали начальника транспортного цеха ...
Re[35]: Шифрование баз данных
От: The Lex Украина  
Дата: 23.07.01 08:46
Оценка:
Досадно, конечно, что все свелось к банальной перебранке между разработчиками...
Голь на выдумку хитра, однако...
Re[36]: Шифрование баз данных
От: WindJammer  
Дата: 24.07.01 06:47
Оценка:
Здравствуйте The Lex, вы писали:

TL>Досадно, конечно, что все свелось к банальной перебранке между разработчиками...


Во-первых, я бы не сказал: "все свелось", я бы сказал, что все началось с понтоватой оценки одним качеств другого, в то время как давать ее (оценку) никто не просил.
Во-вторых, _перебранки_ настолько обыденны, что к ним давно пора привыкнуть и "фильтровать" их при чтении форумов, IMHO.

А главное, во всем этом обсуждении/базаре/перебранке я лично вижу вполне конкретный результат — предложена элементарнейшая технология шифрования, которая хотя и имеет ряд серьезных ограничений и недостатков, связанных масштабируемостью, показала хороший коэффициент <сложность взлома>/<стоимость реализации>.
Re[37]: Шифрование баз данных
От: The Lex Украина  
Дата: 24.07.01 15:32
Оценка:
Здравствуйте WindJammer, вы писали:

WJ>Здравствуйте The Lex, вы писали:


WJ>Во-вторых, _перебранки_ настолько обыденны, что к ним давно пора привыкнуть и "фильтровать" их при чтении форумов, IMHO.


Оно то конечно так, но от того не менее обидно... :)

WJ>А главное, во всем этом обсуждении/базаре/перебранке я лично вижу вполне конкретный результат — предложена элементарнейшая технология шифрования, которая хотя и имеет ряд серьезных ограничений и недостатков, связанных масштабируемостью, показала хороший коэффициент <сложность взлома>/<стоимость реализации>.


Хм... Увы, я этой технологии не увидел. Скорее всего, я недостаточно хорошо внимательно "фильтровал"... :)
Голь на выдумку хитра, однако...
Re[38]: Шифрование баз данных
От: WindJammer  
Дата: 25.07.01 06:20
Оценка:
Здравствуйте The Lex, вы писали:

WJ>>А главное, во всем этом обсуждении/базаре/перебранке я лично вижу вполне конкретный результат — предложена элементарнейшая технология шифрования, которая хотя и имеет ряд серьезных ограничений и недостатков, связанных масштабируемостью, показала хороший коэффициент <сложность взлома>/<стоимость реализации>.


TL>Хм... Увы, я этой технологии не увидел. Скорее всего, я недостаточно хорошо внимательно "фильтровал"... :)


:)
Я не писал, что показал технологию, я писал, что предложил, а до вас никто желание увидеть ее не излагал...

Ниже класс, который выполняет шифрование.



// Crypto.h: interface for the CCrypto class.
//
//////////////////////////////////////////////////////////////////////

#if !defined(AFX_CRYPTO_H__67A3B55E_F3A0_44AD_BAFC_DF3F41A3B1DF__INCLUDED_)
#define AFX_CRYPTO_H__67A3B55E_F3A0_44AD_BAFC_DF3F41A3B1DF__INCLUDED_

#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000

class CCrypto
{
public:
CString EnCrypt(CString str);
CString Crypt(CString str);
CString DoCrypt(CString str, bool bCrypt);
CString DoCrypt(CString str, bool bCrypt, int iLen);
CString m_strKey;
CCrypto();
virtual ~CCrypto();

protected:
TCHAR Wrap(TCHAR tc1, TCHAR tc2, int iWay);
TCHAR m_aTable[155];
};

#endif // !defined(AFX_CRYPTO_H__67A3B55E_F3A0_44AD_BAFC_DF3F41A3B1DF__INCLUDED_)




// Crypto.cpp: implementation of the CCrypto class.
//
//////////////////////////////////////////////////////////////////////

#include "stdafx.h"
#include "CryptoExm.h"
#include "Crypto.h"

#ifdef _DEBUG
#undef THIS_FILE
static char THIS_FILE[]=__FILE__;
#define new DEBUG_NEW
#endif

//////////////////////////////////////////////////////////////////////
// Construction/Destruction
//////////////////////////////////////////////////////////////////////
const int s_nTable=143;
CCrypto::CCrypto()
{
m_aTable[0]='A';
m_aTable[1]='a';
m_aTable[2]='B';
m_aTable[3]='b';
m_aTable[4]='C';
m_aTable[5]='c';
m_aTable[6]='D';
m_aTable[7]='d';
m_aTable[8]='E';
m_aTable[9]='e';
m_aTable[10]='F';
m_aTable[11]='f';
m_aTable[12]='G';
m_aTable[13]='g';
m_aTable[14]='J';
m_aTable[15]='j';
m_aTable[16]='H';
m_aTable[17]='h';
m_aTable[18]='I';
m_aTable[19]='i';
m_aTable[20]='K';
m_aTable[21]='k';
m_aTable[22]='L';
m_aTable[23]='l';
m_aTable[24]='M';
m_aTable[25]='m';
m_aTable[26]='N';
m_aTable[27]='n';
m_aTable[28]='O';
m_aTable[29]='o';
m_aTable[30]='P';
m_aTable[31]='p';
m_aTable[32]='R';
m_aTable[33]='r';
m_aTable[34]='S';
m_aTable[35]='s';
m_aTable[36]='T';
m_aTable[37]='t';
m_aTable[38]='Q';
m_aTable[39]='q';
m_aTable[40]='Y';
m_aTable[41]='y';
m_aTable[42]='U';
m_aTable[43]='u';
m_aTable[44]='W';
m_aTable[45]='w';
m_aTable[46]='X';
m_aTable[47]='x';
m_aTable[48]='Z';
m_aTable[49]='z';
m_aTable[50]='V';
m_aTable[51]='v';
m_aTable[52]='А';
m_aTable[53]='а';
m_aTable[54]='Б';
m_aTable[55]='б';
m_aTable[56]='В';
m_aTable[57]='в';
m_aTable[58]='Г';
m_aTable[59]='г';
m_aTable[60]='Д';
m_aTable[61]='д';
m_aTable[62]='Е';
m_aTable[63]='е';
m_aTable[64]='Ж';
m_aTable[65]='ж';
m_aTable[66]='З';
m_aTable[67]='з';
m_aTable[68]='И';
m_aTable[69]='и';
m_aTable[70]='Й';
m_aTable[71]='й';
m_aTable[72]='К';
m_aTable[73]='к';
m_aTable[74]='Л';
m_aTable[75]='л';
m_aTable[76]='М';
m_aTable[77]='м';
m_aTable[78]='Н';
m_aTable[79]='н';
m_aTable[80]='О';
m_aTable[81]='о';
m_aTable[82]='П';
m_aTable[83]='п';
m_aTable[84]='Р';
m_aTable[85]='р';
m_aTable[86]='С';
m_aTable[87]='с';
m_aTable[88]='Т';
m_aTable[89]='т';
m_aTable[90]='У';
m_aTable[91]='у';
m_aTable[92]='Х';
m_aTable[93]='х';
m_aTable[94]='Ф';
m_aTable[95]='ф';
m_aTable[96]='Ш';
m_aTable[97]='ш';
m_aTable[98]='Щ';
m_aTable[99]='щ';
m_aTable[100]='Ц';
m_aTable[101]='ц';
m_aTable[102]='Ч';
m_aTable[103]='ч';
m_aTable[104]='Ь';
m_aTable[105]='ь';
m_aTable[106]='Ы';
m_aTable[107]='ы';
m_aTable[108]='Ъ';
m_aTable[109]='ъ';
m_aTable[110]='Э';
m_aTable[111]='э';
m_aTable[112]='Ю';
m_aTable[113]='ю';
m_aTable[114]='Я';
m_aTable[115]='я';
m_aTable[116]=' ';
m_aTable[117]='.';
m_aTable[118]=',';
m_aTable[119]='!';
m_aTable[120]='=';
m_aTable[121]=';';
m_aTable[122]=':';
m_aTable[123]='+';
m_aTable[124]='(';
m_aTable[125]=')';
m_aTable[126]='*';
m_aTable[127]='Ё';
m_aTable[128]='ё';
m_aTable[129]='-';
m_aTable[130]='0';
m_aTable[131]='1';
m_aTable[132]='2';
m_aTable[133]='3';
m_aTable[134]='4';
m_aTable[135]='5';
m_aTable[136]='6';
m_aTable[137]='7';
m_aTable[138]='8';
m_aTable[139]='9';

m_aTable[140]='$';
m_aTable[141]='^';
m_aTable[142]='&';
}

CCrypto::~CCrypto()
{

}

//
CString CCrypto::Crypt(CString str)
{
return DoCrypt(str, true);
}

CString CCrypto::EnCrypt(CString str)
{
return DoCrypt(str, false);
}


//

TCHAR CCrypto::Wrap(TCHAR tc1, TCHAR tc2, int iWay)
{
int i, i1, i2;
i1=i2=-1;
for(i=0;i<s_nTable;i++)
{
if(m_aTable[i]==tc1)
i1=i;
if(m_aTable[i]==tc2)
i2=i;
}
if(i1<0 || i2<0)
return tc1;
i=i1+iWay*i2;
if(i>=s_nTable)
i-=s_nTable;
if(i<0)
i+=s_nTable;
return m_aTable[i];
}

CString CCrypto::DoCrypt(CString str, bool bCrypt)
{
int iLen;
iLen=str.GetLength();
return DoCrypt(str,bCrypt,iLen);
}

CString CCrypto::DoCrypt(CString str, bool bCrypt, int iLen)
{
CString strRet, strKey;
int iLenKey, i, j, iCrypt;
iCrypt=(bCrypt ? 1 : -1);
bool bWay;
strKey=m_strKey;
iLenKey=strKey.GetLength();
if(iLenKey<1)
return str;
i=iLen-iLenKey;
bWay=(i<0);
i=iLen/iLenKey;
j=iLen-i*iLenKey;

for(i=0;i<iLen;i++)
{
strRet+=Wrap(str.GetAt(i),strKey.GetAt(j),iCrypt);
if(bWay)
{
j++;
if(j==iLenKey)
j=0;
}
else
{
j--;
if(j<0)
j=iLenKey-1;
}
}


return strRet;

}
Re[39]: Шифрование баз данных
От: Alex Ostapenko Россия  
Дата: 25.07.01 07:26
Оценка:
Здравствуйте WindJammer, вы писали:

WJ>Ниже класс, который выполняет шифрование.


<skip>

Мда, тут я все же не сдержусь. :)
Ты про такие вещи как static или функция strchr когда-нибудь слышал? :)
Я бы постеснялся вставлять такой дубовый код в коммерческий продукт и выставлять его напоказ.
Re[40]: Шифрование баз данных
От: WindJammer  
Дата: 25.07.01 14:44
Оценка:
Здравствуйте Alex Ostapenko, вы писали:

AO>Мда, тут я все же не сдержусь. :)

А надо было. А то опять вспомнят про твои порывы расшифровать БД на раз-два... Ты сам забыл, что ли?


AO>Ты про такие вещи как static или функция strchr когда-нибудь слышал? :)

AO>Я бы постеснялся вставлять такой дубовый код в коммерческий продукт и выставлять его напоказ.
А это говорит о том, что ты относишься именно к той большой категории теоретиков умников.
Re[40]: Шифрование баз данных
От: WindJammer  
Дата: 25.07.01 15:13
Оценка:
Здравствуйте Alex Ostapenko, вы писали:

AO>Ты про такие вещи как static или функция strchr когда-нибудь слышал? :)

AO>Я бы постеснялся вставлять такой дубовый код в коммерческий продукт и выставлять его напоказ.

Что-то я погорячился в прошлом постинге и забыл о главном.

Перепиши код с помощь любых функций и попробуй доказать, что код стал хотя бы на процентов на 10 быстрей, когда докажешь, я задам тебе вопрос, почему ты не пишешь на ассемблере, это же даст еще более эффективный код. Хотя я и уверен, что это ты сделать не в состоянии.
Re[41]: Шифрование баз данных
От: WindJammer  
Дата: 25.07.01 15:38
Оценка:
/*
Опять поспешил жать «Отправить»
*/

Я уже тебе намекал на то, что не плохо бы в диалоге, при оценки кода, технологий и т.д., использовать более иные термины, чем «изврат», «дубовый»... Причем, желательно, что бы оценка была критериальной, а не так, как у тебя получалось до этого.

Так что, ждем с нетерпением твоих выкладок, объясняющих твое понимание слова «дубовый».

Да, и еще. Если решишься показать преимущество применения других функций в представленом алгоритме, сначала потренируйся дома, проценты посчитай, а только потом говори, что готов доказать, а то лажанешься, как прошлый раз с расшифровкой.
Re[39]: Шифрование баз данных
От: The Lex Украина  
Дата: 25.07.01 16:09
Оценка:
Здравствуйте WindJammer, вы писали:

WJ>Ниже класс, который выполняет шифрование.


WJ>// Crypto.h: interface for the CCrypto class.

WJ>//
WJ>// И еще много разного кода...

Уважаемый господин WindJammer. Надеюсь Вы понимаете, что подобного кода можно написать неисчислимое количество вариантов. Суть от этого особо не изменится. Как и его ценность.

Меня же интересует не технология шифрования некоторых массивов данных, например, строк, а технология применения Вашего великолепного класса в самой базе данных. Каким образом Вы производите подключение всего этого к файлу *.mdb? Каким образом происходит работа клиента с базой данных? Возможна ли работа с базой данных посредством самого Access? Вот какие соображения было бы в высшей степени занимательно от Вас услышать...

С глубоким уважением...
Голь на выдумку хитра, однако...
Re[41]: Шифрование баз данных
От: Alex Ostapenko Россия  
Дата: 25.07.01 17:32
Оценка:
Здравствуйте WindJammer, вы писали:

WJ>Здравствуйте Alex Ostapenko, вы писали:


AO>>Ты про такие вещи как static или функция strchr когда-нибудь слышал? :)

AO>>Я бы постеснялся вставлять такой дубовый код в коммерческий продукт и выставлять его напоказ.

WJ>Что-то я погорячился в прошлом постинге и забыл о главном.


Я смотрю,ты только и делаешь, что горячишься.

WJ>Перепиши код с помощь любых функций и попробуй доказать, что код стал хотя бы на процентов на 10 быстрей, когда докажешь, я задам тебе вопрос, почему ты не пишешь на ассемблере, это же даст еще более эффективный код. Хотя я и уверен, что это ты сделать не в состоянии.


Влом. Мне сайчас и других забот хватает. Приведу лишь пару мест, в которых напрашиваются явные замены:
1)
m_Table[0]='A'
....

Прекрасно заменяется на
const static char m_Charset[]="Aa...."; Это и быстрее работает и код уменьшает и смотрится намного лучше.

2) if(m_Table[i]==tc1) меняем на
pc1=strchr(m_Charset,tc1). Это тоже работает быстрее. Поиск второго символа вообще выносится в инициализацию, т.к. пароль постоянен в процессе шифрования.

Дальше меня просто уже заломало смотреть, думаю, что можно было бы найти еще не одно место, которое можно оптимизировать. Прирост производительности можешь сам оценить (есть большое подозрение, что он явно превзойдет 10%).

3) Если ты хочешь еще побиться за скорость, то строка символов один раз преобразуется в массив индексов, а символ потом используется как индекс в этом массиве (не слишком красиво, но суть излагает). Впрочем, и это не предел. Можно создать массивы подстановок алфавита для всех символов пароля — это будет быстрее всего, но памяти много будет кушать.

Что касается моего несостояния писать на асме, спорить особо не буду, т.к. тут я действительно не очень силен — размер моей максимальной проги на асме PDP-11 в сорцах составлял всего лишь 25kb. Asm x86 я просто не люблю за его крайнюю нелогичность по сравнению с PDPшным, да и писать мне на нем почти ничего не приходится. Разве что пару кейгенов написал, да один эмулятор timehasp'а вставил в прогу.:)
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.