высокопроизводительное шифрование в Adobe Air / Flash

Question

При поиске классов / функций, связанных с шифрованием, в сценарии действия / air / flash я видел проект as3crypto .

Этот вариант предоставляет v. Хороший набор опций, но меня немного беспокоит то, что означают представленные числа, когда они используются для дешифрования локального медиа-файла, когда он выбран для воспроизведения.

Я ищу баланс безопасности и производительности .

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

Самым сложным является использование его для флэш-приложений , так как на самом деле нужно ждать, пока все что-нибудь сделает . Если это предположение неверно, то здесь лучший алгоритм производительности в списке на странице as3crypto выглядит как слишком медленный т.е. при 1,5 МБ х сек, для расшифровки флэш-памяти 30 МБ потребуется 20 секунд приложение .

основные вопросы У меня есть на это:

• Существуют ли другие библиотеки с более высокой производительностью? Что-нибудь в воздухе Adobe возможно?
• Для видео / песен , что было бы хорошим значением МБ х сек, чтобы оно могло воспроизводиться ?
• Ожидает ли Flash полной загрузки приложения, прежде чем запускать что-либо из этого?

Answer 1

Что касается производительности, если вы можете передавать потоковое видео и музыку, то есть обрабатывать их по одному блоку за раз, тогда вам нужно только расшифровать один блок вперед, а не расшифровывать весь файл. Это, вероятно, будет достаточно для производительности независимо от алгоритма.

Безопасность

Для обеспечения максимальной безопасности попробуйте AES-256, предпочтительно в режиме CTR (см. статью Колина Персиваля для обоснования). Обратите внимание, что режим CTR преобразует блочный шифр AES в эквивалент потокового шифра без снижения его безопасности - у него есть некоторые полезные свойства, такие как расшифровка с произвольным доступом (по сравнению с CBC, которая заставляет вас расшифровывать все до нужных данных).

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

Наконец, способ генерации ключей шифрования очень важен :

Nonce / IV

Если вы используете один и тот же базовый ключ для шифрования всех файлов, всегда используйте одноразовый номер (a.k.a IV или «Вектор инициализации») при шифровании:

• nonce / IV - это группа случайных байтов, которые хранятся в незашифрованном виде рядом с вашим зашифрованным текстом (часто перед этим зашифрованным текстом)
• Создание и использование разных nonce / IV для каждого зашифрованного файла
• API режима CTR включают способ установки IV / nonce, используемая вами библиотека поддерживает его
• Если вы используете RC4:
  • Спасите nonce / IV самостоятельно
  • сгенерируйте окончательный ключ шифрования, используя HMAC-SHA256 с базовым ключом и одноразовым номером, как упомянуто здесь

Генерация ключа из пароля

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

Поскольку у вас есть реализация hmac-sha256 в библиотеке, вы легко можете внедрить PBKDF2-HMAC-SHA256 самостоятельно, найдите примеры реализации в сети или SO.

Answer 2

Мне интересно, какой тип шифрования вы используете. Симметричная или асимметричная криптография? В случае асимметричного, попробуйте переключиться на симметричный.

В случае симметричного, используйте потоковый шифр (RC4 или любой другой вариант, просто Google для имен), так как имя предполагает, что вы можете шифровать / дешифровать в потоках, так что это соответствует вашим потребностям. Насколько я помню, RC4 дает лучшую производительность большинства потоковых шифров (все еще используемых в WEP и WPA1)

Другой вариант - использовать блочный шифр в режиме ECB (электронная кодовая книга). Это позволяет частично зашифровать / расшифровать содержимое, поскольку каждый блок из 64/128/192/256 битов зашифровывается / дешифруется отдельно. Обратите внимание, что режим ECB менее безопасен, чем более обычный режим CBC (Chained Block Cipher), но здесь вы можете только шифровать / дешифровать контент в целом.

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

Answer 3

Попробуйте XTEA - он достаточно силен, если правильно реализован; очень простой в реализации и достаточно быстрый (он может работать в интерпретируемой виртуальной машине с приемлемым уровнем производительности).

Библиотека AS3crypto включает реализацию XTEA, которую вы сможете импортировать напрямую.

Answer 4

Используйте SSL вместо Flash crypto для шифрования контента при его передаче через Интернет.