Безопасный способ обмена адресами электронной почты (хеширование), позволяющий сопоставлять совпадения в другом списке, но не раскрывать те, для которых перекрытия нет? - PullRequest
1 голос
/ 27 мая 2011

Я из организации (Компания А), у которой большой список адресов электронной почты.Я отправляю подмножество из этого списка из 10 000 адресов электронной почты в другую организацию (компанию B) для проверки на совпадение (узнайте, какие адреса электронной почты находятся в обоих списках).Я хочу отправить список таким способом, который для компании B легко проверить на совпадение, но для компании B трудно (в идеале невозможно) «расшифровать» адреса электронной почты, которых еще нет в их списке.Во-вторых, я хочу убедиться, что если список, который я отправляю, окажется в чужих руках (какой-то третьей стороне), кому-то еще будет трудно узнать фактические адреса электронной почты в списке.

Мое текущее решениеэто просто извлечь письма из нашей базы данных как

SHA1(email + a_long_random_salt)

Используя ту же соль для каждого адреса электронной почты.

Чтобы сопоставить, я отправляю список хэшей и соль (безопасно), отдельно) в компанию B, и они просто ищут в своей базе данных, используя

SELECT email FROM members WHERE SHA1(email + the_salt) IN(hash1, hash2, hash3....)

(или они предварительно вычисляют хеш SHA1 для каждого адреса и сохраняют его в БД с адресом электронной почты, чтобы хеширование не выполнялось).это должно произойти во время выполнения запроса)

Достаточно длинная / случайная соль предотвращает использование предварительно вычисленной радужной таблицы для взлома хэшей.Я предполагаю, что весьма маловероятно, чтобы кто-то имел радужную таблицу из миллионов и миллионов правдоподобных адресов электронной почты, засоленных любой случайной строкой из 100 символов, которую я использую в качестве соли.Пока соль держится в секрете, никакая третья сторона не собирается декодировать этот список с помощью радужного стола или грубой силы.(Пожалуйста, поправьте меня, если я здесь что-то не так.)

Проблема, с которой я бьюсь, заключается в том, что есть, очевидно, легко получаемые списки миллионов и миллионов адресов электронной почты, собранных из Интернета.Компании B было бы довольно легко получить один из этих списков, вычислить хэши, используя предоставленную мной соль, и восстановить некоторую значительную часть писем в списке, который я отправил (конечно, не все, но значительную часть).

Есть ли какая-то стратегия для завершения этого матча, которую я не смог придумать?Единственное, о чем я могу думать, - это использовать более сложный метод хеширования (то есть несколько итераций), чтобы сделать его на медленнее , чтобы сопоставить его со списком сотен миллионов адресов электронной почты (этот теоретический список вычеркнут из Интернета).Ключевым моментом является то, что на самом деле это будет только медленнее - не совсем даже сложно .Кроме того, я знаю, что собственный список адресов электронной почты компании B находится в диапазоне от 1 миллиона адресов, поэтому я не могу дать им схему хеширования, которая потребовала бы много секунд для вычисления каждого адреса в этом списке из 1 миллиона.Простое замедление не решает проблему - я думаю, что мне нужен совершенно другой подход.

Честно говоря, этот конкретный случай для меня является скорее академическим упражнением, чем реальной проблемой безопасности.Я верю, что Компания B не собирается пытаться сделать это (мы часто работаем вместе), и даже если они это сделают, это не будет огромной потерей.Все, что они могли бы узнать, это адреса электронной почты 10 000 человек в нашем списке рассылки - мы не говорим о паролях, номерах кредитных карт и т. Д. Если бы мы имели дело с паролями или номерами кредитных карт, я бы даже не подумал о разработкекакая-то моя собственная схема.И да, конечно, я понимаю, что SHA-256 или какой-то другой более новый алгоритм может быть немного предпочтительнее, чем SHA1, но только в очень ограниченной степени.Я беспокоюсь не о грубой силе хэша.

Ответы [ 3 ]

1 голос
/ 27 мая 2011

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

Цитата из Википедии

Безопасные многопартийные вычисления (также известный как безопасное вычисление или многопартийность (MPC)) является Подполе криптографии. Цель методы для безопасной многопартийности расчет должен позволить сторонам совместно вычислить функцию над их входы, в то же время сохраняя эти входы частные.

Если вы посетите страницу http://en.wikipedia.org/wiki/Secure_multiparty_computation В разделе «Внешние ссылки» содержатся библиотеки и ссылки, с которых можно начать.

0 голосов
/ 30 мая 2011

Мне кажется, что ваша проблема может быть переформулирована как:

Компания B имеет доступ к списку 1 миллион адрес электронной почты, список А. Они также есть доступ к другому списку несколько миллионов адресов электронной почты, список B. Я бы хотел, чтобы компания B смогла запустить алгоритм, чтобы иметь возможность определить, какой из адресов электронной почты в списке А также в нашем списке, но не сможет запустить этот алгоритм для списка Б.

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

0 голосов
/ 27 мая 2011

Одна вещь, о которой я могу подумать, это атака грубой силой на известные домены. Рассмотрим следующие факторы:

  • @hotmail.com, @ gmail.com и @ yahoo.com занимают большую долю рынка
  • список фамилий конечен и не слишком длинный. То же самое для списка имен

Используя комбинацию имени Джон и фамилии Доу, мы можем создать набор адресов, таких как JDoe@hotmail.com, DoeJ@yahoo.com, JohnDow@hotmail.com и т. Д. Набор не будет очень обширным.

В зависимости от того, насколько важен / полезен такой анализ данных (т. Е. Сколько B выиграет, узнав, что Джон Доу в вашем списке), описанная мною атака все еще может быть прибыльной. Да, я помню о солях, но все же число комбинаций имя / домен не слишком велико, чтобы их нельзя было сломить для хорошей параллельной атаки методом грубой силы.

...