Pull to refresh

Comments 12

спасибо за статью, только AES/CBC/PKCS5Padding встречается довольно часто в буднях разработчиков… И не только Android
TL;DR: google android aes, первая ссылка…

Ну серьёзно, тема освещалась неоднократно, в том числе на Хабре, какой-то хитрой специфики в Android относительно обычной Java нет.
Согласен с Вами по поводу обилия материала на данную тему.

Но эта статья имеет цель на легком примере показать, что шифрование это не что-то страшное и непонятное, а очень нужный и полезный инструмент, имеющий под собой красивую математическую основу.

Ну а Android — живой пример использования и внедрения.
Шифрование действительно не является чем-то страшным и непонятным))) Но эта эйфория проходит, когда Вам нужно применить его для «серьезных» задач, требующих сертификации у «регуляторов» — вот тут начинаются «танцы с бубном».
А «для поиграться» — это пожалуйста)))
Вопрос к знатокам… Что лучше с точки зрения безопасности: генерировать вектор инициализации IV случайным образом при каждом шифровании и передавать с сообщением или использовать его в фиксированном виде?

Я так понимаю, что в описанной задаче и ключ и IV являются константами, зашитыми в код. Это так?
Вопрос безопасности является достаточно непростой темой для обсуждения и не имеет однозначного решения, т.к. устройство у пользователя может быть рутованным, трафик может перехватываться, плюс существую и другие источники опасности для каких либо засекреченных данных. Зашивать ключ просто в код — явно менее надежный способ, чем предложенный Вами.
IV нужен для первого раунда шифрования, т.к. в последующих раундах очередной блок исх текста «суммируется» с результатом шифровки предыдущего блока исх. текста. Поскольку для первого раунда у нас нет результата шифровки предыдущего блока исх. текста, то вместо него используется IV. Поэтому для одного и того же исх. текста в плане безопасности лучше использовать случайный IV. А если у вас исх. тексты всегда разные, то IV менять каждый раз не обязательно. Но сможете ли вы гарантировать, что исх текст у вас больше не повториться при шифровке? Поэтмоу лучше всегда использовать случайный IV. И его необязательно скрывать.
и ключ и IV являются константами

Нет, не верно. В CBC-режиме случайный IV генерируется перед шифрованием первого блока исходного сообщения, а затем в явном виде сохраняется/передается вместе с шифротекстом, в частности путем конкатенации IV || C, где C — шифротекст. При дешифровании всего шифротекста IV считывается (так как его длина фиксирована) и используется для дешифрования первого блока, т.е.:
если

c[0] = E(k, IV⊕m[0])
, то
m[0] = D(k, c[0])⊕IV
, где E и D — ф-ции шифрования и дешифрования соответственно, m[0] — первый блок открытого текста, c[0] — первый блок шифротекста.


Доказано, что использование неслучайного IV делает блочный шифр неустойчивым к атаке с подобранным открытым текстом (chosen plaintext attack). Более того, неустойчивым к этой атаке считается и шифр, IV которого можно предугадать.

Да IV должен быть случайным особенно в связке с CBC и не повторятся…
IV не секретная информация он передается не шифрованым
>Операции в поле выполняются по модулю m(x). Всего в поле GF(2^8) насчитывается 2^8 = 256 многочленов.
1.В любом расширенном поле кроме многочленов имеется, по меньшей мере, два числа — нейтральные элементы аддитивной и мультипликативной групп поля
2. Поле у Вас не задано. Кроме неприводимого многочлена, необходимо задать еще и примитивный элемент поля. В Вашем тексте я его не нашел.

Как часто нужно генерировать IV?

Sign up to leave a comment.