Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 7 8 9 10 11 [12] 13 14 15 16 .. 99   вперед  Ctrl
 Re: Разработал драйвер баз данных, что дальше???  [new]
JErik
Member [заблокирован]

Откуда:
Сообщений: 468
ADx,
Вы можете посмотреть результаты последнего теста: "Взял тарификационные данные для теста... более 300.000 звонков Биллайн"...
Кроме того если вам надо сохранить данные в чистом виде то для этого есть функция: TXTWriteMas_u - сохранит в текстовый файл с любым разделителем - хоть CSV хоть текст с табуляцией т.д... с минимальными задержками, без шифрования сжатия и других прибамбасов - более того библиотеке не так важно данные из каких источников обрабатывать и в каком формате они хранятся... Программа Сервер: VxTJ7 - умеет конвертировать данные через ADO - то есть из любых источников БД в TJ7,TJ2 или обычный TXT/CSV... Задавая параметры можно налету изменять фильтровать/сортировать данные - перез сохранением - тоесть автоматом получать отчёты или синхронизировать БД!!!
8 ноя 09, 10:35    [7897828]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
Sergey Orlov
Member

Откуда: СПб
Сообщений: 4506
JErik,
Прочитал я весь топик и решил высказать несколько замечаний,
1. Ох уж эти программисты, поставят себе Intel extreme, гиг 8 озу, 64-битную операционку, а потом удивляются, чего пользователи говорят, что все медленно работает, у меня к примеру все летает....
Поэтому все ваши тесты от лукавого, особенно то, что вы предлагаете на сжатие/расжатие данных при передаче их каналу сервер-клиент, это очень хорошо при одновременном выполнение 4-х условий:
а. Большой обьем данных
б. слабая пропускная способность канала, имеется в виду и скорость и помехи
в. проц на клиенте
г. проц на сервере
Стоит вылететь одному из условий и вы в пролете...
Не совсем понимаю и тесты на сортировку, даже в FOXPRO правильно построенные индексы существенно изменяют сортировку, ну а создание базы...
2. Хотите продвинуть свой проект, посмотрите на него сторонним взглядом, вычлените главное и вперед в opensourse под соответствующей лицензией, а ваши алгоритмы шифрования за отдельную плату, другими словами повторить путь mysql...
8 ноя 09, 17:31    [7898329]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
gR4mm
Member

Откуда: Москва
Сообщений: 1412
А зачем фильтровать и сортировать данные перед сохранением?
8 ноя 09, 18:48    [7898474]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
mayton
Member

Откуда: loopback
Сообщений: 52919
JErik
TJ7-1.5.1.1E-open\Программы\TJ7Reader2\TJ7Reader.exe

Посмотрел я зависимости библиотек и пришёл к следующему сценарию возможного взлома.

1) Необходимо дизассемблировать сборку PR9X.dll. Насколько я понимаю это интерфейс твоего криптопровайдера.

PR9XInfo2 
PR9XInfo 
PR9XVer 
ZifrCheck_u 
Zifr_u 
ProtectionSTRCheck_u 
ProtectionSTR_u 
NShifrPR2_u
ShifrPR2_u 
NShifrPR1P_u 
ShifrPR1P_u 
NShifrPR1_u 
ShifrPR1_u 
NShifr_u 
Shifr_u 
Gpsch_u 

И узнать, для начала, использует-ли она Microsoft Crypto API. По зависимостям я только могу видеть, что она использует oleaut32.dll, user32.dll, kernel32.dll, advapi32.dll. Последняя включает в себя ф-ции безопасности, но не факт что ты их использовал, целиком и правильно.

2) Если ты использовал самопальные функции для генерации ключей и блочного шифрования, то тогда сценарий видоизменяется. Из сложного криптоанализа он превращается в реверс-инженеринг того что ты сотворил и не очень сложный криптоанализ. Узнаём алгоритм и сравниваем его с идеальным блочным шифром. Фактически задача будет сводится к тому, чтобы узнать, насколько х.ёвый плохой твой метод по сравнению со стандартным методами, которые включены в advapi32.dll и crypt32.dll, и по сравннеию с идеальным блочным шифром. Задача криптоанализа остаётся в силе - но она упрощается. Самопальные крипто-алгоритмы на проверку всегда оказываются хуже стандартных (если автор конечно не гениальный математик).

