Здравствуйте 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>Ну, зачем же так самокритично. Ну, подлый я, дал маленькую БД, зачем же так убиваться, по этому поводу. :)

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