2013-05-30 4 views
1

Я хочу, чтобы загрузить следующий шестнадцатеричный файл, который имеетКак читать шестнадцатеричный файл в Numpy массив

1) инициализирует значение (IV) на первой линии,
2) encrption ключ на второй линии,
3) количество простых текстов на третьей линии, и
4) фактические простые тексты для шифрования AES в режиме

в Numpy массив цепочкой цифровых блоков (CBC).

6bce1cb8d64153f82570751b6653c943 
b15a65475a91774a45106fbc28f0df70 
10 
f493befb2dcad5118d523a4a4bf4a504 
54fc4e0a82ae8dc56cc7befc9994b79d 
878d287647b457fd95d40691b6e0c8ab 
dc0adc16665eb96a15d3257752ae67dc 
8cda3b8f23d38e9240b9a89587f69970 
e06301763146c1bac24619e61015f481 
c19def2f12e5707d89539e18ad104937 
048d734a1a36d4346edc7ceda07ff171 
5e621ce0a570478c1c2ec3e557ca3e0d 
e55c57b119ff922b7f87db0ead2006cd 

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

Идея состоит в том, чтобы загрузить этот файл в массив numpy и затем эффективно выполнить шифрование AES.

Как я могу загрузить это в массив numpy, а затем использовать AES из Crypto.Cipher для шифрования AES этого файла и подобных файлов. У меня есть файлы этого формата, содержащие до 100 миллионов простых текстов.

Спасибо и пожалуйста, дайте мне знать, если у вас есть какие-либо вопросы

+2

Вы уверены, что загрузите 1,6 ГБ + данных в один гигантский массив в памяти и не будете выполнять какую-либо обработку до тех пор, пока не будет выполнена загрузка и препроцессинг (де-гекслификация), будет быстрее, чем просто обрабатывать ее итеративно? – abarnert

+4

Почему вы хотите загрузить это в массив numpy? Это не будет делать 'Crypto.Cipher.AES' быстрее, я не должен думать. – DSM

+0

Является ли это более быстрым или нет, это то, что я хочу видеть. Может, так оно и есть? Кто знает ? Так что лучше проверьте это – user2065276

ответ

4

Я предполагаю, что вы хотите unhexlify данные и хранить полученные байтовые строки в качестве фиксированной длиной строки символов, а не object. (Вы не можете хранить их как тип типа int128, потому что numpy не имеет такого типа.)

Чтобы не читать 3,2 ГБ текста в память и использовать примерно такую ​​же сумму, предварительно обработав ее желаемая форма, вы, вероятно, хотите использовать fromiter, так:

with open(myfile) as f: 
    iv = binascii.unhexlify(f.readline().strip()) 
    key = binascii.unhexlify(f.readline().strip()) 
    count = int(f.readline()) 
    a = np.fromiter((binascii.unhexlify(line.strip()) for line in f), dtype='|S16') 

Если у вас есть 10 ГБ оперативной памяти, чтобы сэкономить (грубо приблизительная предположение), то может быстрее читать все дело в качестве array из object, затем преобразуйте его дважды ... но я в этом сомневаюсь.


Как будет ли это поможет ... Вы могли бы получить небольшую выгоду, поскольку AES-ки 16 байт может быть достаточно быстро, что стоимость итерации заметно. Давайте проверим это и посмотрим.

С 64-разрядным Mac Python 2.7.2 я создал массив из 100000 S16s, скопировав ваш пример повторно. Затем:

In [514]: %timeit [aes.encrypt(x) for x in a] 
10 loops, best of 3: 166 ms per loop 
In [515]: %timeit np.vectorize(aes.encrypt)(a) 
10 loops, best of 3: 126 ms per loop 

Таким образом, это почти 25% экономии. Неплохо.

Конечно, массив занимает больше времени, чем просто держать вещи в итераторе в первую очередь, но, даже учитывая это, все же есть 9% прироста производительности. И вполне разумно торговать 1,6 ГБ для ускорения 9% в вашем случае использования.

Имейте в виду, что я только строю массив из 100K объектов из уже существующего списка 100K; с 100 М объектами, считываемыми с диска, I/O, вероятно, станет серьезным фактором, и вполне возможно, что итеративная обработка (позволяющая чередовать затраты процессора с ожиданием диска) будет намного лучше.

Другими словами, вам необходимо протестировать свои собственные реальные данные и сценарий. Но ты это уже знал.


Для более широкого разнообразия реализаций, с помощью простого перфорирования-тестирования строительных лесов см this pastebin.

Возможно, вы захотите попробовать комбинировать различные подходы. Например, вы можете использовать рецепт grouper от itertools для пакетного вещания в, скажем, 32K открытых текстах за раз, а затем обрабатывать каждую партию с помощью numpy, чтобы получить лучшее из того и другого. И затем pool.imap, что обработка numpy, чтобы получить максимум 3. Или, альтернативно, поместите один большой массив numpy в общую память и сделайте каждую задачу многопроцессорной обработки срезом этого массива.

+0

У меня 8GB RAM. Так что не беспокойтесь об этом – user2065276

+3

@ user2065276: Если у вас 8 ГБ ОЗУ, с использованием 3,2 ГБ для файла, не менее 3,2 ГБ для промежуточного хранилища и 1,6 ГБ для окончательного результата, это будет своп на диск, так что ты очень определенно _hould_ беспокоиться об этом. – abarnert

+0

Спасибо abarnert миллион. Ты слишком хорош! – user2065276

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