3) Далее снова возможны варианты - нужно искать слабое звено. Либо блочный шифр, либо метод генерации ключа. С ключом всё ясно. Используем dictionary. Успехом будет взлом 1 блока шифротекста, (или нескольких). В нашем случае это шапка файла tj7 (только та часть, которая подвержена шифрованию). Критерий успешности должна выдать функция-валидатор, которую мы напишем для определения корректности. Её принцип должен быть основан на стат. показателях самих шифруемых данных. Например, если внутри данные лежат в сжатом виде, то мы, несомненно будем иметь некий хедер типа словаря и т.п. Еще лучше, если в заголовке есть контрольная сумма. Если из пункта (2) мы получили доп-информацию об особенностях кустарного блочного шифра (кривая гистограмма, слабый алгоритм генерации СЧ, плохой метод транформации пароля и т.п.) то эта информация также может быть использована для нахождения ключа. Таже мы можем свободно использовать метод "Избранного открытого текста" т.к у нас есть на руках функции.

Если ты всё-таки использовал Microsoft Crypto API, то сценарий усложняется многократно.

P.S. Данная информация общедоступна в литературе и предоставляется мной для ознакомления и не может быть использована для нанесения кому-либо вреда. Если вам ПОКАЗАЛОСЬ, что я нарушил правила форума - то знайте - вам просто показалось.
8 ноя 09, 18:52    [7898481]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
JErik
Member [заблокирован]

Откуда:
Сообщений: 468
mayton,
Выже лучше меня понимаете - что всё приведённое вами - это лишь теория, а на практике взломать шапку TJ7 - невозможно!!! Вам всё равно понадобится знание пароля - чтобы вы не взламывали, каких-бы локальных успехов вы не добивались - вы ничего не добъётесь и каждый раз будете возвращаться к одному и тому-же: ЗНАНИЮ ПАРОЛЯ!!!
Красиво написать - это не значит оойти защиту, скажите-ка мне что сохранено в файлике: tex-doc.tj7 - который я выкладывал выше?
9 ноя 09, 04:14    [7899447]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
Сахават Юсифов
Member

Откуда: Орел
Сообщений: 3992
JErik,

давай тыщ 50 зеленых, я сломаю
9 ноя 09, 04:41    [7899450]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
JErik
Member [заблокирован]

Откуда:
Сообщений: 468
Сахават Юсифов
JErik,
давай тыщ 50 зеленых, я сломаю

То во сколько вы оценили стойкость алгоритмов - очень похвально, но я думаю вы всё-же недооцениваете её!!!
9 ноя 09, 05:04    [7899454]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
gR4mm
Member

Откуда: Москва
Сообщений: 1412
JErik
mayton,
Выже лучше меня понимаете - что всё приведённое вами - это лишь теория, а на практике взломать шапку TJ7 - невозможно!!!

Товарищ, во-первых, нет ничего не возможного.
Во-вторых вы слишком переоцениваете свои силы
В-третьих, это только вопрос времени
9 ноя 09, 06:48    [7899488]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
JErik
Member [заблокирован]

Откуда:
Сообщений: 468
gR4mm
JErik
mayton,
Выже лучше меня понимаете - что всё приведённое вами - это лишь теория, а на практике взломать шапку TJ7 - невозможно!!!

Товарищ, во-первых, нет ничего не возможного.
Во-вторых вы слишком переоцениваете свои силы
В-третьих, это только вопрос времени

У вас нет ни одной причины так утверждать... Тем более чейчас когда найдены уязвимости в SSL и TLS - становится очевидно, что использование TJ7 - более безопасно, неже ли ваши хвалёные - сертифицированные протоколы...
Я не переоцениваю свои силы - я точно знаю с чем имею дело...
Время в данном случае - лишь закаливает алгоритмы, подтверждая их стойкость...
9 ноя 09, 07:12    [7899498]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
Анонимус
Guest
Блин, неужели кому-нибудь IDA сложно в руки взять и не лить из пустого в порожнее?

Убер алгоритмы из PR9X.dll:

Gpsch_u - это я так понял и есть генератор случайных числел. И мы там видим: f(a,b) = (9a+7) mod b. Линейный конгруэнтный метод, первое же что по ссылке написано: "...применяется в простых случаях и не обладает криптографической стойкостью...".

Shifr_u - убер шифрование, две строки на входе и что-то вроде ключа на выходе:
1) Строки посимвольно суммируются по длинне первой строки + при каждой итерации соответствующий символ второй строки заменяется на число с соответствующим индексом из A = {x = gpch(x, 256), x = 0..255}.
2) Все символы второй строки суммируются, к ним добавляется занчение какой-то линейной функции от длинны этой строки.
3) От предыдущей суммы берется два раза (видимо для надежности) gpch(x, 256(255 во втором случае)), значения обоих вызовов складываются.
4) Суммированые значения посимвольно добавляются к первой строке.
5) Суммированая строка как-то конвертируется в определенный формат кратный 8 байтам при помощи комманд fpu, думаю это delphi загонятся, сам автор такого бы не написал. Финиш.

NShifr_u - по-моему тоже самое что и Shifr_u, только суммирование везде на разность заменено.

Остальные *Shifr* - особо ни вникал, по-моему просто обертки для Shifr/NShifr вызывающие их по нескольку раз и ничего принципиально интересного не делающие.

Точка входа из tj7reader.exe в убер-шифрование находится в TJ7ReadMas[fvmass.dll], передается сам пароль и какой-то константный фарш длинной FD байт, созданием которого процедура по большей части и занимается, как она его делает разбираться за бесплатно просто лень.

PS: Стоит отметить хорошее знание дискретной математики(или на чем там еще основаны его алгоритмы...), в особенности символики. Если кто заметил, то линейный конгруэнтный метод - функция высших порядков и для генерации последовательности псевдослучайных чисел рекурсивно вызывает сама себя же в качестве аргумента, чего я, по-моему, так нигде и не увидел.
9 ноя 09, 08:11    [7899530]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
JErik

вот видите - оракл шифрованием передачи данных не занимается о какой вообще безопасности здесь можно говорить???


Еще раз по буквам для особо глухих: OAS
Oracle "шифрованием передачи данных" занимается

Но суть разумеется не в этом
9 ноя 09, 08:21    [7899542]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
JErik
mayton,
Выже лучше меня понимаете - что всё приведённое вами - это лишь теория, а на практике взломать шапку TJ7 - невозможно!!!


Не путай гамму и ключ. Ты генеришь гамму из ключа своим ГПСЧ, но кто сказал, что ее так уж невозможно предсказать ???

"Невозможно" взломать было бы, если бы размер КЛЮЧА был не меньше размера шифруемого текста, но это автоматически ведет к проблемам в управлении ключами и может быть использовано только в исключительно специальных случаях.

P.S. Сдается мне бисер все это
9 ноя 09, 09:01    [7899607]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
JErik
Сахават Юсифов
JErik,
давай тыщ 50 зеленых, я сломаю

То во сколько вы оценили стойкость алгоритмов - очень похвально, но я думаю вы всё-же недооцениваете её!!!


проверим? гони бабло
9 ноя 09, 09:03    [7899610]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
JErik

Время в данном случае - лишь закаливает алгоритмы, подтверждая их стойкость...


Ага. Расскажи это DES-у и "Упаковке Рюкзака"
9 ноя 09, 09:04    [7899617]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
mayton
Member

Откуда: loopback
Сообщений: 52919
JErik
Красиво написать - это не значит оойти защиту, скажите-ка мне что сохранено в файлике: tex-doc.tj7 - который я выкладывал выше?

Сколько тебе лет?
Модератор: если уж так хочется выяснить какие-то личные данные, то как-минимум для приличия надо бы написать что-то о себе


Сообщение было отредактировано: 9 ноя 09, 10:18
9 ноя 09, 09:32    [7899695]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
JErik
Member [заблокирован]

Откуда:
Сообщений: 468
Анонимус,
Улёт - В яблочко алгоритм псевдо-случайных чисел - именно такой, НО здесь надёжнее и не требуется и это не алгоритм случайных чисел...
Что касается функций Shifr - то это функции блочного шифрования, принцип шифрования просто: на вход строка и пароль на выходе: шифрованная строка!!! НО максимальная длинна строки 255 символов и максимальная длинна пароля 255 символов и период повторения генератора случайных сисел 256 символов - то есть на данном алгоритме при любом входе - обеспечивается полное отсутствие периода повторения ключа...
Как идёт шифрование неважно - ошибётесь при расшифровке хотя-бы на один битик в любом месте ключа - вСЁ - вам вернётся полная каша...
что касается функций которые ShifrPR* - это функции основанные на базовой: Shifr - но у них другое назначение - это функционал повышенной безопасности с рандомизацией и фиксированной длинной...
PR1 - блоки используются для аутентификации: преобразования входа в выход, хотя по сути расшифровывают зашифрованные данные - но так как это рандомизированный блок фиксированной длинны - эти данные надо ещё найти :)...
PR1P - является чуток модифицированным блоком проверки пароля и возвращает Истину или ложьь. Суть блока в том что он ничего незнает о самом пароле и данные о позиции как и в PR1 - шифрованы - поэтому по введёному вами паролу - он предполагает - что внутри зашифрована строка такой-же длинны (он незнаети проверить неможет - ему приходится верить что введёный пароль верен) НО если он неверен - вернётся чушь конечно как и всегда.
PR2 - это вообще убойная вещь - позволяет не только получить заранее зашифрованные данные, НО и проверяет правильно ли введён пароль. Алгоритм вероятностный - о пароле он ничего не знает и более того не содержит не хеша ни длин ничего - проверяет правильность по чисто субьективным признакам декодирования а именно по тому что зашифровано. Если кратко то PR2 - это 2-ва PR1 блока, когда навход поступает зашифровать строку 1111 с паролем 2222... он шифрует её дважды PR1 методом и в будущем когда вам надо раскодировать её - он раскодирует так-же 2 PR1 блока и сравнивает результат если результат обоих декодирований одинаков - то возвращается строка - иначе: пароль введён неверно!!! К сожалению так как всё рандомизирвоано то при подборе часто вываливается одинаковый результат расшифровки - однако вероятность такого события не так велика чтобы недоверять данному результату и пользователю результат можно сообщать с уверенностью - только при попытке перебора пароля - лавинообразно хлынут ложные результаты... PR2 - является основой защиты TJ7 - кроме того внутренняяшифрованная информация случайной длинны из случайных символов - является Паролем для следующего PR1 блока с параметрами БД такими как размерность, кол-вео строк/столбцов - затем код опять меняется иему назначается специальный алгоритм изменнеия - то есть он более нигде не используется в явном виде а каждая ячейка зашифрована своим уникальным кодом - преобразованным из случайного кода случайной длинны... TJ7 - это предел безопасности - лучшей защиты вы больше нигде никогда не увидите (я имею ввиду аналогичные продукты криптографии - многих других производителей)... PR2 - это алгоритм с полным циклом расшифровки как и все PR - вы никогда не сделаете программу которая могла бы быстрее проверять пароль - так как в любом случае требуется полный цикл расшифровки...JErik
9 ноя 09, 10:30    [7900048]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
JErik
Member [заблокирован]

Откуда:
Сообщений: 468
Кстате, дополню про вышесказанное про PR2 - алгоритм содержит не просто 2-ва PR1 - а это его принцип - вся избыточная информация - которая могла бы быть при 2-х PR1 - удалена - чтобы не дублироваться поэтому на оба блока единые шифрованные указатели позиций и длин - поэтому после расшифровки 1-го уровня - ничего не ясно - у вас случайны данные- и что-то начнёт проясняться только ещё через применение нескольких функций декодирования... Поэтому алгоритм можно считать с полным циклом обработки без возможности быстрого подбора- кроме того что уже создано автором...
9 ноя 09, 10:36    [7900085]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
JErik
Member [заблокирован]

