Компания Google предложила (https://security.googleblog.com/2019/02/introducing-adiantum... механизм шифрования накопителей Adiantum (https://source.android.com/security/encryption/adiantum), который может применяться на маломощный устройствах, на которых невозможно использовать алгоритм блочного шифрования AES из-за слишком больших накладных расходов. В частности, Google намерен применять Adiantum для шифрования накопителей младших моделей смартфонов на базе платформы Android, оснащаемых процессорами ARM, не предоставляющими инструкции для аппаратного ускорения шифрования AES. Эталонная реализация алгоритма опубликована (https://github.com/google/adiantum) под лицензией MIT, реализация на уровне подсистемы ядра Linux dm-crypt опубликована (https://source.android.com/security/encryption/adiantum) под лицензией GPLv2 (патчи подготовлены как для редакций ядра для Android, так и для обычных ванильных ядер Linux).По аналогии с AES-128-CBC-ESSIV и AES-XTS метод Adiantum не изменяет результирующий размер данных, что позволяет использовать его для шифрования секторов на накопителях. Adiantum также обеспечивает генерацию блоков с разным шифротекстом для повторяющихся исходных данных. Реализация Adiantum базируется на применении быстрой хэш-функции NH (https://en.wikipedia.org/wiki/UMAC#NH_hash-function_family), алгоритме аутентификации сообщений (MAC) Poly1305 (http://cr.yp.to/mac.html) и потоковом шифре XChaCha12 (https://en.wikipedia.org/wiki/Salsa20#XChaCha), а также единоразовой операции на базе блочного шифра AES-256 для 16 байт в каждом блоке (с учётом размера блока в 4096 байт такая операция не критична с точки зрения производительности).
Poly1305 и XChaCha12 позиционируются как более быстрые и безопасные аналоги HMAC и AES, программная реализация которых позволяет добиться фиксированного времени выполнения без задействования специальной аппаратной поддержки. Для повышения производительности алгоритм ChaCha применяется в варианте с 12 раундами вместо обычно используемых 20, но этого вполне достаточно, так как ChaCha даже с 12 раундами обеспечивает (https://tosc.iacr.org/index.php/ToSC/article/view/7360) более высокий уровень стойкости к атакам, чем AES-256. На процессоре ARM Cortex-A7 реализация Adiantum тратит на операцию расшифровки 10.6 циклов процессора на каждый байт (при размере блока 4096 байт), что в пять раз быстрее AES-256-XTS.На процессорах с аппаратной поддержкой ускорения AES, таких как ARMv8 с инструкциями A64, A32 и T32 (Cryptography Extensions (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.... и x86 с инструкциями AES-NI (https://en.wikipedia.org/wiki/AES_instruction_set), рекомендуется применять систему шифрования дисков на базе AES, так как в этом случае аппаратно ускоренный AES будет быстрее программной реализации Adiantum. При этом Adiantum обеспечивает более высокую стойкость к атакам, так как в
AES-XTS изменение одного байта исходных данных приводит к изменению всего 16 байт шифротекста, в то время как в Adiantum изменяется целиком весь блок, равный размеру сектора (512 или 4096 байт).
URL: https://security.googleblog.com/2019/02/introducing-adiantum...
Новость: https://www.opennet.ru/opennews/art.shtml?num=50123
> невозможно использовать алгоритм блочного шифрования AES из-за слишком больших накладных расходов
> Perfomance: 24 MB/s encryption 20 MB/s decryptionСерьёзно? Невозможно?
>> невозможно использовать алгоритм блочного шифрования AES из-за слишком больших накладных расходов
>> Perfomance: 24 MB/s encryption 20 MB/s decryption
> Серьёзно? Невозможно?У вас в 4 раза ниже минимально допустимого значения. Минимальный порог производительности, при котором Google включает шифрование в Android - 80 MB/s.
Именно "невозможно" будет это продать, там же не написанно, что это технически невозможно.
Точно так же сила тока пропорциональна сопротивлению, обратно, но пропорциональна, потому что не сказанно что прямо.
Так а зачем гонять 16 байт плейнтекста через aes? Какой в эьом смысл?
(очевидно, что это и есть главное отличие этого "инновационного" алгоритма от ванильной поточной связки chacha+poly как в содиуме, но смысл его не ясен)
чтоб для расшифровки ломать приходилось и поли с чачей и аес, но не гонять через аес все данные. весьма хитрое решение.
Скажите ещё, что 10 последовательных xor сложнее взломать.
> (...)Любителя Lisp всегда видно
Смысл в том, что к поли с чачей доверия куда меньше, чем к AES, поэтому AES сохранён.
Думаю, чтобы генерить рандомный ключ для ChaCha. Хотя, в целом и правда странная конструкция.
Чем больше лейбочек, тем круче ценник.
Наверное на это сценарий радужки просчитаны. :)
Я понял: цель, получить блочный шифр на все 4096 байт.
Т.е. чтобы каждый байт результирующего 4к блока зависил от каждого байта исходного 4к блока.
С голым XChaCha этого не добиться, т.к. это потоковый шифр, а значит, это просто XOR с шифропотоком.
Цель конструкции в том, чтобы шифропоток зависел от всего блока.
От 4080 берём быструю хэшсумму, и с помощью AES хорошо перемешиваем вместе с последними 16 байтами.
Полученная мешанина зависит от всех 4096 байт. Следовательно шифропоток на выходе ChaCha тоже зависит от всех 4096 байт.
https://github.com/google/adiantum
ежа с ужом?
ждём шифровальщиков на андройеде...
Чем не устраивает dm-crypt с AES?