forum.opennet.ru - "Google представил механизм Adiantum для быстрого шифрования ..." (17)

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

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Google представил механизм Adiantum для быстрого шифрования ..."	+/–
Сообщение от opennews (??), 11-Фев-19, 00:17
Компания 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.dev/opennews/art.shtml?num=50123
Ответить \| Правка \| Cообщить модератору

Оглавление

Серьёзно Невозможно , Коммунист (?), 02:43 , 11-Фев-19, (6) –4

У вас в 4 раза ниже минимально допустимого значения Минимальный порог производи, Аноним (14), 07:25 , 11-Фев-19, (14) +3
Именно невозможно будет это продать, там же не написанно, что это технически н, гг (?), 09:59 , 11-Фев-19, (17)

Так а зачем гонять 16 байт плейнтекста через aes Какой в эьом смысл , Аноним (8), 03:43 , 11-Фев-19, (8)

очевидно, что это и есть главное отличие этого инновационного алгоритма от ва, Аноним (8), 03:44 , 11-Фев-19, (9) +1

чтоб для расшифровки ломать приходилось и поли с чачей и аес, но не гонять через, nevfr (?), 04:39 , 11-Фев-19, (11) +2

Скажите ещё, что 10 последовательных xor сложнее взломать , Аноним (20), 12:54 , 11-Фев-19, (20) +1

Любителя Lisp всегда видно, Аноним (18), 10:16 , 11-Фев-19, (18) +8

Смысл в том, что к поли с чачей доверия куда меньше, чем к AES, поэтому AES сохр, Онаним (?), 09:33 , 11-Фев-19, (15)

Думаю, чтобы генерить рандомный ключ для ChaCha Хотя, в целом и правда странная, funny.falcon (?), 09:51 , 11-Фев-19, (16) +1

Чем больше лейбочек, тем круче ценник , Аноним (20), 12:55 , 11-Фев-19, (21)

Наверное на это сценарий радужки просчитаны , КО (?), 10:40 , 11-Фев-19, (19) +3
Я понял цель, получить блочный шифр на все 4096 байт Т е чтобы каждый байт рез, funny.falcon (?), 16:26 , 11-Фев-19, (23) +2
https github com google adiantum, funny.falcon (?), 16:28 , 11-Фев-19, (24)

ежа с ужом , Sw00p aka Jerom (?), 15:00 , 11-Фев-19, (22) –1
ждём шифровальщиков на андройеде , огщгз (?), 17:01 , 11-Фев-19, (25) +1

Чем не устраивает dm-crypt с AES , None (??), 17:01 , 08-Май-19, (27)

Сообщения [Сортировка по ответам | RSS]

6. Сообщение от Коммунист (?), 11-Фев-19, 02:43 –4 +/–

> невозможно использовать алгоритм блочного шифрования AES из-за слишком больших накладных расходов
> Perfomance: 24 MB/s encryption 20 MB/s decryption
Серьёзно? Невозможно?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #14, #17

8. Сообщение от Аноним (8), 11-Фев-19, 03:43 +/–

Так а зачем гонять 16 байт плейнтекста через aes? Какой в эьом смысл?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #15, #19, #23, #24

9. Сообщение от Аноним (8), 11-Фев-19, 03:44 +1 +/–

(очевидно, что это и есть главное отличие этого "инновационного" алгоритма от ванильной поточной связки chacha+poly как в содиуме, но смысл его не ясен)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #11, #18

11. Сообщение от nevfr (?), 11-Фев-19, 04:39 +2 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #20

14. Сообщение от Аноним (14), 11-Фев-19, 07:25 +3 +/–

>> невозможно использовать алгоритм блочного шифрования AES из-за слишком больших накладных расходов
>> Perfomance: 24 MB/s encryption 20 MB/s decryption
> Серьёзно? Невозможно?
У вас в 4 раза ниже минимально допустимого значения. Минимальный порог производительности, при котором Google включает шифрование в Android - 80 MB/s.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

15. Сообщение от Онаним (?), 11-Фев-19, 09:33 +/–

Смысл в том, что к поли с чачей доверия куда меньше, чем к AES, поэтому AES сохранён.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #16

16. Сообщение от funny.falcon (?), 11-Фев-19, 09:51 +1 +/–

Думаю, чтобы генерить рандомный ключ для ChaCha. Хотя, в целом и правда странная конструкция.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #21

17. Сообщение от гг (?), 11-Фев-19, 09:59 +/–

Именно "невозможно" будет это продать, там же не написанно, что это технически невозможно.
Точно так же сила тока пропорциональна сопротивлению, обратно, но пропорциональна, потому что не сказанно что прямо.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

18. Сообщение от Аноним (18), 11-Фев-19, 10:16 +8 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

19. Сообщение от КО (?), 11-Фев-19, 10:40 +3 +/–

Наверное на это сценарий радужки просчитаны. :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

20. Сообщение от Аноним (20), 11-Фев-19, 12:54 +1 +/–

Скажите ещё, что 10 последовательных xor сложнее взломать.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

21. Сообщение от Аноним (20), 11-Фев-19, 12:55 +/–

Чем больше лейбочек, тем круче ценник.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

22. Сообщение от Sw00p aka Jerom (?), 11-Фев-19, 15:00 –1 +/–

ежа с ужом?

