Здравствуйте The Lex, вы писали:
TL>Надеюсь Вы понимаете, что подобного кода можно написать неисчислимое количество вариантов. Суть от этого особо не изменится. Как и его ценность.
Да.
TL>Меня же интересует не технология шифрования некоторых массивов данных, например, строк, а технология применения Вашего великолепного класса в самой базе данных.
Перед записью шифровать, после чтения расшифровывать, перед передачей подстроки поиска ее преобразовывать. TL>Каким образом Вы производите подключение всего этого к файлу *.mdb?
Чего всего к mdb? TL>Каким образом происходит работа клиента с базой данных?
Через ADO, например. TL>Возможна ли работа с базой данных посредством самого Access?
Нет
E-yes, достаточно точно описал проблему. Он написал, что нельзя шифровать строки самостоятельно, поскольку используется контекстный поиск. Я предложил шифровать строки самостоятельно, а при контекстном поиске подставлять предварительно преобразованный запрос.
Все дальнейше обсуждение возникло только благодаря пытливому уму Алекса. С целью показать, что практика отличается от теории, что за несколько часов можно добавить в приложение функции шифрования, взлом которых... (повторяться не буду). Я ни разу не сказал, что это мое ной-хау, я почеркивал, что это элементарнейшая технология. /* это комментарии к вашей ирони */
Как защитить базу данных Access (.mdb) от пиратского использования?
Стандартное шифрование от MS не подходит (сами знаете;).
Шифровать поля самостоятельно — тоже не выход (используется контекстный поиск).
Неужели придется отказаться от DAO?
Здравствуйте e-yes, вы писали:
EY>Шифровать поля самостоятельно — тоже не выход (используется контекстный поиск).
Почему? Перед тем как искать подстроку зашифруйте и ее тем же методом.
Здравствуйте WindJammer, вы писали:
WJ>Здравствуйте e-yes, вы писали:
EY>>Шифровать поля самостоятельно — тоже не выход (используется контекстный поиск). WJ>Почему? Перед тем как искать подстроку зашифруйте и ее тем же методом.
:))))) Видимо ты очень слабо представляешь себе нормальные блочные шифры. То, что ты предлагаешь, годиться только для чего-нибудь типа ксора.
Здравствуйте Alex Ostapenko, вы писали:
AO>:))))) Видимо ты очень слабо представляешь себе нормальные блочные шифры. То, что ты предлагаешь, годиться только для чего-нибудь типа ксора.
Жаль, что человек столь сильно представляющий себе нормальные блочные шифры, так и не проявил себя советом в тему...
Случаи бывают разные, иногда даже простого ксора хватит для защиты от пиратского использования, в то же время, как затраты на реализацию такого метода минимальны. e-yes не уточнял, какая степень защиты ему нужна. И не писал, что хочет нормальные блочные шифры.
Здравствуйте WindJammer, вы писали:
WJ>Здравствуйте Alex Ostapenko, вы писали:
AO>>:))))) Видимо ты очень слабо представляешь себе нормальные блочные шифры. То, что ты предлагаешь, годиться только для чего-нибудь типа ксора.
WJ>Жаль, что человек столь сильно представляющий себе нормальные блочные шифры, так и не проявил себя советом в тему...
А мне жаль, что ты проявил себя советом не в тему. Я не люблю давать советы, которые нафиг никому не нужны. Не вижу я нормального способа шифровать акцесные данные, чтобы при этом еще и поиск работал.
WJ>Случаи бывают разные, иногда даже простого ксора хватит для защиты от пиратского использования, в то же время, как
Щаз. Пираты отнюдь не дураки. Ломают и говаздо более навороченные защиты.
>затраты на реализацию такого метода минимальны. e-yes не уточнял, какая степень защиты ему нужна. И не писал, что хочет
Польза от него тоже минимальна.
>нормальные блочные шифры.
Когда речь идет о шифровании, одним из наиболее важных параметров всегда является надежность шифра. Xor — под этот критерий ну никак не попадает.
Здравствуйте Корнилов Григорий Петрович, вы писали:
КГП>Здравствуйте Alex Ostapenko, вы писали:
AO>>Здравствуйте WindJammer, вы писали: WJ>>>Здравствуйте Alex Ostapenko, вы писали:
КГП>А толковый совет по теме ... КГП>Ну а пиз..ь — не мешки ворочать.
AO>Не вижу я нормального способа шифровать акцесные данные, чтобы при этом еще и поиск работал.
С этого надо было и начинать, а точнее и вовсе не надо было.
AO>Щаз. Пираты отнюдь не дураки. Ломают и говаздо более навороченные защиты.
AO>Когда речь идет о шифровании, одним из наиболее важных параметров всегда является надежность шифра. Xor — под этот критерий ну никак не попадает.
Все верно, только все еще и относительно. Про овчинку и ее выделку слышал когда-нибудь?
А что касается шифрования БД Access (с поиском контекстным), то сделать это вполне реально, несмотря на то, что ты не видишь способа. Кода совсем немного потребуется, впределах 1 дня работы. Результат шифр с одним ключом, работать при контекстном поиске будет медленнее, но на взлом потребуется "некоторое время" и опыт... По-крайней мере мою БД зашифрованную таким способом взломаной не видел, она конечно не тысячи долларов стоит, но сотню другую за нее реально платили.
Здравствуйте WindJammer, вы писали:
WJ>Здравствуйте Alex Ostapenko, вы писали:
AO>>Не вижу я нормального способа шифровать акцесные данные, чтобы при этом еще и поиск работал.
WJ>С этого надо было и начинать, а точнее и вовсе не надо было.
Это в первую очередь к тебе самому относится.
AO>>Щаз. Пираты отнюдь не дураки. Ломают и говаздо более навороченные защиты.
AO>>Когда речь идет о шифровании, одним из наиболее важных параметров всегда является надежность шифра. Xor — под этот критерий ну никак не попадает.
WJ>Все верно, только все еще и относительно. Про овчинку и ее выделку слышал когда-нибудь?
Знаешь, я видел (и не только видел, но и ломал) не одну защиту, построенную по такому принципу. И уж лучше бы ее авторы не тратили свое время на ее написание.
WJ>А что касается шифрования БД Access (с поиском контекстным), то сделать это вполне реально, несмотря на то, что ты не
Смотри внимательно. Я сказал _нормального_ способа. Если он тебе известен, то будь добр, изложи его. А не лей воду.
>идишь способа. Кода совсем немного потребуется, впределах 1 дня работы. Результат шифр с одним ключом, работать при >онтекстном поиске будет медленнее, но на взлом потребуется "некоторое время" и опыт... По-крайней мере мою БД >ашифрованную таким способом взломаной не видел, она конечно не тысячи долларов стоит, но сотню другую за нее реально >латили.
Алгоритм шифрования в студию. Тогда будем говорить, сколько опыта и времени понадобиться на его взлом.
Твой пример ровным счетом ни о чем не говорит. Очень вероятно, что твоя база просто мало кому нужна, соответсвенно и браться за нее никто не будет.
Здравствуйте Alex Ostapenko, вы писали:
AO>Смотри внимательно. Я сказал _нормального_ способа. Если он тебе известен, то будь добр, изложи его. А не лей воду.
Ну так и ты воду не лей, а поясни свое понимание слова _нормальный_
AO>Алгоритм шифрования в студию. Тогда будем говорить, сколько опыта и времени понадобиться на его взлом. AO>Твой пример ровным счетом ни о чем не говорит. Очень вероятно, что твоя база просто мало кому нужна, соответсвенно и браться за нее никто не будет.
Я указал порядковые цифры в денежном измерении. За БД платили люди из своего кармана, а не взламывали ее легким движением руки.
А что касается "Алгоритм шифрования в студию", у меня есть встречное предложение — "взлом в студию". Я дам свою БД, в понедельник например (если найду), а ты ее взломаешь, вот мы и оценим, сколько нужно времени высоко квалифицированного специалиста на взлом моего алгоритма. Только скажи заранее, что ты согласен и время есть.
Здравствуйте WindJammer, вы писали:
AO>>Алгоритм шифрования в студию. Тогда будем говорить, сколько опыта и времени понадобиться на его взлом. AO>>Твой пример ровным счетом ни о чем не говорит. Очень вероятно, что твоя база просто мало кому нужна, соответсвенно и браться за нее никто не будет.
WJ>Я указал порядковые цифры в денежном измерении. За БД платили люди из своего кармана, а не взламывали ее легким движением руки.
WJ>А что касается "Алгоритм шифрования в студию", у меня есть встречное предложение — "взлом в студию". Я дам свою БД, в понедельник например (если найду), а ты ее взломаешь, вот мы и оценим, сколько нужно времени высоко квалифицированного специалиста на взлом моего алгоритма. Только скажи заранее, что ты согласен и время есть.
Давай. Ближе к следующим выходным. На чем, кстати, написана программа, работающая с базой?
Здравствуйте Alex Ostapenko, вы писали:
AO>Давай. Ближе к следующим выходным. На чем, кстати, написана программа, работающая с базой?
Давай к следующим.
Программа на VC++.
Написана давно, тогда я только DAO знал. Могу и на ADO, для технологии шифрования разницы нет, кода и там и там не много.
Здравствуйте WindJammer, вы писали:
WJ>Здравствуйте Alex Ostapenko, вы писали:
AO>>Давай. Ближе к следующим выходным. На чем, кстати, написана программа, работающая с базой?
WJ>Давай к следующим.
OK.
WJ>Программа на VC++. WJ>Написана давно, тогда я только DAO знал. Могу и на ADO, для технологии шифрования разницы нет, кода и там и там не много.
AO>>>Давай. Ближе к следующим выходным. На чем, кстати, написана программа, работающая с базой? WJ>>Давай к следующим. AO>OK. WJ>>Программа на VC++. WJ>>Написана давно, тогда я только DAO знал. Могу и на ADO, для технологии шифрования разницы нет, кода и там и там не много. AO>Монопенисуально.:) Давай как есть.
Well, well, well...
Это уже интересно :) Как будем проверять достоверность и сроки взлома?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте IT, вы писали:
AO>>>>Давай. Ближе к следующим выходным. На чем, кстати, написана программа, работающая с базой? WJ>>>Давай к следующим. AO>>OK. WJ>>>Программа на VC++. WJ>>>Написана давно, тогда я только DAO знал. Могу и на ADO, для технологии шифрования разницы нет, кода и там и там не много. AO>>Монопенисуально.:) Давай как есть.
IT>Well, well, well... IT>Это уже интересно :) Как будем проверять достоверность и сроки взлома?
Ну, с достоверностью проблем вроде нет. Автор ведь знает, что должно получаться.
Со сроками придется верить мне на слово. :)
IT>>Well, well, well... IT>>Это уже интересно :) Как будем проверять достоверность и сроки взлома?
AO>Ну, с достоверностью проблем вроде нет. Автор ведь знает, что должно получаться. AO>Со сроками придется верить мне на слово. :)
Как выигрыш делить будем?
Если нам не помогут, то мы тоже никого не пощадим.
Все это лажа.
Вот если бы MS SQL Server имел sp_Like..., которую вызывал бы при конструкции Like, передавая параметром строку — а на выходе да/нет !
И вообще — принцип сделай (настрой) сам свой сервер когда-нибудь будет работать ?
Где бы взять перечень sp_..., которыми обрабатывает MS SQL Server запросы, да попереопределять их ...
Здравствуйте IT, вы писали:
КГП>>Где бы взять перечень sp_..., которыми обрабатывает MS SQL Server запросы, да попереопределять их ...
IT>Знамо где... в M$.
Если это про MSDN, то там нет описания sp_... extended.Или хотя бы параметры и смысл (поподробнее чем название).
Здравствуйте Корнилов Григорий Петрович, вы писали:
КГП>Здравствуйте IT, вы писали:
КГП>Все это лажа. КГП>Вот если бы MS SQL Server имел sp_Like..., которую вызывал бы при конструкции Like, передавая параметром строку — а на выходе да/нет !
ТО это был бы уже не SQL Server, а херня какая-то. Минимум, получился бы тормоз.
Если уж так хочется свой like, то напиши свою xp_черте-че с собственной логикой и вызывай ее вместо select'а.
КГП>И вообще — принцип сделай (настрой) сам свой сервер когда-нибудь будет работать ?
Скорее всего никогда. :)
КГП>Где бы взять перечень sp_..., которыми обрабатывает MS SQL Server запросы, да попереопределять их ...
Не думаю, что программисты из MS такие идиоты, чтобы запросы обрабатывать через sp.
Здравствуйте Alex Ostapenko, вы писали:
AO>ТО это был бы уже не SQL Server, а херня какая-то. Минимум, получился бы тормоз.
Грубо и спорно. Нужные sp_ сервер загружает готовой функцией и вызывает ее при необходимости.
Причин для потери времени не вижу.
AO>Если уж так хочется свой like, то напиши свою xp_черте-че с собственной логикой и вызывай ее вместо select'а.
А вот это предложение убого.
AO>Скорее всего никогда. :)
Никогда не говори 'никогда'.
AO>Не думаю, что программисты из MS такие идиоты, чтобы запросы обрабатывать через sp.
Здравствуйте Корнилов Григорий Петрович, вы писали:
AO>>ТО это был бы уже не SQL Server, а херня какая-то. Минимум, получился бы тормоз.
КГП>Грубо и спорно. Нужные sp_ сервер загружает готовой функцией и вызывает ее при необходимости. КГП>Причин для потери времени не вижу.
Грубо — да. Спорить тут вроде бессмысленно.
Причина №1: Откомпилированный алгоритм всегда быстрее скрипта. А sp в машинный код однозначно не компилируется.
Причина №2: Фиксированный алгоритм можно хорошо соптимизировать, чего не сделаешь в предлагаемом варианте.
AO>>Если уж так хочется свой like, то напиши свою xp_черте-че с собственной логикой и вызывай ее вместо select'а.
КГП>А вот это предложение убого.
Может оно и убого, но действенно. Идея ломать всю логику сервера из-за того, что кому-то не понравился встроенный select мне кажется гораздо более убогой.
AO>>Скорее всего никогда. :)
КГП>Никогда не говори 'никогда'.
:) Я не оптимист.
AO>>Не думаю, что программисты из MS такие идиоты, чтобы запросы обрабатывать через sp.
КГП>Не 'чтобы'. а 'что'.
Здравствуйте Alex Ostapenko, вы писали:
AO>Причина №1: Откомпилированный алгоритм всегда быстрее скрипта. А sp в машинный код однозначно не компилируется.
А MS SQL Server расширенные sp_ разве использует по другому? К тому же он кеширует sp_
AO>Может оно и убого, но действенно. Идея ломать всю логику сервера из-за того, что кому-то не понравился встроенный select мне кажется гораздо более убогой.
Нет, не ломать логику — а настраивать логику
AO>К чему это?
Здравствуйте Корнилов Григорий Петрович, вы писали:
AO>>Причина №1: Откомпилированный алгоритм всегда быстрее скрипта. А sp в машинный код однозначно не компилируется.
КГП>А MS SQL Server расширенные sp_ разве использует по другому? К тому же он кеширует sp_
Как "по другому"? Он их переводит в некое внутреннее представление, но никак не в машинный код. А что толку с этого кеширования? Ну не нужно лишний раз строить execution plan, и все.
AO>>Может оно и убого, но действенно. Идея ломать всю логику сервера из-за того, что кому-то не понравился встроенный select мне кажется гораздо более убогой.
КГП>Нет, не ломать логику — а настраивать логику
Это смотря с какой стороны смотреть.
AO>>К чему это?
КГП>К дождю ...
Да, от дождичка я бы не отказался. Жара уже порядком достала. :)
TL>Так что там насчет взлома? Получилось или нет? :) Мне с профессиональной точки зрения интересно...
Да, да, да... Просим, просим...
;o)
Если нам не помогут, то мы тоже никого не пощадим.
Re[22]: Шифрование баз данных
От:
Аноним
Дата:
19.07.01 05:40
Оценка:
Здравствуйте IT, вы писали:
TL>>Так что там насчет взлома? Получилось или нет? :) Мне с профессиональной точки зрения интересно...
IT>Да, да, да... Просим, просим... IT>o)
Обойдётеся — у нас интернет отрубили (БелИнфоСофт)
Здравствуйте Аноним, вы писали:
А>Здравствуйте IT, вы писали:
TL>>>Так что там насчет взлома? Получилось или нет? :) Мне с профессиональной точки зрения интересно...
IT>>Да, да, да... Просим, просим... IT>>o)
Да мы вроде как договаривались начать в конце этой недели, но теперь видимо и это не получится. :)
А>Обойдётеся — у нас интернет отрубили (БелИнфоСофт)
Ну и ладно, у меня похоже выходные все равну будут заняты. :)
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
Здравствуйте 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 захочет потренироваться?
Честно говоря, мне эта "тренировка" нафиг не нужна. Я на это пошел, чтобы не показаться голословным. :)
А где программа просмотра? Голая база мне нафиг не нужна.
WJ>/* WJ>Жаль, что rsdn.ru так и не нашел места для БД. WJ>Может у них тоже инет отвалился? WJ>*/
Такую базу я могу и у себя выложить, если хочешь.
AO>>Честно говоря, мне эта "тренировка" нафиг не нужна. Я на это пошел, чтобы не показаться голословным. :)
WJ>Тут ни чем помочь не могу. Не надо было встревать с комментариями.
А я помощи у тебя и не прошу. Я всего лишь констатирую факт.:)
Здравствуйте WindJammer, вы писали:
WJ>Здравствуйте Alex Ostapenko, вы писали:
AO>>А где программа просмотра? Голая база мне нафиг не нужна. WJ>/* это было прогнозируемо */ WJ>Выслал.
Посмотрел я на это чудо. Вот наш ответ Чемберлену: :)
1) Складывается четкая картина того, что инспользован шифр многоалфавитной замены с периодом равным длине пароля. На такой базе, если пароль не слишком короткий, его хрен вскроешь, т.к. данных для набора нужной статистики маловато. На паре тысячей записей взлом уже вполне реален.
2) Что-то я в упор не наблюдаю работающего контекстного поиска. :) Я в общем-то догадываюсь, как ты его собирался делать — что в стиле LIKE enc_str(pass,pattern) OR LIKE '%+enc_str(shift(pass),pattern)+%' OR... (число OR'ов равно длине пароля). Но это, ИМХО, полнейший изврат. Для приличной по размеру базы это очень неслабо увеличивает расходы на выборку, да еще и фильтровать результаты самому еще раз придется.
В общем, как защита от дурака для баз малого размера оно вполне годится, но не более.
Здравствуйте 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>В общем, как защита от дурака для баз малого размера оно вполне годится, но не более.
Ну, зачем же так самокритично. Ну, подлый я, дал маленькую БД, зачем же так убиваться, по этому поводу. :)
Здравствуйте 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>Ну, зачем же так самокритично. Ну, подлый я, дал маленькую БД, зачем же так убиваться, по этому поводу. :)
Я бы на твоем месте поплакал и пошел бы переквалифицироваться в управдомы. Разработчик систем защиты из тебя похоже вообще никакой.
Здравствуйте IT, вы писали:
AO>>Я бы на твоем месте поплакал и пошел бы переквалифицироваться в управдомы. Разработчик систем защиты из тебя похоже вообще никакой.
IT>Alex, плиз, соблюдаем корректность.
OK. Прошу прощения, не сдержался.
Я со своей стороны топик закрываю. WildJammer, если у тебя есть желание еще поспорить, переходи в мыло.
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>Я бы на твоем месте поплакал и пошел бы переквалифицироваться в управдомы. Разработчик систем защиты из тебя похоже вообще никакой.
Ты же сам написал: "...как защита от дурака для баз малого размера оно вполне годится...", базу я тебе послал малого размера, ты ее не сломал, защита устояла, отсюда и следующий вывод...
AO>Я со своей стороны топик закрываю. WildJammer, если у тебя есть желание еще поспорить, переходи в мыло.
Что и требовалось доказать.
Если вам не противостоят серьезные организации и ваш продукт, который вы защищаете, не имеет широкого распространения, то даже самых примитивных мер будет достаточно, чтобы защититься. Теоретиков много, а вот практиков нет.
Здравствуйте The Lex, вы писали:
TL>Досадно, конечно, что все свелось к банальной перебранке между разработчиками...
Во-первых, я бы не сказал: "все свелось", я бы сказал, что все началось с понтоватой оценки одним качеств другого, в то время как давать ее (оценку) никто не просил.
Во-вторых, _перебранки_ настолько обыденны, что к ним давно пора привыкнуть и "фильтровать" их при чтении форумов, IMHO.
А главное, во всем этом обсуждении/базаре/перебранке я лично вижу вполне конкретный результат — предложена элементарнейшая технология шифрования, которая хотя и имеет ряд серьезных ограничений и недостатков, связанных масштабируемостью, показала хороший коэффициент <сложность взлома>/<стоимость реализации>.
Здравствуйте WindJammer, вы писали:
WJ>Здравствуйте The Lex, вы писали:
WJ>Во-вторых, _перебранки_ настолько обыденны, что к ним давно пора привыкнуть и "фильтровать" их при чтении форумов, IMHO.
Оно то конечно так, но от того не менее обидно... :)
WJ>А главное, во всем этом обсуждении/базаре/перебранке я лично вижу вполне конкретный результат — предложена элементарнейшая технология шифрования, которая хотя и имеет ряд серьезных ограничений и недостатков, связанных масштабируемостью, показала хороший коэффициент <сложность взлома>/<стоимость реализации>.
Хм... Увы, я этой технологии не увидел. Скорее всего, я недостаточно хорошо внимательно "фильтровал"... :)
Здравствуйте The Lex, вы писали:
WJ>>А главное, во всем этом обсуждении/базаре/перебранке я лично вижу вполне конкретный результат — предложена элементарнейшая технология шифрования, которая хотя и имеет ряд серьезных ограничений и недостатков, связанных масштабируемостью, показала хороший коэффициент <сложность взлома>/<стоимость реализации>.
TL>Хм... Увы, я этой технологии не увидел. Скорее всего, я недостаточно хорошо внимательно "фильтровал"... :)
:)
Я не писал, что показал технологию, я писал, что предложил, а до вас никто желание увидеть ее не излагал...
Ниже класс, который выполняет шифрование.
// Crypto.h: interface for the CCrypto class.
//
//////////////////////////////////////////////////////////////////////
Здравствуйте WindJammer, вы писали:
WJ>Ниже класс, который выполняет шифрование.
<skip>
Мда, тут я все же не сдержусь. :)
Ты про такие вещи как static или функция strchr когда-нибудь слышал? :)
Я бы постеснялся вставлять такой дубовый код в коммерческий продукт и выставлять его напоказ.
Здравствуйте Alex Ostapenko, вы писали:
AO>Мда, тут я все же не сдержусь. :)
А надо было. А то опять вспомнят про твои порывы расшифровать БД на раз-два... Ты сам забыл, что ли?
AO>Ты про такие вещи как static или функция strchr когда-нибудь слышал? :) AO>Я бы постеснялся вставлять такой дубовый код в коммерческий продукт и выставлять его напоказ.
А это говорит о том, что ты относишься именно к той большой категории теоретиков умников.
Здравствуйте Alex Ostapenko, вы писали:
AO>Ты про такие вещи как static или функция strchr когда-нибудь слышал? :) AO>Я бы постеснялся вставлять такой дубовый код в коммерческий продукт и выставлять его напоказ.
Что-то я погорячился в прошлом постинге и забыл о главном.
Перепиши код с помощь любых функций и попробуй доказать, что код стал хотя бы на процентов на 10 быстрей, когда докажешь, я задам тебе вопрос, почему ты не пишешь на ассемблере, это же даст еще более эффективный код. Хотя я и уверен, что это ты сделать не в состоянии.
Я уже тебе намекал на то, что не плохо бы в диалоге, при оценки кода, технологий и т.д., использовать более иные термины, чем «изврат», «дубовый»... Причем, желательно, что бы оценка была критериальной, а не так, как у тебя получалось до этого.
Так что, ждем с нетерпением твоих выкладок, объясняющих твое понимание слова «дубовый».
Да, и еще. Если решишься показать преимущество применения других функций в представленом алгоритме, сначала потренируйся дома, проценты посчитай, а только потом говори, что готов доказать, а то лажанешься, как прошлый раз с расшифровкой.
Здравствуйте WindJammer, вы писали:
WJ>Ниже класс, который выполняет шифрование.
WJ>// Crypto.h: interface for the CCrypto class. WJ>// WJ>// И еще много разного кода...
Уважаемый господин WindJammer. Надеюсь Вы понимаете, что подобного кода можно написать неисчислимое количество вариантов. Суть от этого особо не изменится. Как и его ценность.
Меня же интересует не технология шифрования некоторых массивов данных, например, строк, а технология применения Вашего великолепного класса в самой базе данных. Каким образом Вы производите подключение всего этого к файлу *.mdb? Каким образом происходит работа клиента с базой данных? Возможна ли работа с базой данных посредством самого Access? Вот какие соображения было бы в высшей степени занимательно от Вас услышать...
Здравствуйте 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'а вставил в прогу.:)