Откуда:
Сообщений: 468
Отдельно можно сказать про алгоритмы обеспечения целостности данных - они не CRC - стандартные как вы привыкли выдеть - они тоже разработаны лично мной. и за проверку целостности тоже отвечает PR9X. Реализация цикличная, что печально - честно скажу - каюсь, суть нахождения суммы проста:
все символы считаются по их кодам - при этмо каждый следующий символ суммируется со смещением, ну например вычислим контрольную сумму 3-х байт: №30№77№42
Сумма=30+770+4200...
То есть каждый байт считается со смещением в 10-ть раз... придумывал сам, в основном для того чтобы повреждения были явно видны - если вы один символ уменьшите на 1 а второй увеличите - то увы - контрольная сумма не сойдётся, восстановлением данных она не занимается - так как это в любом случае вероятностная затея - она лишь контрольрует целостность и указывает когда данные поврежлены и их нельзя использовать...
9 ноя 09, 10:55    [7900220]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
Зайцев Фёдор
Member

Откуда: Лужки
Сообщений: 5308
JErik
алгоритм псевдо-случайных чисел - именно такой,
JErik
это не алгоритм случайных чисел...
в смысле?
9 ноя 09, 11:17    [7900328]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
Игорь Котов
Guest
JErik, вы упорно не понимаете, что для дешифровки можно даже не знать ваш алгоритм, это несколько осложняет задачу, но не делает ее невозможной. Весь вопрос только стоит в ее эффективности, то есть количестве потребных вычислительных ресурсов.

Если у вас действительно хороший алгоритм он будет на уровне лучших известных, но сильно сомневаюсь в этом.

Про уязвимости в TSL и SSL вы внимательно читали в чем именно эти уязвимости? Подсказка: криптоалгоритм там совершенно не при чем, уязвимость скорее не в TSL, а в связке http(s) + ssl.
9 ноя 09, 11:29    [7900398]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
JErik
Member [заблокирован]

Откуда:
Сообщений: 468
Зайцев Фёдор
JErik
алгоритм псевдо-случайных чисел - именно такой,
JErik
это не алгоритм случайных чисел...
в смысле?
Смысл алгоритма псевдо-случайных чисел в его воспроизведении, то есть если я ему на вход подаю одну букву - он возвращает мне другую, псевдо-случайную - то есть если я 2-3-4 раза на вход одному и тому же алгоритму подам одну и туже букву - то результат будет один и тот-же, за исключением как выше писали - вложенных запросов.
http://ru.wikipedia.org/wiki/Генератор_псевдослучайных_чисел
То есть я от введёного пароля могу с заданным распределением получить другой связанный с ним алгоритмом преобразования - то что я получу нельзя считать случайной последовательностью так как она получина из из определённой последовательности и хоть и выглядит непредсказуемо - при желании я могу повторить подобные преобразования, то есть в случае если бы новая последовательность была случайна и никак не связана с первоочередной - я бы никогда больше не смог её повторить мне бы пришлось сохранять где-то эти данные чтобы потом их применить для раскодирования, а так я использую псевдо-случайную последовательность...
9 ноя 09, 11:32    [7900412]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
Игорь Котов
Guest
Gluk (Kazan)
JErik

Время в данном случае - лишь закаливает алгоритмы, подтверждая их стойкость...


Ага. Расскажи это DES-у и "Упаковке Рюкзака"


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

Просто вычислительные возможности даже домашних компов настолько фантастически выросли, по сравнению с 1977 годом, что стало возможным легко его ломать "в лоб", особенно с помощью такого метода как создания предварительно вычисленных Orphan Tables.
9 ноя 09, 11:38    [7900448]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
JErik
Member [заблокирован]

Откуда:
Сообщений: 468
Игорь Котов
JErik, вы упорно не понимаете, что для дешифровки можно даже не знать ваш алгоритм, это несколько осложняет задачу, но не делает ее невозможной. Весь вопрос только стоит в ее эффективности, то есть количестве потребных вычислительных ресурсов.

