Регистрация Войти
Рейтинг:2
phantomcraft avatar Crypto

Каковы были бы недостатки очень больших размеров блоков в блочных шифрах?

флаг pf
phantomcraft

Предположим, кто-то создал блочный шифр с размером блока 8192 байта (65536 бит) или, может быть, с размером блока 16384 байта (131072 бита).

Что было бы его недостатки по блочному шифру с меньшими размерами блоков, такими как 128 или 256 бит?

88
0 + 0
Paul Uszak avatar
флаг cn
Paul Uszak
Не подходит для Arduino?
1
Ответить
флаг et
user93353
Допустим, у вас есть размер блока 65536 бит, а ваш обычный текст - 65537 бит или (65536 * k) + 1 бит, тогда вам нужно будет дополнить последний блок 65535 битами, что является пустой тратой. Кроме того, я думаю, что большие размеры блоков становятся неэффективными.
0
Ответить
Paul Uszak avatar
флаг cn
Paul Uszak
@ user93353 Это интересный момент. Одна из дурацких причин, которую антипейдеры придумывают против одноразовых блокнотов, заключается в том, что становится трудно зашифровать жесткий диск на 12 ТБ. Тем не менее, вы предполагаете, что люди могут отправлять небольшие сообщения. Дихотомия?
0
Ответить
Paul Uszak avatar
флаг cn
Paul Uszak
Дихотомия будет усиливаться в том смысле, что современная криптография предназначена для наименьшего общего знаменателя по сравнению с аппаратным обеспечением vi. Один размер должен соответствовать всем/всем яйцам в одной корзине. Никакая другая область человеческой деятельности не следует этому принципу, но он подходит АНБ как минимизация поверхности атаки. Так что не допустят.
0
Ответить
флаг et
user93353
@PaulUszak - «Тем не менее, вы предполагаете, что люди могут отправлять небольшие сообщения» - нет, я не предлагаю, чтобы люди могли отправлять небольшие сообщения. Даже если это большое сообщение, но размер сообщения составляет (65536*k) + 1 бит, происходит такая же потеря заполнения.
1
Ответить
флаг et
user93353
@PaulUszak - есть и другие причины не использовать потоковые шифры в FDE - https://crypto.stackexchange.com/a/53544/3941
1
Ответить
r3mainer avatar
флаг us
r3mainer
Еще одной проблемой будет задержка. Если вы шифруете поток MP3 со скоростью 64 кбит/с с размером блока 65536 бит, то у вас будет 1-секундная задержка кодирования на передающей стороне (возможно, также и на принимающей стороне, в зависимости от пропускной способности канала).
0
Ответить
Рейтинг:2
kelalaka avatar Crypto
флаг in
kelalaka

  • Проблема заполнения: Если вы используете режим блочного шифрования, такой как CBC, то им нужно заполнение, и помните, что заполнение всегда применяется независимо от размера. Даже если размер $65536*к$ то требуется новый полный блок. Непонятно, как можно применить заполнение PKCS#7, так как он поддерживает блоки размером до 256 байт. Есть и другие простые отступы, такие как добавление 1 затем нули, затем кодирование размера заполнения.

    В современной криптографии мы отказались от режимов заполнения, мы используем такие режимы, как AES-GCM, а режимы ChaCha20-Poly1305 — это режимы аутентификации без дополнений.

  • Количество раундов: Если мы рассмотрим Rijndael, который требует дополнительного раунда на 32 блока, аналогичный блочный шифр потребует 2048 раундов для достижения того же уровня безопасности (имейте в виду, что это действительно грубая оценка). Это создает задержку для первого вывода. ~ в 148 раз медленнее, чем первый выход AES-256. Хотя эта задержка может быть не важна для обмена сообщениями в Signal, есть места, где задержка не является предпочтительной.

  • Проблема с размером ключа: В SPN мы используем ключ x-or для округления значений. Если размер ключа меньше размера блока, это действительно проблема безопасности, которая может открыть новые возможности для линейных и дифференциальных атак. Следовательно, необходимо сгенерировать, обменяться передачами и сохранить ключ размером 65536 бит.

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

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

  • Постквант: Это не дает никаких преимуществ для постквантовой обработки, поскольку AES-256 уже защищен от оптимального алгоритма Гровера.

  • Нужны ли нам более 128-битные блочные шифры?

    Да. Например, если бы AES был стандартизирован точно так же, как Rijndael, то случайные проблемы одноразового номера AES-GCM больше не будут для нас проблемой. Случайные одноразовые номера размером 256 будут защищены от коллизий под одним и тем же ключом.

  • Есть ли у нас более 256-битные блочные шифры?

    Да, дружественный к процессору ChaCha20 с 512-битным выходом в режиме CTR. XChaCha20 имеет хорошую защиту от коллизий одноразовых номеров благодаря 192-битному размеру одноразовых номеров.

0 + 0
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

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