Безопасно ли шифрование RIJNDAEL для использования с небольшим количеством текста, предоставленного пользователям?

Question

Я подумываю о том, чтобы переключить на хранение данных сеанса в зашифрованных файлах cookie, а не на моем сервере. Хотя это приведет к увеличению полосы пропускания, используемой для каждого запроса, это позволит сэкономить дополнительную нагрузку на базу данных и пространство для хранения.

Во всяком случае, я планирую шифрования содержимого печенья с использованием RIJNDAEL 256.

function encrypt($text, $key) 
{ 
    return mcrypt_encrypt(MCRYPT_RIJNDAEL_256,$key,$text,MCRYPT_MODE_ECB,mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256,MCRYPT_MODE_ECB),MCRYPT_RAND)); 
} 

, который при использовании будет производить что-то вроде этого (в кодировке base64 для отображения)

print base64_encode(encrypt('text', 'key')); 

7s6RyMaYd4yAibXZJ3C8EuBtB4F0qfJ31xu1tXm8Xvw= 

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

Есть ли способ проверить оценочные времена крекинга по отношению к используемым параметрам? Или существует стандартная мера времени по отношению к размеру используемого текста или ключа?

Я слышал, как кто-то сказал, что ключи должны превышать 256 бит, чтобы быть достаточно безопасными для использования с RIJNDAEL. Мне также интересно, должна ли длина зашифрованного текста быть определенной длиной, чтобы не раздавать ключ.

Данные, как правило, около 200 символов

a:3{s:7:"user_id";i:345;s:5:"token";s:32:"0c4a14547ad221a5d877c2509b887ee6";s:4:"lang";s:2:"en";} 

Так это безопасно?

Answer 1

Избегайте использования ЕЦБ. Он может раскрывать информацию о том, что зашифровано. Любые два блока с одним и тем же открытым текстом будут иметь одинаковый зашифрованный текст. CBC избежал бы этого, но требует, чтобы IV был сгенерирован или сохранен.

Избегайте просто сохранять ключ и IV. Создайте 256-битный мастер-ключ, используя криптографически сильный генератор случайных чисел и сохраните это в вашем приложении где-нибудь в безопасности. Используйте это для генерации ключей сеанса для использования в шифровании. IV можно получить из ключа сеанса. При генерации ключа сеанса включаются все доступные данные, которые могут использоваться для сужения сферы действия ключа сеанса. (например.включают область действия cookie, адрес удаленного хоста, случайный сигнал, сохраненный с зашифрованными данными, и/или идентификатор пользователя, если он не находится в зашифрованных данных)

В зависимости от того, как данные должны использоваться, может включать MAC. ECB и CBC не предназначены для обнаружения каких-либо изменений в зашифрованном тексте, и такие изменения приводят к мусору в виде открытого текста. Возможно, вы захотите включить HMAC с зашифрованными данными, чтобы вы могли аутентифицировать его, прежде чем принимать его как канон. Ключ HMAC сеанса должен быть выведен из ключа шифрования сеанса. Кроме того, вы можете использовать режим PCBC. PCBC был сделан для обнаружения изменений в зашифрованном тексте, но его способность делать это ограничена размером заполнения, ведь это зависит от данных, которые зашифрованы, и не все криптографические API-интерфейсы будут иметь его в качестве опции.

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

В летнее время защита ключа - это только кончик ледяного покрова.

Answer 2

Rijndael был переименован в AES. Да, это безопасно использовать.

Тем не менее, вы должны тщательно рассмотреть, что вы положили в файл cookie. Это зависит от того, что у вас есть на складе в вашей системе, но вы можете просто выбрать случайное число (например, 64-разрядное число) и сохранить его в файле cookie. В вашей серверной системе вы сохраните запись о том, с кем был связан номер, и другие сведения. Это позволяет избежать шифрования вообще. Вы используете другие данные для проверки (насколько это может быть подтверждено), был ли cookie отправлен обратно из браузера, к которому вы его первоначально отправили.

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

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

Answer 3

AES-128 должно быть более чем достаточно, без необходимости использования более длинных клавиш - если клавиша выбрана случайным образом.

Однако есть и другие проблемы. Во-первых, вы не должны использовать ECB. С ECB данный 128-битный блок открытого текста всегда сопоставляется с тем же 128-битным зашифрованным текстом, если ключ тот же. Это означает, что противники могут хирургически модифицировать шифротекст, вводящий различные блоки, для которых они знают соответствующий зашифрованный текст. Например, они могут смешивать данные двух разных пользователей. В других режимах, например, CBC отлично, зашифрованный текст также зависит от IV (вектор инициализации), который должен отличаться при каждом выполнении алгоритма. Таким образом, тот же самый открытый текст зашифровывается по-разному каждый раз, и противник не может получить никакого преимущества. Вам также нужно сохранить IV где-нибудь с зашифрованным текстом, не нужно его защищать. Всякий раз, когда вероятность повторного использования одного и того же IV становится не пренебрежимо малой, вы также должны изменить ключ.

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

Answer 4

Если вы используете длинный ключ, я бы сказал, что ключ был довольно безопасным. Некоторые вещи, которые нужно беспокоиться:

Вы выгружаете хранилище данных клиенту. НИКОГДА НЕ ХОТИТЕ КЛИЕНТА. Это не значит, что вы не можете этого сделать, просто вам нужно либо обрабатывать данные в cookie как ненадежные (не принимайте никаких решений более серьезно, чем «тема», чтобы показать пользователя на его основе) или предоставить для проверки достоверности данных.

Некоторые примеры того, как проверка данных будет:

• включают соль (так что люди с тем же данные сессии не получают тот же печенье) и
• контрольную сумму (так что тот, кто меняет хотя бы один кусочек файла cookie, делает его бесполезным).

Answer 5

Да Rijndael (AES) безопасен, однако ваша реализация далека от безопасности. Есть две нерешенные проблемы с вашей реализацией. Использование режима ECB и вашего IV является статической переменной, которая будет использоваться для всех сообщений. An IV must always be a Cryptographic Nonce. Ваш код находится в явном нарушении CWE-329.

режим ECB не следует использовать, необходимо использовать режим CBC, и это почему:

Оригинал:

Зашифрованные с ЕЦБ режиме:

Зашифрованные с использованием режима CBC: