2015-12-25 5 views
3

У меня есть ~ 2 ТБ CSV, где первые 2 столбца содержит два идентификационных номера. Они должны быть анонимизированы, чтобы данные могли использоваться в академических исследованиях. Анонимизация может быть (но не обязательно) необратимой. Это НЕ медицинские записи, поэтому мне не нужен самый причудливый криптографический алгоритм.Анинимизация номеров счетов в 2 ТБ CSV

Вопрос:

Стандартные алгоритмы хэширования сделать очень длинные строки, но мне придется сделать кучу ID-согласования (т.е. «для подмножества строк в данных, содержащих ID XXX, сделать ...) 'для обработки анонимных данных, поэтому это не идеально. Есть ли способ лучше?

Например, если я знаю, что существует ~ 10 миллионов уникальных номеров учетных записей, существует ли стандартный способ использования набора целых чисел [1: 10 миллионов] в качестве замены/анонимных идентификаторов?

Расчетное ограничение состоит в том, что данные, скорее всего, будут анонимизированы на 32-ядерном сервере 500 ГБ.

+0

(a * x + b)% m; с m около 10 миллионов, нечетным и относительно простым по m; и сохранить a и b «секрет». – wildplasser

+0

Есть ли формат номеров учетных записей (или каждой клавиши)? – itsols

+0

нет, если 'gcd (a, m) == 1' (« относительно простое »). Попробуйте с помощью {a, m}: = (малых) простых чисел. (для OP, m обязательно должно быть> = max (исходный номер)) – wildplasser

ответ

0

Я предполагаю, что вы хотите сделать один проход, один CSV с номерами ID в качестве ввода, другой CSV с анонимизированными номерами в качестве вывода. Я буду также принять количество уникальных идентификаторов где-то порядка 10 миллионов или меньше.

Это моя мысль, что было бы лучше использовать какую-то полностью произвольную функцию от набора идентификационных номеров (N) до набора идентифицированных номеров (D). Это было бы более безопасно. Если вы использовали некоторую функцию хеша , и противник узнал, что такое хэш, номера в N можно было бы восстановить без особых проблем с помощью атаки словаря . Вместо этого я предлагаю простую таблицу поиска: ID 1234567 карты с идентификационным номером 4672592 и т. Д. Соответствие будет , сохраненное в другом файле, и противник без этого файла не будет , способным многое сделать.

С 10 миллионами или менее записей на машине, такой как вы описываете, это не большая проблема. Программа эскиза в псевдо-питоне:

mapping = {} 
unused_numbers = list(range(10000000)) 

while data: 
    read record 
    for each ID number N in record: 
     if N in mapping: 
      D = mapping[N] 
     else: 
      D = choose_random(unused_numbers) 
      unused_numbers.del(D) 
      mapping[N] = D 
     replace N with D in record 
    write record 

write mapping to lookup table file 
+0

Может кто-нибудь объяснить, почему это происходит вниз? Я изначально думал о том, чтобы что-то делать в одном направлении ... Единственный недостаток, который я вижу, заключается в том, что объект «mapping» становится очень большим, а это означает, что «если N в отображении: ... do» может получить ужасно медленный к концу анонимизации. – cataclysmic

+0

@cataclysmic: Он не должен замедляться. 'mapping' является' dict', по существу хэш-таблицей, и доступ должен быть больше похож на O (1), чем O (N). По крайней мере, до тех пор, пока достаточно памяти, чтобы избежать обмена, и у вас должно быть много всего с машиной, о которой вы говорили. –

0

Кажется, вы не заботитесь о том, чтобы идентификаторы были обратимыми, но если это помогает, вы можете попробовать одну из идей format preserving encryption. Они в значительной степени предназначены для этого варианта использования.

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

PS. Если вы закончите делать хеширование, убедитесь, что вы добавили соль разумного размера. Хэши идентификаторов в диапазоне [1: 10M] были бы тривиальны, если брутфорс в противном случае.

+1

Если вы используете разные соли для всего, вам нужно их хранить. Если вы используете одну соль для всех, то это не соль, не так ли? –

+0

Технически нет, это не так, может быть, я не должен был называть его солью. Если вы хотите убедиться, что одинаковые исходные идентификаторы соответствуют тем же хэшам, вам придется хранить их во время обработки. Но я не уверен, насколько это важно в этом случае. Просто создавая огромную случайную соль для всех, вы должны обеспечить то, что необходимо (предотвратите грубое принуждение). – viraptor

+1

Соли в хранилищах паролей различны, так что пространство поиска расширено, а общие пароли не имеют хеш-значения для одного и того же значения. Здесь нам нужно только расширенное пространство. – viraptor

 Смежные вопросы

  • Нет связанных вопросов^_^