The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Google представил механизм Adiantum для быстрого шифрования накопителей

10.02.2019 22:52

Компания Google предложила механизм шифрования накопителей Adiantum, который может применяться на маломощных устройствах, на которых невозможно использовать алгоритм блочного шифрования AES из-за слишком больших накладных расходов. В частности, Google намерен применять Adiantum для шифрования накопителей младших моделей смартфонов на базе платформы Android, оснащаемых процессорами ARM, не предоставляющими инструкции для аппаратного ускорения шифрования AES. Эталонная реализация алгоритма опубликована под лицензией MIT, реализация на уровне подсистемы ядра Linux dm-crypt опубликована под лицензией GPLv2 (патчи подготовлены как для редакций ядра для Android, так и для обычных ванильных ядер Linux).

По аналогии с AES-128-CBC-ESSIV и AES-XTS метод Adiantum не изменяет результирующий размер данных, что позволяет использовать его для шифрования секторов на накопителях. Adiantum также обеспечивает генерацию блоков с разным шифротекстом для повторяющихся исходных данных. Реализация Adiantum базируется на применении быстрой хэш-функции NH, алгоритме аутентификации сообщений (MAC) Poly1305 и потоковом шифре XChaCha12, а также единоразовой операции на базе блочного шифра AES-256 для 16 байт в каждом блоке (с учётом размера блока в 4096 байт такая операция не критична с точки зрения производительности).

Poly1305 и XChaCha12 позиционируются как более быстрые и безопасные аналоги HMAC и AES, программная реализация которых позволяет добиться фиксированного времени выполнения без задействования специальной аппаратной поддержки. Для повышения производительности алгоритм ChaCha применяется в варианте с 12 раундами вместо обычно используемых 20, но этого вполне достаточно, так как ChaCha даже с 12 раундами обеспечивает более высокий уровень стойкости к атакам, чем AES-256. На процессоре ARM Cortex-A7 реализация Adiantum тратит на операцию расшифровки 10.6 циклов процессора на каждый байт (при размере блока 4096 байт), что в пять раз быстрее AES-256-XTS.

На процессорах с аппаратной поддержкой ускорения AES, таких как ARMv8 с инструкциями A64, A32 и T32 (Cryptography Extensions) и x86 с инструкциями AES-NI, рекомендуется применять систему шифрования дисков на базе AES, так как в этом случае аппаратно ускоренный AES будет быстрее программной реализации Adiantum. При этом Adiantum обеспечивает более высокую стойкость к атакам, так как в AES-XTS изменение одного байта исходных данных приводит к изменению всего 16 байт шифротекста, в то время как в Adiantum изменяется целиком весь блок, равный размеру сектора (512 или 4096 байт).

  1. Главная ссылка к новости (https://security.googleblog.co...)
  2. OpenNews: Google представил Android Go, платформу для телефонов с небольшим ОЗУ
  3. OpenNews: В Chrome добавлены средства шифрования, стойкие к подбору на квантовом компьютере
  4. OpenNews: Для файловой системы Ext4 представлена поддержка шифрования
  5. OpenNews: Значительное обновление файловой системы Bcachefs
  6. OpenNews: Выпуск Cryptsetup 2.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/50123-adiantum
Ключевые слова: adiantum, android, crypt
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (17) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.6, Коммунист (?), 02:43, 11/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    > невозможно использовать алгоритм блочного шифрования AES из-за слишком больших накладных расходов
    > Perfomance: 24 MB/s encryption 20 MB/s decryption

    Серьёзно? Невозможно?

     
     
  • 2.14, Аноним (14), 07:25, 11/02/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >> невозможно использовать алгоритм блочного шифрования AES из-за слишком больших накладных расходов
    >> Perfomance: 24 MB/s encryption 20 MB/s decryption
    > Серьёзно? Невозможно?

    У вас в 4 раза ниже минимально допустимого значения. Минимальный порог производительности, при котором Google включает шифрование в Android - 80 MB/s.

     
  • 2.17, гг (?), 09:59, 11/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Именно "невозможно" будет это продать, там же не написанно, что это технически невозможно.
    Точно так же сила тока пропорциональна сопротивлению, обратно, но пропорциональна, потому что не сказанно что прямо.
     

  • 1.8, Аноним (8), 03:43, 11/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Так а зачем гонять 16 байт плейнтекста через aes? Какой в эьом смысл?
     
     
  • 2.9, Аноним (8), 03:44, 11/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    (очевидно, что это и есть главное отличие этого "инновационного" алгоритма от ванильной поточной связки chacha+poly как в содиуме, но смысл его не ясен)
     
     
  • 3.11, nevfr (?), 04:39, 11/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    чтоб для расшифровки ломать приходилось и поли с чачей и аес, но не гонять через аес все данные. весьма хитрое решение.
     
     
  • 4.20, Аноним (20), 12:54, 11/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Скажите ещё, что 10 последовательных xor сложнее взломать.
     
  • 3.18, Аноним (18), 10:16, 11/02/2019 [^] [^^] [^^^] [ответить]  
  • +8 +/
    > (...)

    Любителя Lisp всегда видно

     
  • 2.15, Онаним (?), 09:33, 11/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Смысл в том, что к поли с чачей доверия куда меньше, чем к AES, поэтому AES сохранён.
     
     
  • 3.16, funny.falcon (?), 09:51, 11/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Думаю, чтобы генерить рандомный ключ для ChaCha. Хотя, в целом и правда странная конструкция.
     
     
  • 4.21, Аноним (20), 12:55, 11/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Чем больше лейбочек, тем круче ценник.
     
  • 2.19, КО (?), 10:40, 11/02/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Наверное на это сценарий радужки просчитаны. :)
     
  • 2.23, funny.falcon (?), 16:26, 11/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Я понял: цель, получить блочный шифр на все 4096 байт.
    Т.е. чтобы каждый байт результирующего 4к блока зависил от каждого байта исходного 4к блока.
    С голым XChaCha этого не добиться, т.к. это потоковый шифр, а значит, это просто XOR с шифропотоком.
    Цель конструкции в том, чтобы шифропоток зависел от всего блока.
    От 4080 берём быструю хэшсумму, и с помощью AES хорошо перемешиваем вместе с последними 16 байтами.
    Полученная мешанина зависит от всех 4096 байт. Следовательно шифропоток на выходе ChaCha тоже зависит от всех 4096 байт.
     
  • 2.24, funny.falcon (?), 16:28, 11/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    https://github.com/google/adiantum
     

  • 1.22, Sw00p aka Jerom (?), 15:00, 11/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    ежа с ужом?
     
  • 1.25, огщгз (?), 17:01, 11/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    ждём шифровальщиков на андройеде...
     
     
  • 2.27, None (??), 17:01, 08/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Чем не устраивает dm-crypt с AES?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру