|
Действия ...
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
25.08.2016, 09:06
|
|||
|---|---|---|---|
Поиск по криптованным данным |
|||
|
#18+
Как известно, когда данные криптуются, то можно использовать случайный IV для каждой строки, тогда однаковые данные в разных строках все равно будут выглядеть по-разному когда закриптованы. Это очень хорошо, но не позволяет производить поиск по таким данным именно по этой причине. Вопрос - есть-ли какие-то решения данной проблемы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.08.2016, 10:10
|
|||
|---|---|---|---|
Поиск по криптованным данным |
|||
|
#18+
Для того и шифрование. Кроме всего прочего перед шифрованием данные могут быть пожаты архиватором. Поэтому сначала расшифровать, а потом искать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.08.2016, 12:29
|
|||
|---|---|---|---|
Поиск по криптованным данным |
|||
|
#18+
А зачем тогда использовать случайный IV? Как вариант, можно хранить в соседних колонках зашифрованные данные и хеш от незашифрованных данных. И искать по хешу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.08.2016, 13:57
|
|||
|---|---|---|---|
|
|||
Поиск по криптованным данным |
|||
|
#18+
stenfordВопрос - есть-ли какие-то решения данной проблемы? В общем случае - нет. В частном - возможен поиск исключительно на равенство для блоков информации, совпадающих по размерам с блоком шифрования и соответствующим смещением. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.08.2016, 03:56
|
|||
|---|---|---|---|
Поиск по криптованным данным |
|||
|
#18+
ну ок, нет так нет, просто это открывает путь к взлому если у хакера есть read-only доступ к базе, теоретически можно подобрать значение интересующего поля даже без знания ключа. Расшифровывать перед поиском нереально по соображениям производительности, а хэш тут ничем не поможет ибо проблема взлома-то останется, значение поля просто подберут по одинаковым хэшам ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.08.2016, 10:40
|
|||
|---|---|---|---|
Поиск по криптованным данным |
|||
|
#18+
stenford, эээ... предлагаю революционный подход - не давать хакеру read-only доступа к базе. Для небольших баз и особо ценных данных (к примеру, паролей или номеров банковских карт) обычное решение - на машину с БД ставится приложение с сетевым API, реализующим нужный доступ к нужным данным, после чего файрволл закручивается так, что из сети видно только это самое API. В целом ваша задача не реализуема - см https://ru.wikipedia.org/wiki/Полностью_гомоморфное_шифрование ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.08.2016, 14:10
|
|||
|---|---|---|---|
|
|||
Поиск по криптованным данным |
|||
|
#18+
stenfordпросто это открывает путь к взлому если у хакера есть read-only доступ к базе, теоретически можно подобрать значение интересующего поля даже без знания ключа. Да, да, осталась мелочь: проверить все возможные значения 128 бит и понять какие из них - правильные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.08.2016, 01:17
|
|||
|---|---|---|---|
Поиск по криптованным данным |
|||
|
#18+
scfэээ... предлагаю революционный подход - не давать хакеру read-only доступа к базе. Для небольших баз и особо ценных данных (к примеру, паролей или номеров банковских карт) обычное решение - на машину с БД ставится приложение с сетевым API, реализующим нужный доступ к нужным данным, после чего файрволл закручивается так, что из сети видно только это самое API. все это не отменяет остальных защит, данные все равно должны шифроваться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.08.2016, 01:22
|
|||
|---|---|---|---|
Поиск по криптованным данным |
|||
|
#18+
Dimitry SibiryakovДа, да, осталась мелочь: проверить все возможные значения 128 бит и понять какие из них - правильные. все куда проще - хакер открывает свой лигитимный аккаунт и выставляет например значение пинкода у своей карточки в значение 6714. После чего (исходим из того что есть хотя-бы read-only access) просматривает все остальные аккаунты на предмет совпадения шифра - где совпало - пинкод взломан. Через N-ое число итераций взломаны будут все пинкоды в системе ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.08.2016, 08:09
|
|||
|---|---|---|---|
Поиск по криптованным данным |
|||
|
#18+
stenfordвсе куда проще - хакер открывает свой лигитимный аккаунт и выставляет например значение пинкода у своей карточки в значение 6714. После чего (исходим из того что есть хотя-бы read-only access) просматривает все остальные аккаунты на предмет совпадения шифра - где совпало - пинкод взломан. Через N-ое число итераций взломаны будут все пинкоды в системе КМК ты резко уводишь нас в обсуждение уязвимостией какой-то конкретной банковской системы. Криптография здесь непричем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.08.2016, 08:18
|
|||
|---|---|---|---|
Поиск по криптованным данным |
|||
|
#18+
scfак вариант, можно хранить в соседних колонках зашифрованные данные и хеш от незашифрованных данных. И искать по хешу. В общем случае это нежелательно делать. Любая информация об зашифрованном тексте (в данном случае это ключевые слова поиска) дает атакующему больше сведений о том что лежит в шифро тексте. В данном примере он может взять словарь и провести эффективное сопоставление хеша и зашифрованного текста. И если шифро-текст был короткий (4-5 слов) то открытый текст находится комбинаторикой. Далее надо смотреть уже по возможностям атакующюего но в любом случае это будет уязвимость типа компрометирования. С этого момента надежность алгоритма шифрования - под вопросом. Она уже не такая как предполагалось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.08.2016, 14:10
|
|||
|---|---|---|---|
|
|||
Поиск по криптованным данным |
|||
|
#18+
stenfordвсе куда проще - хакер открывает свой лигитимный аккаунт и выставляет например значение пинкода у своей карточки в значение 6714. После чего (исходим из того что есть хотя-бы read-only access) просматривает все остальные аккаунты на предмет совпадения шифра - где совпало - пинкод взломан. Оххх... как бы это сказать без мата... Блок шифрования у AES - 128 бит. Пинкод занимает незначительную его часть. Остаток заполняется случайными байтами. Вероятность совпадения, конечно, остаётся, но абсолютно статистически незначимая. Шифрование само по себе - не панацея и даже хуже: ничего не защищает. К нему должен прилагаться правильный разработчик. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.08.2016, 01:41
|
|||
|---|---|---|---|
Поиск по криптованным данным |
|||
|
#18+
Dimitry SibiryakovОххх... как бы это сказать без мата... Блок шифрования у AES - 128 бит. Пинкод занимает незначительную его часть. Остаток заполняется случайными байтами. Вероятность совпадения, конечно, остаётся, но абсолютно статистически незначимая. Шифрование само по себе - не панацея и даже хуже: ничего не защищает. К нему должен прилагаться правильный разработчик. При чем тут размер ключа и блоков? Ты вообще моего вопроса по-ходу не понял, при шифровании с одинаковым IV и ключом пинкод будет ВСЕГДА выглядеть одинаково в зашифрованном виде, например asdf%&^e3r8yfdgsgfds%^&$, как только хакер обнаруживает ТОЧНО ТАКУЮ-ЖЕ комбинацию где-то еще - значит пинкод одинаков ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.08.2016, 01:43
|
|||
|---|---|---|---|
Поиск по криптованным данным |
|||
|
#18+
maytonКМК ты резко уводишь нас в обсуждение уязвимостией какой-то конкретной банковской системы. Криптография здесь непричем. пинкод - это пример, может быть любое поле, которое хакер в состоянии просмотреть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.08.2016, 13:43
|
|||
|---|---|---|---|
|
|||
Поиск по криптованным данным |
|||
|
#18+
stenfordкак только хакер обнаруживает ТОЧНО ТАКУЮ-ЖЕ комбинацию где-то еще - значит пинкод одинаков Это, конечно, прелестно, но размер блока по-прежнему 128 бит и хакеру понадобится очень большой набор криптотекстов чтобы в разумное время подобрать открытый текст к одному из них. Или очень большая удача. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.08.2016, 01:32
|
|||
|---|---|---|---|
Поиск по криптованным данным |
|||
|
#18+
Dimitry SibiryakovЭто, конечно, прелестно, но размер блока по-прежнему 128 бит и хакеру понадобится очень большой набор криптотекстов чтобы в разумное время подобрать открытый текст к одному из них. Или очень большая удача. пинкод - отдельное поле, все что хакеру надо будет сделать - это произвести запрос select * from cardstable where pincode = 'asdf%&^e3r8yfdgsgfds%^&$', при наличии скажем миллиона клиентов, у пары-тройки из них пинкод совпадет и запрос выведет эти строки. Далее он меняет пинкод и повторяет процедуру для взлома новых записей И у меня шифрование с 32-битным ключом ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.08.2016, 08:30
|
|||
|---|---|---|---|
Поиск по криптованным данным |
|||
|
#18+
Непонятно зачем вообще нужен поиск по пин-коду? Сначала идентифицировал клиента, получил его шифрованный пин-код, затем проверяй. Пин можно шифровать с солью, так никогда не будет двух одинаковых даже при одинаковом IV. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.08.2016, 09:28
|
|||
|---|---|---|---|
Поиск по криптованным данным |
|||
|
#18+
Dima TНепонятно зачем вообще нужен поиск по пин-коду? Сначала идентифицировал клиента, получил его шифрованный пин-код, затем проверяй. Пин можно шифровать с солью, так никогда не будет двух одинаковых даже при одинаковом IV. это пример, не нравится пинкод - например имя клиента, или какие-нибудь поля адреса. Соль тут не нужна по-определению если есть случайный IV, именно он делает шифры непохожими друг на друга, соль используется только для хэшей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.08.2016, 14:04
|
|||
|---|---|---|---|
|
|||
Поиск по криптованным данным |
|||
|
#18+
stenfordу меня шифрование с 32-битным ключом С учётом внедрения AES в современные процессора, использование чего-то другого нужно очень сильно обосновывать. А сам AES на данный момент считается устойчивым как к brute force, так и атакам по известному содержимому. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=16&tablet=1&tid=1340626]: |
0ms |
get settings: |
10ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
92ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
63ms |
get tp. blocked users: |
1ms |
| others: | 250ms |
| total: | 454ms |
| 0 / 0 |
