У какого есть ккие соображения по поводу: Приложение-клиент получает файл от сервера и хранит его в TMemoryStream, что меня более чем устраивает. Теперь задача: сделать так, чтобы не было практически никаких возможностей спереть эту инфу из памяти куда-нить. На диск оно, естественнно, не записывается. Но, если я правильно понимаю, при достаточной степени мастерства и наличии хороших инструментов, утащить это дело из памяти будет несложно. Да, кстати, сожержимое файла — текст.
Здравствуйте, _Student_, Вы писали:
_S_>Теперь задача: сделать так, чтобы не было практически никаких возможностей спереть эту инфу из памяти куда-нить.
Здравствуйте, kavlad, Вы писали:
K>Здравствуйте, _Student_, Вы писали:
_S_>>Теперь задача: сделать так, чтобы не было практически никаких возможностей спереть эту инфу из памяти куда-нить.
K>Шифровать?
Боюсь, это не лучший выход из положения. Дело в том, что с этими данными производится постоянная выборка, сравнение и т.д. Типа, юзер ввел че-то, а я сравниваю с тем, что в файле. т.е. дешифровать все-равно придется...
Привет, _Student_!
Вы пишешь 05 мая 2005:
K>> Шифровать?
S> Боюсь, это не лучший выход из положения. Дело в том, что с этими данными производится постоянная выборка, сравнение и т.д. Типа, S> юзер ввел че-то, а я сравниваю с тем, что в файле. т.е. дешифровать все-равно придется...
Не обязательно дешифровать.
Можно рядышком с зашифрованными данными хранить хеш.
И сравнивать хеш в файле с тем, который получен по новым данным.
Здравствуйте, Alex.Che, Вы писали:
AC>Привет, _Student_! AC>Вы пишешь 05 мая 2005:
K>>> Шифровать?
S>> Боюсь, это не лучший выход из положения. Дело в том, что с этими данными производится постоянная выборка, сравнение и т.д. Типа, S>> юзер ввел че-то, а я сравниваю с тем, что в файле. т.е. дешифровать все-равно придется...
AC>Не обязательно дешифровать. AC>Можно рядышком с зашифрованными данными хранить хеш. AC>И сравнивать хеш в файле с тем, который получен по новым данным.
AC>-- AC>With best regards, Alex Cherednichenko.
Честно говоря, я не очень дружу с алгоритмами шифрования. Но если правильно понял, для одних и тех же данных шифрованный код будет одинаковым? или как? что такое хеш? Буду благодарен за пояснения.
Здравствуйте, _Student_, Вы писали:
_S_>Честно говоря, я не очень дружу с алгоритмами шифрования. Но если правильно понял, для одних и тех же данных шифрованный код будет одинаковым? или как? что такое хеш? Буду благодарен за пояснения.
Грубо говоря — хешь это результат шифрования
На твою строку применяется функция хеширования — на выходе получаешь другую строку или скажем число.
Здравствуйте, kavlad, Вы писали:
K>Здравствуйте, _Student_, Вы писали:
_S_>>Честно говоря, я не очень дружу с алгоритмами шифрования. Но если правильно понял, для одних и тех же данных шифрованный код будет одинаковым? или как? что такое хеш? Буду благодарен за пояснения.
K>Грубо говоря — хешь это результат шифрования K>На твою строку применяется функция хеширования — на выходе получаешь другую строку или скажем число.
Это я понимаю, так что, получается, что для строки "aabbcc" например, всегда будет одинаковый результат шифрования?
Привет, _Student_!
Вы пишешь 05 мая 2005:
S> Честно говоря, я не очень дружу с алгоритмами шифрования. S> Но если правильно понял, для одних и тех же данных шифрованный код будет одинаковым? или как?
Если ключ не менять и данные теже, то да.
Но сравнивать БЛОБы не очень удобно.
S> что такое хеш? Буду благодарен за пояснения.
Воспринимай его как некую "контрольную сумму".
Хеш-функция, независимо от размера входных данных,
даёт на выходе последовательность фиксированного (небольшого) размера.
Как получить хеш MD5, я писал в http://rsdn.ru/forum/?mid=1145470
Здравствуйте, _Student_, Вы писали:
_S_>Это я понимаю, так что, получается, что для строки "aabbcc" например, всегда будет одинаковый результат шифрования?
Здравствуйте, kavlad, Вы писали:
K>Здравствуйте, _Student_, Вы писали:
_S_>>Это я понимаю, так что, получается, что для строки "aabbcc" например, всегда будет одинаковый результат шифрования?
K>Да. Но есть свои проблемы.
Две похожие строки могут иметь одинаковый хеш. Как выбрать хорошую хеш-функцию? И еще масса проблем
Алгоритмы хеширования — это достаточно большая область для форума по делфи.
Привет, kavlad!
Вы пишешь 05 мая 2005:
AC>> Хочу посмотреть пример строк, которые приводят к коллизии для MD5.
k> Я где-нибудь хоть словом обмолвился про md5?
Да какая разница!
Задача хеширования — получение уникального "дайджеста".
В противном случае — это фикция.
k> P.S. Не факт, что хеширование вообще ему подойдет! k> Особенно, если данные закачиваются в память, а потом их надо отобразить на экране из памяти.
Я предложил хеширование не в качестве замены шифрования!
Но в дополнение к нему. Для определения того, нужно ли шифровать
новые данные, либо же, они идентичны сохранённым.
Шифрование — операция гораздо более ресурсоёмкая, по отношению к хешированию.
Кроме того, сравнение БЛОБов, тоже полновеснее, чем сравнение хешей.
Привет, Гай!
Вы пишешь 05 мая 2005:
k>>> Две похожие строки могут иметь одинаковый хеш.
Г> Две ПОХОЖИЕ строки НЕ МОГУТ иметь одинаковый хэш. В этом вся суть хеширования.
Hello, Гай!
You wrote on Thu, 05 May 2005 09:40:31 GMT:
>> From: Alex.Che >> Привет, kavlad! >> Вы пишешь 05 мая 2005:
k>>> Две похожие строки могут иметь одинаковый хеш.
Г> Две ПОХОЖИЕ строки НЕ МОГУТ иметь одинаковый хэш. В этом вся суть Г> хеширования.
Это не так. Вероятность совпадения хеша низка, но не более...
Ведь длина того же MD5 постоянна и не очень велика, а хеш можно считать как по любому слову, так и по роману "Война и мир" Толстого. Количество источников, по которым можно посчитать хеш значительно больше, чем вариантов значения хеша, сам подумай. Но на практике коллизии присходят крайне редко. Так что твои суждения оправданы, но лучше знать суровую правду жизни.
Хочешь иметь нулевую вероятность совпадения используй ZIP или RAR
Привет, Diouzshev!
Вы пишешь 05 мая 2005:
D> Но на практике коллизии присходят крайне редко. D> Так что твои суждения оправданы, но лучше знать суровую правду жизни.
Есть такое понятие "статистически гарантировано".
Вот от него и нужно танцевать.
А то "суровую правду жизни", пАнимаишь...
GUID пользовать не боишься?
Hello, Alex.Che!
You wrote on Thu, 05 May 2005 09:55:44 GMT:
D>> Но на практике коллизии присходят крайне редко. D>> Так что твои суждения оправданы, но лучше знать суровую правду D>> жизни.
AC> Есть такое понятие "статистически гарантировано". AC> Вот от него и нужно танцевать. AC> А то "суровую правду жизни", пАнимаишь... AC> GUID пользовать не боишься?
> From: Diouzshev > Hello, Гай! > You wrote on Thu, 05 May 2005 09:40:31 GMT:
>>> From: Alex.Che >>> Привет, kavlad! >>> Вы пишешь 05 мая 2005:
k>>>> Две похожие строки могут иметь одинаковый хеш.
Г>> Две ПОХОЖИЕ строки НЕ МОГУТ иметь одинаковый хэш. В этом вся суть Г>> хеширования.
> Это не так. Вероятность совпадения хеша низка, но не более... > Ведь длина того же MD5 постоянна и не очень велика, а хеш можно считать как > по любому слову, так и по роману "Война и мир" Толстого. Количество > источников, по которым можно посчитать хеш значительно больше, чем вариантов > значения хеша, сам подумай. Но на практике коллизии присходят крайне редко. > Так что твои суждения оправданы, но лучше знать суровую правду жизни.
Каюсь, упростил. Ессна, коллизии имеют место быть, но вероятность их настолько
низка, что может быть приравнена к нулю. Опять же, смотря какой алгоритм хэша.
Но в общих чертах моё утверждение всё же верно. Тем более что суть хеширования в
том, что при изменении в хешируемом объекте одного бита происходит изменение
большей чати хэша. Имеенно поэтому две ПОХОЖИЕ строки никогда не будут иметь
одинаковый хэш.
> With best regards, Alexander Diouzshev-Maltsev. > Posted via RSDN NNTP Server 1.9
Здравствуйте, _Student_, Вы писали: _S_>Честно говоря, я не очень дружу с алгоритмами шифрования. Но если правильно понял, для одних и тех же данных шифрованный код будет одинаковым?
Ну, в большинстве случаев это именно так. В противном случае в шифрованных данных появляется избыточность.
Поэтому ты можешь забить на хэш, а вместо этого шифровать пользовательский ввод, и сравнивать результаты шифрования. _S_>или как? что такое хеш? Буду благодарен за пояснения.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Alex.Che, Вы писали:
AC>>> GUID пользовать не боишься?
k>> ОК. Но хеш — это не только md5, хеши бывают разные
AC>Я о криптографических ключах. AC>Они вообще не должны приводить к колизиям по определению! AC>По крайней мере в теории
AC>А другие хеши тут не нужны.
а я у себя упростил.
хеш самый быстрый, а уж если хеш совпал, то не грех еще и строку сравнить.
Здравствуйте, Alex.Che, Вы писали: AC>Я о криптографических ключах. AC>Они вообще не должны приводить к колизиям по определению!
Прямо щас. AC>По крайней мере в теории
Нет. По определению, криптографический хеш отличается от некриптографического только тем, что его реверсирование — трудная задача. Т.е. подобрать такую строку, чтобы давала нужный хеш, должно быть не легче, чем прямым перебором. Вероятность коллизии никакого отношения к этому не имеет. Она определяется только длиной и количеством хешей. Ну, естественно, кроме вырожденных случаев.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Привет, Sinclair!
Вы пишешь 05 мая 2005:
AC>> Я о криптографических ключах. AC>> Они вообще не должны приводить к колизиям по определению! S> Прямо щас.
Здравствуйте, Alex.Che, Вы писали:
AC>http://www.infobez.ru/docfaq.asp?ob_no=1121
Нетрудно убедиться, что никакого отношения к вероятности коллизий термин свободность от коллизий не имеет.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Привет, Sinclair!
Вы пишешь 05 мая 2005:
AC>> http://www.infobez.ru/docfaq.asp?ob_no=1121 S> Нетрудно убедиться, что никакого отношения к вероятности коллизий термин свободность от коллизий не имеет.
От токо не надо демагогий!
Сморозил фигню, так и скажи.
А то начинаешь искать зацепки, как бы выкрутиться.
Здравствуйте, Alex.Che, Вы писали: AC>Сморозил фигню, так и скажи.
Ты конечно извини, но фигню сморозил ты. Цитирую:
Они вообще не должны приводить к колизиям по определению!
Если ты не отличаешь это утверждение от утверждения
вычислительно невозможно найти любую пару x' != x, такой что H(x')=H(x).
, то это твои проблемы. Еще раз, медленно и по буквам: вероятность коллизии на случайных данных для любой невырожденной хеш-функции одинакова.
Криптографичность хеша связана исключительно с трудностью решения обратных задач. При этом отсутствие непереборного алгоритма восстановления x по H(x) или подбора такой пары x' != x, что H(x')=H(x) никак не влияет на шансы получить такую пару случайно.
Представим себе, что мы хешируем 1024 документа в хеш длиной 8 бит. H1() — обычная, некриптографическая хеш функция. H2() — офигенно криптографическая функция.
Каково будет минимальное количество коллизий для H1()? Каково оно будет для H2()?
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Привет, Sinclair!
Вы пишешь 05 мая 2005:
AC>> Сморозил фигню, так и скажи. S> Ты конечно извини, но фигню сморозил ты.
Давай ещё пиписьками померяемся...
Твои слова: "По определению, криптографический хеш отличается от некриптографического
только тем, что его реверсирование — трудная задача.
Т.е. подобрать такую строку, чтобы давала нужный хеш, должно быть не легче, чем прямым перебором.
Вероятность коллизии никакого отношения к этому не имеет
."
А теперь ты начиешь юлить и рассказывать то, как нужно понимать
то, что написано в FAQ-е, сцылку на который я тебе дал.
Здравствуйте, Alex.Che, Вы писали: AC>А теперь ты начиешь юлить и рассказывать то, как нужно понимать AC>то, что написано в FAQ-е, сцылку на который я тебе дал.
Верно, я не учел второе требование к криптографическим функциям. С этим я согласен. Спасибо за ссылку.
Тем не менее, твое утверждение
Они вообще не должны приводить к колизиям по определению!
от этого вернее не становится.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Привет, Sinclair!
Вы пишешь 05 мая 2005:
AC>> А теперь ты начиешь юлить и рассказывать то, как нужно понимать AC>> то, что написано в FAQ-е, сцылку на который я тебе дал. S> Верно, я не учел второе требование к криптографическим функциям. С этим я согласен. Спасибо за ссылку. S> Тем не менее, твое утверждение S>
Они вообще не должны приводить к колизиям по определению!