Ответить | Правка | Наверх | Cообщить модератору

23. Сообщение от funny.falcon (?), 11-Фев-19, 16:26 +2 +/–

Я понял: цель, получить блочный шифр на все 4096 байт.
Т.е. чтобы каждый байт результирующего 4к блока зависил от каждого байта исходного 4к блока.
С голым XChaCha этого не добиться, т.к. это потоковый шифр, а значит, это просто XOR с шифропотоком.
Цель конструкции в том, чтобы шифропоток зависел от всего блока.
От 4080 берём быструю хэшсумму, и с помощью AES хорошо перемешиваем вместе с последними 16 байтами.
Полученная мешанина зависит от всех 4096 байт. Следовательно шифропоток на выходе ChaCha тоже зависит от всех 4096 байт.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

24. Сообщение от funny.falcon (?), 11-Фев-19, 16:28 +/–

https://github.com/google/adiantum

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

25. Сообщение от огщгз (?), 11-Фев-19, 17:01 +1 +/–

ждём шифровальщиков на андройеде...

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #27

27. Сообщение от None (??), 08-Май-19, 17:01 +/–

Чем не устраивает dm-crypt с AES?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

6. Сообщение от Коммунист (?), 11-Фев-19, 02:43	–4 +/–
> невозможно использовать алгоритм блочного шифрования AES из-за слишком больших накладных расходов > Perfomance: 24 MB/s encryption 20 MB/s decryption Серьёзно? Невозможно?
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #14, #17

8. Сообщение от Аноним (8), 11-Фев-19, 03:43	+/–
Так а зачем гонять 16 байт плейнтекста через aes? Какой в эьом смысл?
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #9, #15, #19, #23, #24

9. Сообщение от Аноним (8), 11-Фев-19, 03:44	+1 +/–
(очевидно, что это и есть главное отличие этого "инновационного" алгоритма от ванильной поточной связки chacha+poly как в содиуме, но смысл его не ясен)
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8 Ответы: #11, #18

11. Сообщение от nevfr (?), 11-Фев-19, 04:39	+2 +/–
чтоб для расшифровки ломать приходилось и поли с чачей и аес, но не гонять через аес все данные. весьма хитрое решение.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9 Ответы: #20

14. Сообщение от Аноним (14), 11-Фев-19, 07:25	+3 +/–
>> невозможно использовать алгоритм блочного шифрования AES из-за слишком больших накладных расходов >> Perfomance: 24 MB/s encryption 20 MB/s decryption > Серьёзно? Невозможно? У вас в 4 раза ниже минимально допустимого значения. Минимальный порог производительности, при котором Google включает шифрование в Android - 80 MB/s.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6

15. Сообщение от Онаним (?), 11-Фев-19, 09:33	+/–
Смысл в том, что к поли с чачей доверия куда меньше, чем к AES, поэтому AES сохранён.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8 Ответы: #16

16. Сообщение от funny.falcon (?), 11-Фев-19, 09:51	+1 +/–
Думаю, чтобы генерить рандомный ключ для ChaCha. Хотя, в целом и правда странная конструкция.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #15 Ответы: #21

17. Сообщение от гг (?), 11-Фев-19, 09:59	+/–
Именно "невозможно" будет это продать, там же не написанно, что это технически невозможно. Точно так же сила тока пропорциональна сопротивлению, обратно, но пропорциональна, потому что не сказанно что прямо.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6

18. Сообщение от Аноним (18), 11-Фев-19, 10:16	+8 +/–
> (...) Любителя Lisp всегда видно
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9

19. Сообщение от КО (?), 11-Фев-19, 10:40	+3 +/–
Наверное на это сценарий радужки просчитаны. :)
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8

20. Сообщение от Аноним (20), 11-Фев-19, 12:54	+1 +/–
Скажите ещё, что 10 последовательных xor сложнее взломать.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11

21. Сообщение от Аноним (20), 11-Фев-19, 12:55	+/–
Чем больше лейбочек, тем круче ценник.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #16

22. Сообщение от Sw00p aka Jerom (?), 11-Фев-19, 15:00	–1 +/–
ежа с ужом?
Ответить \| Правка \| Наверх \| Cообщить модератору

23. Сообщение от funny.falcon (?), 11-Фев-19, 16:26	+2 +/–
Я понял: цель, получить блочный шифр на все 4096 байт. Т.е. чтобы каждый байт результирующего 4к блока зависил от каждого байта исходного 4к блока. С голым XChaCha этого не добиться, т.к. это потоковый шифр, а значит, это просто XOR с шифропотоком. Цель конструкции в том, чтобы шифропоток зависел от всего блока. От 4080 берём быструю хэшсумму, и с помощью AES хорошо перемешиваем вместе с последними 16 байтами. Полученная мешанина зависит от всех 4096 байт. Следовательно шифропоток на выходе ChaCha тоже зависит от всех 4096 байт.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8

24. Сообщение от funny.falcon (?), 11-Фев-19, 16:28	+/–
https://github.com/google/adiantum
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8

25. Сообщение от огщгз (?), 11-Фев-19, 17:01	+1 +/–
ждём шифровальщиков на андройеде...
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #27

27. Сообщение от None (??), 08-Май-19, 17:01	+/–
Чем не устраивает dm-crypt с AES?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #25