Здравствуйте 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'а вставил в прогу.:)
Здравствуйте The Lex, вы писали:
TL>Надеюсь Вы понимаете, что подобного кода можно написать неисчислимое количество вариантов. Суть от этого особо не изменится. Как и его ценность.
Да.
TL>Меня же интересует не технология шифрования некоторых массивов данных, например, строк, а технология применения Вашего великолепного класса в самой базе данных.
Перед записью шифровать, после чтения расшифровывать, перед передачей подстроки поиска ее преобразовывать. TL>Каким образом Вы производите подключение всего этого к файлу *.mdb?
Чего всего к mdb? TL>Каким образом происходит работа клиента с базой данных?
Через ADO, например. TL>Возможна ли работа с базой данных посредством самого Access?
Нет
E-yes, достаточно точно описал проблему. Он написал, что нельзя шифровать строки самостоятельно, поскольку используется контекстный поиск. Я предложил шифровать строки самостоятельно, а при контекстном поиске подставлять предварительно преобразованный запрос.
Все дальнейше обсуждение возникло только благодаря пытливому уму Алекса. С целью показать, что практика отличается от теории, что за несколько часов можно добавить в приложение функции шифрования, взлом которых... (повторяться не буду). Я ни разу не сказал, что это мое ной-хау, я почеркивал, что это элементарнейшая технология. /* это комментарии к вашей ирони */