Если у вас действительно хороший алгоритм он будет на уровне лучших известных, но сильно сомневаюсь в этом.

Про уязвимости в TSL и SSL вы внимательно читали в чем именно эти уязвимости? Подсказка: криптоалгоритм там совершенно не при чем, уязвимость скорее не в TSL, а в связке http(s) + ssl.
Связка-не связка - а проблема аутентификации - это на мой взгляд непростительная ошибка...
В этом то и суть - что алгоритма знаете вы или не знаете - разницы нету, для вас пез пароля - это всё равно тайна за семью печатями, основная причина - банальна - пароль - это то связующее звено которое позволяет восстановить информацию.
Что касается вычислительных мощностей, то это вопрос вобще нереальный, таких вычислительных мощностей просто несуществует и в ближайшие 100 лет точно не будет существовать... Длина пароля от 1 до 255 символов, при этом состав символов - вообще любой с кодом от №0 до №255 - при всём вашем энтузиазме - ни один из существующих алгоритмов не обладает такими длинами ключей, это вам не 64/128 или 256 битный ключ.... Более того - на мой взгляд это даже мало похоже на шифрованный текст - это скорее последовательность ничем не связанных байт - пока нет ключа и алгоритма. что касается шифрование БД с надёжным паролем - то эта проблема давно решена - на сервере БД лежит со случайным паролем случайной длинны, в таком-же виде идёт вся передача информации по чети - а пользователи для доступа используют свои короткие пароли проходя аутентификацию стандартная аутентификация реализована на уровне PR1-блоков!!!при всём вашем желании вы взломав сервер или перехватив трафик или просто как-то заполучив базу - никогда её не откроете... что касается технологий обеспечения безопасности клиентских машин - то это отдельный разговор - и здесь средства безопасности более гибкие и позволяют администратору даже запрещать экспорт - в то время как к стандартным БД с именем и паролем я могу даже Экселем подцепиться и всё сохранить...
9 ноя 09, 11:43    [7900476]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
Денис Ильин
Member

Откуда: Железнодорожный
Сообщений: 242
псевдостучайная последовательность плоха тем, что зная алгоритм её воспроизведения это сделать сможет каждый.. обычно это одно из слабых мест шифрователей - вместо всего множества возможных ключей (ну, скажем, 128 битный ключ) на самом деле генерируется только миллион/миллиард или т.п.. А миллион ключей перебрать - это по нынешним временам тфу.
9 ноя 09, 11:52    [7900544]     Ответить | Цитировать Сообщить модератору
 Re: Разработал драйвер баз данных, что дальше???  [new]
mayton
Member

Откуда: loopback
Сообщений: 52919
Игорь Котов
Просто вычислительные возможности даже домашних компов настолько фантастически выросли, по сравнению с 1977 годом, что стало возможным легко его ломать "в лоб", особенно с помощью такого метода как создания предварительно вычисленных Orphan Tables.

Да. Всё верно. DES проектировался в те времена, когда вычислительные мощности железок были невелики и не было никаких прогнозов (типа закона Мура) на их рост. И разрядность 2х32 бит на раунд была взята исходя из текущих аппаратных особенностей. Сегодня, рост Интернета и всяких там grid вычислений позволил взять баръер по успешной атаке, но это редкий исключительный случай, который довольно трудно повторить. Кстати, DES имеет уязвимость в виде нулевого ключа и прочих специальных ключей-констант которые нежелательно использовать.

И сегодня все криптографические прогнозы по атаке основаны на предположениях типа: "в ближайшие 50 лет при сохранении текущено темпа роста мегафлопов этот алгоритм будет принципиально невзламываем". Остаётся только правильно выбрать разрядность ключа (128,256,512 бит) с одной стороны чтобы не ушатать шифрованные сокеты сервера нагрузкой на CPU и, с другой стороны, чтобы сохранить приемлемую стойкость.
9 ноя 09, 12:00    [7900602]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 7 8 9 10 11 [12] 13 14 15 16 .. 99   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить