The OpenNET Project / Index page

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

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
Тип: К сведению
Ключевые слова: adiantum, android, crypt
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.6, Коммунист (?), 02:43, 11/02/2019 [ответить] [показать ветку] [···]    [к модератору]
  • –3 +/
    > невозможно использовать алгоритм блочного шифрования AES из-за слишком больших накладных расходов
    > Perfomance: 24 MB/s encryption 20 MB/s decryption

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

     
     
  • 2.14, Аноним (14), 07:25, 11/02/2019 [^] [ответить]     [к модератору]
  • +1 +/
    У вас в 4 раза ниже минимально допустимого значения Минимальный порог производи... весь текст скрыт [показать]
     
  • 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 [^] [ответить]    [к модератору]  
  • +3 +/
    чтоб для расшифровки ломать приходилось и поли с чачей и аес, но не гонять через аес все данные. весьма хитрое решение.
     
     
  • 4.20, Аноним (20), 12:54, 11/02/2019 [^] [ответить]    [к модератору]  
  • +/
    Скажите ещё, что 10 последовательных xor сложнее взломать.
     
  • 3.18, Аноним (18), 10:16, 11/02/2019 [^] [ответить]    [к модератору]  
  • +4 +/
    > (...)

    Любителя 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 [^] [ответить]    [к модератору]  
  • +2 +/
    Наверное на это сценарий радужки просчитаны. :)
     
  • 2.23, funny.falcon (?), 16:26, 11/02/2019 [^] [ответить]    [к модератору]  
  • +/
    Я понял: цель, получить блочный шифр на все 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.25, огщгз (?), 17:01, 11/02/2019 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    ждём шифровальщиков на андройеде...
     

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


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