Защита информации в сетях Wi-Fi: что использовать – WPA2-AES, WPA2-TKIP или и то и другое?
Многие роутеры в качестве опций предоставляют следующие стандарты безопасности: WPA2-PSK (TKIP), WPA2-PSK (AES) и WPA2-PSK (TKIP/AES). Сделаете неправильный выбор – получите более медленную и менее защищенную сеть.
Стандарты WEP (Wired Equivalent Privacy), WPA (Wi-Fi Protected Access) и WPA2 (Wi-Fi Protected Access II), которые будут вам предложены на выбор при настройке параметров безопасности беспроводной сети, представляют собой основные алгоритмы защиты информации. WEP является старейшим из них и наиболее уязвимым, так как за время его использования в нем было обнаружено множество слабых мест. WPA дает более совершенную защиту, но по имеющимся данным он также подвержен взлому. WPA2 – в настоящее время развивающийся стандарт – на текущий момент является самым распространенным вариантом защиты. TKIP (Temporal Key Integrity Protocol) и AES (Advanced Encryption Standard) представляют собой два различных типа шифрования, которые могут применяться в стандарте WPA2. Давайте посмотрим, чем они отличаются и какой из них в наибольшей степени подходит вам.
AES vs. TKIP
TKIP и AES представляют собой два различных стандарта шифрования, которые могут использоваться в сетях Wi-Fi. TKIP – более старый протокол шифрования, введенный в свое время стандартом WPA взамен крайне ненадежного алгоритма WEP. На самом деле TKIP во многом подобен алгоритму шифрования WEP. TKIP уже не считается надежным методом защиты и в настоящее время не рекомендуется. Другими словами, вам не следует его использовать.
AES – более надежный протокол шифрования, введенный стандартом WPA2. AES – это не какой-нибудь унылый, тот или другой стандарт, разработанный специально для сетей Wi-Fi. Это серьезный мировой стандарт шифрования, взятый на вооружение даже правительством США. Например, когда вы зашифровываете жесткий диск с помощью программы TrueCrypt, она может использовать для этого алгоритм шифрования AES. AES является общепризнанным стандартом, обеспечивающим практически полную безопасность, а его возможные слабые места – потенциальная восприимчивость к атакам методом «грубой силы» (для противодействия которым применяются достаточно сложные кодовые фразы) и недостатки защиты, связанные с другими аспектами WPA2.
Усеченный вариант защиты – TKIP, более старый протокол шифрования, используемый стандартом WPA. AES для Wi-Fi – более новое решение в части шифрования, применяемое в новом и безопасном стандарте WPA2. В теории на этом можно было бы закончить. Но на практике, в зависимости от вашего роутера, простого выбора WPA2 может оказаться недостаточно.
Хотя стандарт WPA2 для оптимальной защиты предполагает использование AES, он может использовать и TKIP – там, где требуется обратная совместимость с устройствами предыдущих поколений. При таком раскладе устройства, поддерживающие WPA2, будут подключаться в соответствии с WPA2, а устройства, поддерживающие WPA, будут подключаться в соответствии с WPA. То есть «WPA2» не всегда означает WPA2-AES. Тем не менее, на устройствах без явного указания опций «TKIP» или «AES» WPA2 обычно является синонимом WPA2-AES.
Аббревиатура «PSK» в полном наименовании этих опций расшифровывается как «pre-shared key» – ваша кодовая фраза (ключ шифра). Это отличает персональные стандарты от WPA-Enterprise, в котором используется RADIUS-сервер для выдачи уникальных ключей в больших корпоративных или правительственных сетях Wi-Fi.
Опции безопасности для сети Wi-Fi
- Open (risky): в открытых сетях Wi-Fi нет кодовых фраз. Вам не следует устанавливать эту опцию – серьезно, вы можете дать повод полиции нагрянуть к вам в гости.
- WEP 64 (risky): старый стандарт протокола WEP легко уязвим, и вам не следует его использовать.
- WEP 128 (risky): это тот же WEP, но с увеличенной длиной шифровального ключа. По факту уязвим не менее, чем WEP 64.
- WPA-PSK (TKIP): здесь используется оригинальная версия протокола WPA (по сути – WPA1). Он не вполне безопасен и был заменен на WPA2.
- WPA-PSK (AES): здесь используется оригинальный протокол WPA, где TKIP заменен на более современный стандарт шифрования AES. Этот вариант предлагается как временная мера, но устройства, поддерживающие AES, почти всегда будут поддерживать WPA2, в то время как устройства, которым требуется WPA, почти никогда не будут поддерживать AES. Таким образом, эта опция не имеет большого смысла.
- WPA2-PSK (TKIP): здесь используется современный стандарт WPA2 со старым алгоритмом шифрования TKIP. Этот вариант не безопасен, и его достоинство заключается только в том, что он подходит для старых устройств, которые не поддерживают опцию WPA2-PSK (AES).
- WPA2-PSK (AES): это наиболее употребительная опция безопасности. Здесь используется WPA2, новейший стандарт шифрования для сетей Wi-Fi, и новейший протокол шифрования AES. Вам следует использовать эту опцию. На некоторых устройствах вы увидите опцию под названием просто «WPA2» или «WPA2-PSK», что в большинстве случаев подразумевает использование AES.
- WPAWPA2-PSK (TKIP/AES): некоторые устройства предлагают – и даже рекомендуют – такую смешанную опцию. Данная опция позволяет использовать и WPA, и WPA2 – как с TKIP, так и с AES. Это обеспечивает максимальную совместимость с любыми древними устройствами, которые у вас могут быть, но также дает хакерам возможность проникнуть в вашу сеть путем взлома более уязвимых протоколов WPA и TKIP.
Сертификация WPA2 действительна с 2004 г., в 2006 г. она стала обязательной. Любое устройство с логотипом «Wi-Fi», произведенное после 2006 г., должно поддерживать стандарт шифрования WPA2.
Поскольку ваше устройство с возможностью подключения к сети Wi-Fi скорее всего моложе 11 лет, вы можете чувствовать себя спокойно, просто выбирая опцию WPA2-PSK (AES). Установив эту опцию, вы также сможете проверить работоспособность вашего устройства. Если устройство перестает работать, вы всегда сможете вернуть или обменять его. Хотя, если безопасность имеет для вас большое значение, вы можете просто купить новое устройство, произведенное не ранее 2006 г.
WPA и TKIP замедляют сеть Wi-Fi
Выбираемые в целях совместимости опции WPA и TKIP могут еще и замедлить работу сети Wi-Fi. Многие современные роутеры Wi-Fi, поддерживающие 802.11n или более новые и быстрые стандарты, будут снижать скорость до 54 Мбит/с, если вы установите на них опцию WPA или TKIP, – для обеспечения гарантированной совместимости с гипотетическими старыми устройствами.
Для сравнения, при использовании WPA2 с AES даже стандарт 802.11n поддерживает скорость до 300 Мбит/с, а стандарт 802.11ac предлагает теоретическую максимальную скорость 3,46 Гбит/с при оптимальных (читай: идеальных) условиях.
В большинстве роутеров, как мы уже убедились, список опций обычно включает в себя WEP, WPA (TKIP) и WPA2 (AES) – и, возможно, смешанную опцию режима максимальной совместимости WPA (TKIP) + WPA2 (AES), добавленную с лучшими намерениями.
Если у вас роутер необычного типа, который предлагает WPA2 или вместе с TKIP, или вместе с AES, выбирайте AES. Почти все ваши устройства точно будут с ним работать, к тому же более быстро и более безопасно. AES – простой и рациональный выбор.
Выбор наиболее криптостойкого режима симметричного шифрования с алгоритмом AES-256 (CBC/CTR)
Я на php улучшаю, ранее разработанную мной, систему шифрованных команд, которая является частью системы аутентификации пользователей, суть которой в следующем. 1 Сервер создаёт и отправляет пользователю на email ссылку, в которой содержатся зашифрованные командные данными (data) и вектором инициализации ( IV ). 2 Сервер, при получении этих данных в GET-запросе, расшифровывает данные, проверяет на валидность, и если всё верно (данные соответствуют некой структуре, данные не просрочены, команда и все данные, необходимые для выполнения указанной команды существуют, и ещё некоторые проверки, в зависимости от команды), тогда сервер предполагает, что эти данные отправил именно тот пользователь, на email которого они отправлялись и немедленно выполняет соответствующую команду (регистрация нового пользователя, подтверждение на восстановление пароля, генерация и отправка пользователю нового пароля, подтверждение на изменение email, изменение email). 3 Шифруемые командные данные могут достигать длины примерно 128 символов. Ранее я использовал php-модуль mcrypt $data = mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $salt, $data, MCRYPT_MODE_CBC, $iv); Сейчас хочу использовать php-модуль openssl $data = openssl_encrypt($data, ‘AES-256-CTR’, $salt, 0, $iv); Но вот я не уверен, оптимальный ли я выбрал для этого режим (CTR)? Я много гуглил по режимам симметричного шифрования, на русских рессурсах, так как с английским у меня плохо, и понял лишь, что. 1 ECB лучше вообще не использовать, если длина данных более одного блока (256 бит = 32 символа), а у меня больше. 2 CBC уязвим из-за своей особенности дополнять последний блок. 3 CFB и CTR быстрее, чем CBC и длина зашифрованных данных меньше, и тут нет авто дополнение последнего блока, как и блоков вообще, так как это поточные алгоритмы, но ни слова про криптостойкость и про сравнение по криптостойкости с CBC. 4 Описание и сравнение GCM и XTS я вообще не нащёл. Выполнив код:
$get = openssl_get_cipher_methods(); foreach($get as $key=>$val) echo $key,' = ',$val,' (',openssl_cipher_iv_length($val),')
'; Получил, среди прочего, вот такое:
. 15 = AES-256-CBC (16) 16 = AES-256-CFB (16) 17 = AES-256-CFB1 (16) 18 = AES-256-CFB8 (16) 19 = AES-256-CTR (16) 20 = AES-256-ECB (0) 21 = AES-256-OFB (16) 22 = AES-256-XTS (16) . 98 = aes-256-cbc (16) 99 = aes-256-ccm (12) 100 = aes-256-cfb (16) 101 = aes-256-cfb1 (16) 102 = aes-256-cfb8 (16) 103 = aes-256-ctr (16) 104 = aes-256-ecb (0) 105 = aes-256-gcm (12) 106 = aes-256-ofb (16) 107 = aes-256-xts (16) . 157 = id-aes256-CCM (12) 158 = id-aes256-GCM (12) 159 = id-aes256-wrap (8) . Чем эти 3 группы друг от друга отличаются, но или хотя бы 1-ая от 2-ой? 3-яя, как я догадываюсь, это передача помимо шифрованных данных не шифрованных для аутентификации, но могу и ошибаться.
До сих пор не знаю. :-( Опишите мне, достоинства и недостатки этих методов по сравнению друг с другом акцентируя внимание именно на криптостойкости? Единственные безопасные, которые можно использовать, по рекомендации Нильза Фергюсена (Niels Ferguson), это CBC и CTR. Какой из этих методов мне стоит использовать, причём единственный значимый критерий для меня — это максимальная криптостойкость? Если есть возможность генерировать при каждом шифре безопасную, надёжную, псевдослучайную, уникальную последовательность ( nonce ) для вектора инициализации ( VI ), и передавать его клиенту с шифром, тогда нужно использовать CTR . Он будет безопаснее, короче, быстрее и будет иметь возможность параллельного вычисления. Если нет возможности генерировать при каждом шифре безопасную, надёжную, псевдослучайную, уникальную последовательность ( nonce ) для вектора инициализации ( VI ), и передавать его клиенту с шифром, тогда нужно использовать CBC . Он Более стойкий к соответствующим атакам подбора вектора инициализации, хотя уязвим к подбору последнего блока. Вывод — наиболее безопасно генерировать надёжную nonce для VI и использовать CTR. Чем и как, возможно используя openssl , генерировать вектор инициализации ( IV ) и соль ( salt ). Надёжная, безопасная, псевдослучайная последовательность в PHP генерируется функцией openssl_random_pseudo_bytes(16); . Она прекрасно подходит как для разовой генерации salt , так и для постоянного генерирования nonce для VI . При этом в обоих случаях в обоих алгоритмах её нужно вызывать с параметром 16 , так как и для CBC , и для CTR требуется 16-ти битная nonce . При этом нужно отметить, что функция возвращает бинарные данные, и что бы соль сохранить в текстовую строку нужно закодировать в base64 base64_encode($salt); , а потом, при вызовах openssl_encrypt($data,’AES-256-CTR’,base64_decode($salt),0,$iv); и openssl_decrypt($data,’AES-256-CTR’,base64_decode($salt),0,$iv); , декодировать обратно в бинарные данные base64_decode($salt); . А чтобы передать вектор инициализации клиенту в GET-запросе, нужно после кодирования в base64 ещё заменить символы + и / , например на — и _ соответственно strtr(base64_encode($iv),’+/’,’-_’)); . А получив вектор инициализации от клиента, произвести обратную замену и декодировать вектор инициализации в бинарные данные base64_decode(strtr($_GET[‘iv’],’-_’,’+/’)); . Для более детального изучения вопроса, рекомендую обратиться к англоязычной книге Cryptography Engineering: Design Principles and Practical Applications , написанной Niels Ferguson в марте 2010-ого. ISBN13: 9780470474242 Русскоязычных источников я, к сожалению, не обнаружил, хотя эту книгу я смог найти только тут.
AES шифрование и Android клиент
Как говорится, ничего не предвещало беды. Мобильный клиент потихоньку пилился, кофе стыл, задачки закрывались одна за другой, пока вдруг внезапно не пришло письмо на корпоративную почту:
Срочно внедряем новый функционал. Все необходимые параметры для построения бизнес модели, в целях безопасности, будут передаваться в зашифрованном виде AES/CBC/PKCS5Padding с вектором инициализации AAACCCDDDYYUURRS и ключом шифрования ZZHHYYTTUUHHGGRR. Пример зашифрованных данных:
p+oJjsGEULNSptP5Sj1BM5w65hMjkqzahORd8ybIkqyJD0V/608c1tYuKIvDLUIa
RQ9jQ6+EwbyMFjlMa6xuEnxOx4sez001hd3NsLO7p00XoTqAvi9zwUBII+
nPphP6Zr0P4icvODpmhlmRILgSBsUf1H/3VN1lNXjo4LTa
GxLqW3VSg9iV9yFq4VMWqsRF
Попытки быстрого поиска решения выдали кучу неработающих примеров показали, что задача выходит за рамки привычной верстки layout’ов и написания Presenter’ов и требует изучения доков и чтения мануалов. Отличная возможность изучить что-то новое и обогатить свой опыт.
Но для начала, давайте разберемся, что же это такое — шифрование и зачем оно вообще нужно.
Немного теории об AES шифровании
Advanced Encryption Standard (AES) — симметричный алгоритм блочного шифрования, принятый правительством США на основе результатов проведенного конкурса в качестве стандарта шифрования и заменивший собой менее надежный алгоритм Data Encryption Standard (DES). Утвержденный алгоритм в качестве единого стандарта шифрования стал повсеместно применяться для защиты электронных данных.
Основу алгоритма составляют замены, подстановки и линейные преобразования, каждое из которых выполняется блоками по 128 бит (цифры со значениями от 0 или 1), являющихся основой структуры входных и выходных данных, поэтому он и носит называние блочного шифра. Повторение операций происходит неоднократно и в процессе каждой итерации (раунда) вычисляется уникальный ключ на основе ключа шифрования и встраивается в дальнейшие вычисления.
Криптографический ключ для алгоритма AES представляет собой последовательность из 128, 192 или 256 бит. Другие параметры входных и выходных данных и криптографического ключа не допускается стандартом AES.
Надежность шифрования обеспечивается тем, что изменение даже одного блока влечет за собой изменение последующих блоков и полное изменение конечных данных на выходе.
Данный подход обеспечивает высокую надежность алгоритма, в которой можно убедиться, рассмотрев следующий несложный пример:
Пример расчета времени на взлом шифротекста
Таблица 1: Зависимость количества комбинаций от длины ключа
| Размер ключа | Возможное количество комбинаций |
| 1 бит | 2 |
| 2 бита | 4 |
| 4 бита | 16 |
| 8 бит | 256 |
| 16 бит | 65536 |
| 32 бита | 4.2 * 10^9 |
| 56 бит (DES Алгоритм) | 7.2 * 10^16 |
| 64 бита | 1.8 * 10^19 |
| 128 бит (AES алогритм) | 3.4 * 10^38 |
| 192 бита (AES алогритм) | 6.2 * 10^57 |
| 256 бит (AES алогритм) | 1.1 * 10^77 |
Самый быстрый суперкомпьютер: 10,51 ПетаФлопс = 10,51 х 10^15 Флопс (операций с плавающей точкой в секунду)
Пусть примерное количество операций в секунду, необходимых для проверки комбинации оптимистично будет: 1000
Количество проверок комбинации в секунду = (10,51 х 10^15) / 1000 = 10,51 х 10^12
Количество секунд в течение одного года = 365 х 24 х 60 х 60 = 31536000
Количество лет, чтобы взломать AES с 128-битным ключом = (3,4 х 10^38) / [(10,51 х 1012) х 31536000] = (0,323 х 10^26) / 31536000 = 1,02 х 10^18 = 1 миллиард миллиардов лет.
Подробное описание алгоритма на английском языке: ADVANCED ENCRYPTION STANDARD
Также можно почитать эту замечательную статью: Как устроен AES
Вектор инициализации
Initialization vector (IV) — вектор инициализации, представляет собой произвольное число, которое может быть использовано вместе с секретным ключом для шифрования данных.
Использование IV предотвращает повторение шифрования данных, что делает процесс взлома более трудным для хакера с помощью атаки по словарю, в попытках найти шаблоны и сломать шифр. Например, последовательность может появиться два раза и более в теле сообщения. Если повторяются последовательности в зашифрованных данных, злоумышленник может предположить, что соответствующие последовательности в сообщении также были идентичны. IV предотвращает появление соответствующих повторяющихся последовательностей символов в зашифрованном тексте.
Математическая основа
Для вспоминания изучения математической основы, воспользуемся материалом из документации к алгоритму ADVANCED ENCRYPTION STANDARD, а также этим хорошим материалом на русском языке: Общее описание криптоалгоритма AES
Соответственно, для описания алгоритма используется конечное поле Галуа GF(2^8), построенное как расширение поля GF(2) = по модулю неприводимого многочлена m(x) = x^8 + x^4 + x^3 + x + 1. Элементами поля GF(2^8) являются многочлены вида
b_7 · x^7 + b_6 · x^6 + b_5 · x^5 + b_4 · x^4 + b_3 · x^3 + b_2 · x^2 + b_1 · x + b_0
Операции в поле выполняются по модулю m(x). Всего в поле GF(2^8) насчитывается 2^8 = 256 многочленов.
- Сложение байт можно выполнить любым из трех способов:
- представить байты битовыми многочленами и сложить их по обычному правилу суммирования многочленов с последующим приведением коэффициентов суммы по модулю 2 (операция XOR над коэффициентами);
- суммировать по модулю 2 соответствующие биты в байтах;
- сложить байты в шестнадцатеричной системе исчисления.
- Умножение байт выполняется с помощью представления их
многочленами и перемножения по обычным алгебраическим правилам.
Полученное произведение необходимо привести по модулю многочлена m(x) = x^8 + x^4 + x^3 + x + 1 (результат приведения равен остатку от деления произведения на m(x)) - Для любого ненулевого битового многочлена b(x) в поле GF(2^8)
существует многочлен b^-1(x), обратный к нему по
умножению, т.е. b(x) · b^-1(x) = 1 mod m(x)
Таким образом, в этих многочленах в роли коэффициентов при неизвестных задействованы байты вместо бит. Далее эти многочлены будем представлять в форме слова [a_0, a_1, a_2, a_3]. В стандарте AES при умножении многочленов вида (1) используется приведение по модулю другого многочлена x^4 + 1.
- Сложение
a(x) + b(x) = (a_3 ⊕ b_3) x^3 + (a_2 ⊕ b_2) x^2 + (a_1 ⊕ b_1) x + (a_0 ⊕ b_0) - Умножение
Для представления результата четырехбайтовым словом, берется результат по модулю многочлена степени не более 4. Авторы шифра выбрали для этой цели многочлен x^4+1, для которого справедливо x_i mod(x^4 + 1) ≡ x_i mod 4. Дальнейшее приведение по модулю x^4+1 позволяет получить результат в виде:
Параметры шифрования
Ну что есть AES и вектор инициализации стало понятно. Теперь попытаемся понять и остальные слова в строке AES/CBC/PKCS5Padding
Cipher block chaining (CBC) — режим сцепления блоков шифротекста — один из режимов шифрования для симметричного блочного шифра с использованием механизма обратной связи. Каждый блок открытого текста (кроме первого) побитово складывается по модулю 2 с предыдущим результатом. Одна ошибка в бите блока шифротекста влияет на расшифровку всех последующих блоков. Перестройка порядка блоков зашифрованного текста вызывает повреждения результата дешифрования.
Другой параметр PKCS5Padding, указывает на то, каким образом должны обрабатываться неполные блоки. При использовании одного из общих алгоритмов заполнения, нужно включить размер блока в зашифрованные данные, гарантируя то, что когда вы попытаетесь расшифровать зашифрованное сообщение, вы получите нужное количество байт.
Для работоспособности всех параметров шифрования AES, каждая реализация платформы Java должна поддерживать следующие стандартные алгоритмы шифрования с ключевыми размерами (в скобках):
Standard Cipher transformations
- AES/CBC/NoPadding (128)
- AES/CBC/PKCS5Padding (128)
- AES/ECB/NoPadding (128)
- AES/ECB/PKCS5Padding (128)
- DES/CBC/NoPadding (56)
- DES/CBC/PKCS5Padding (56)
- DES/ECB/NoPadding (56)
- DES/ECB/PKCS5Padding (56)
- DESede/CBC/NoPadding (168)
- DESede/CBC/PKCS5Padding (168)
- DESede/ECB/NoPadding (168)
- DESede/ECB/PKCS5Padding (168)
- RSA/ECB/PKCS1Padding (1024, 2048)
- RSA/ECB/OAEPWithSHA-1AndMGF1Padding (1024, 2048)
- RSA/ECB/OAEPWithSHA-256AndMGF1Padding (1024, 2048)
Ларчик просто открывался
Разобравшись с теорией, можно приступать к реализации самого алгоритма расшифровки серверного сообщения.
В отличии от стандартного набора JDK, для работы нам потребуется android.util.Base64 для преобразования строки:
import android.util.Base64; import java.security.GeneralSecurityException; import javax.crypto.Cipher; import javax.crypto.spec.IvParameterSpec; import javax.crypto.spec.SecretKeySpec; public static String decrypt(String key, String iv, String encrypted) throws GeneralSecurityException < //Преобразование входных данных в массивы байт final byte[] keyBytes = key.getBytes(); final byte[] ivBytes = iv.getBytes(); final byte[] encryptedBytes = Base64.decode(encrypted, Base64.DEFAULT); //Инициализация и задание параметров расшифровки SecretKeySpec secretKeySpec = new SecretKeySpec(keyBytes, "AES"); Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding"); cipher.init(Cipher.DECRYPT_MODE, secretKeySpec, new IvParameterSpec(ivBytes)); //Расшифровка final byte[] resultBytes = cipher.doFinal(encryptedBytes); return new String(resultBytes); >Стоит также принимать во внимание, что размер вектора инициализации должен быть 16 байт (128 — бит). Это связано с тем, что стандарт шифрования AES включает в себя три типа блочных шифров: AES — 128, AES — 192 и AES — 256. Каждый из этих шифров имеет 128 — битный размер блока, с размерами ключа 128, 192 и 256 бит соответственно и принимая во внимание то, что для всех типов блочного шифра, вектор инициализации такого же размера, как и размер блока шифра мы получаем, что вектор инициализации всегда имеет 128 — битный размер.
В противном случае, даже если мы попытаемся использовать вектор другого размера, то шифротекст не будет расшифрован и мы получим следующее исключение:
java.security.InvalidAlgorithmParameterException: Wrong IV length: must be 16 bytes long Результат
Как видно из реализации, решение оказалось достаточно простым и тривиальным в контексте задач подобного рода. Но тем не менее, иногда бывает очень полезно покопаться в доках и реализовать то, что встречается не так уж и часто в трудовых буднях Android разработчика.
Для самых любознательных — под спойлером то, что было зашифровано в сообщении:
ответ к задачке
< "items": [ < "name": "star", "color": "green", "id": 21 >, < "name": "dog", "color": "brown", "id": 43 >], "lucky_item_id": 43 > Более надежный чем aes
Привет.
Насколько я знаю по производительности данные алгоритмы шифрования располагаются так:
1) RC4
2) AES-128
3) 3DES
А по надежности, защищенности шифрования какой порядок будет? Я здесь имею ввиду всё и найденные потенциальные уязвимости и чисто теоретические основания.
Re: RC4, 3DES, AES-128 что надежнее?
| От: | Alyash77 |
| Дата: | 19.12.13 15:46 |
| Оценка: |
N>А по надежности, защищенности шифрования какой порядок будет? Я здесь имею ввиду всё и найденные потенциальные уязвимости и чисто теоретические основания.
Чисто практический вопрос — что Вас заставляет использовать именно эти алгоритмы шифрования? Или интерес сугубо академический?
Вот тут немного теории и исследований по вашему вопросу (там ссылок много на научные работы):
http://www.cl.cam.ac.uk/~rnc1/brute.html
Re: RC4, 3DES, AES-128 что надежнее?
| От: | BlackEric | http://black-eric.lj.ru |
| Дата: | 19.12.13 15:47 | |
| Оценка: | +1 | |
Здравствуйте, neokoder, Вы писали:
N>Привет.
N>Насколько я знаю по производительности данные алгоритмы шифрования располагаются так:
N>1) RC4
N>2) AES-128
N>3) 3DES
N>А по надежности, защищенности шифрования какой порядок будет? Я здесь имею ввиду всё и найденные потенциальные уязвимости и чисто теоретические основания.
А от чего защищаться будем?
Лучший, пожалуй, AES-128.
RC4- считается устаревшим. 3DES также выходит из употребления постепенно заменяясь AES. Также можно рассмотреть AES-192/256 с большей длиной ключа.
Re[2]: RC4, 3DES, AES-128 что надежнее?
| От: | neokoder |
| Дата: | 19.12.13 15:59 |
| Оценка: |
Здравствуйте, Alyash77, Вы писали:
A>Чисто практический вопрос — что Вас заставляет использовать именно эти алгоритмы шифрования? Или интерес сугубо академический?
Интерес чисто практический. Заставляют меня httpS web-серверы, которые очень любят именно их из соображений производительности.
Всем известный стандарт AES-256 они не очень любят
Re[2]: RC4, 3DES, AES-128 что надежнее?
| От: | neokoder |
| Дата: | 19.12.13 16:05 |
| Оценка: |
Здравствуйте, BlackEric, Вы писали:
BE>А от чего защищаться будем?
Ответил чуть выше.
BE>Лучший, пожалуй, AES-128.
BE>RC4- считается устаревшим. 3DES также выходит из употребления постепенно заменяясь AES.
Тут дело в чём, в 3DES длина ключа 168, но эффективная 112, отсюда и варианты. Я не спец в криптографии, поэтому спрашиваю.
Re[2]: RC4, 3DES, AES-128 что надежнее?
| От: | neokoder |
| Дата: | 19.12.13 16:09 |
| Оценка: |
Здравствуйте, Alyash77, Вы писали:
A>Чисто практический вопрос — что Вас заставляет использовать именно эти алгоритмы шифрования? Или интерес сугубо академический?
Почему многие серверы выбирают комплекты шифров с RC4 я ещё могу понять — производительность. Но вот почему 3DES вместо AES-256 и тем более AES-128 понять не могу.
Я не уверен что AES-256 сильно медленнее 3DES, а если ещё учесть вариант аппаратной реализации, то точно быстрее.
Re[3]: RC4, 3DES, AES-128 что надежнее?
| От: | Anton Batenev | https://github.com/abbat |
| Дата: | 19.12.13 16:24 | |
| Оценка: |
Здравствуйте, neokoder, Вы писали:
n> Интерес чисто практический. Заставляют меня httpS web-серверы, которые очень любят именно их из соображений производительности.
Веб-сервера любят то, что им скажут. А для HTTPS им обычно говорят что-то типа:
RC4:HIGH:!aNULL:!MD5:!CAMELLIA;RC4 ставится на первое место из за BEAST. Надеюсь через пару лет необходимость в нем останется только для очень старых браузеров, которые ССЗБ.
n> Всем известный стандарт AES-256 они не очень любят
Re[3]: RC4, 3DES, AES-128 что надежнее?
| От: | Alyash77 |
| Дата: | 19.12.13 16:25 |
| Оценка: |
N>Почему многие серверы выбирают комплекты шифров с RC4 я ещё могу понять — производительность.
Сомнительно — скорее совместимость или банальная лень админов чтобы отключить в конфиге старые алгоритмы.
N>Но вот почему 3DES вместо AES-256 и тем более AES-128 понять не могу.
та же лень и совместимость. до какого-то момента AES-256 вообще был запрещен к экспорту из США если я правильно все помню.
N>Я не уверен что AES-256 сильно медленнее 3DES, а если ещё учесть вариант аппаратной реализации, то точно быстрее.
Даже аппаратной реализации не надо в 90% случаев — хотя в корпорациях часто что-то типа F5 используют чтобы разгрузить сервера приложений.
В общем случае использовать что-то ниже чем AES-128 смысла не имеет. Все новые браузеры его нормально поддерживают.
Re[4]: RC4, 3DES, AES-128 что надежнее?
| От: | Cyberax |
| Дата: | 19.12.13 16:38 |
| Оценка: |
Здравствуйте, Alyash77, Вы писали:
N>>Но вот почему 3DES вместо AES-256 и тем более AES-128 понять не могу.
A>та же лень и совместимость. до какого-то момента AES-256 вообще был запрещен к экспорту из США если я правильно все помню.
Учитывая, что AES256 в девичестве назывался Rijndael и был разработан в Бельгии — интересно как это могло бы произойти.
Запрет на экспорт криптографии был отменён ещё при Клинтоне.
Sapienti sat!
Re[4]: RC4, 3DES, AES-128 что надежнее?
| От: | neokoder |
| Дата: | 19.12.13 16:38 |
| Оценка: |
Здравствуйте, Anton Batenev, Вы писали:
AB>Веб-сервера любят то, что им скажут. А для HTTPS им обычно говорят что-то типа:
Так знаю, вот и вопрос почему на серьёзном httpS сервере настраивают openssl или прочее ПО странным образом? Никого не хочу обвинять но есть такой момент!
AB>RC4 ставится на первое место из за BEAST. Надеюсь через пару лет необходимость в нем останется только для очень старых браузеров, которые ССЗБ.
А подробнее можно? О BEAST слышал, сейчас ещё почитаю, но вопрос такой пока: что RC4 как потоковый шифр неуязвим к BEAST? Ну даже если и так, разве может быть только это основанием для того чтобы выбирать такой уcтаревший и слабый шифр?
Я почему то считаю такой выбор обусловлен прежде всего скоростью его работы, он просто самый быстрый.
AB>Это еще почему?
Ну вот смотрите пример.
Сайт: https://click.alfabank.ru
Браузер: Chrome(с отключенным RC4)
Протокол: TLS 1.2
3 «одинаковых» комплекта шифра(остальные не привожу ради примера) в ClientHello в приоритетном порядке:
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)
Сервер Альфа-Банка выбирает последний. Причина?
И это при том что там ещё куча других вариантов с Forward Secrecy, естественно более надежных.
Re[4]: RC4, 3DES, AES-128 что надежнее?
| От: | neokoder |
| Дата: | 19.12.13 16:43 |
| Оценка: |
Здравствуйте, Alyash77, Вы писали:
N>>Почему многие серверы выбирают комплекты шифров с RC4 я ещё могу понять — производительность.
A>Сомнительно — скорее совместимость или банальная лень админов чтобы отключить в конфиге старые алгоритмы.
N>>Но вот почему 3DES вместо AES-256 и тем более AES-128 понять не могу.
A>та же лень и совместимость. до какого-то момента AES-256 вообще был запрещен к экспорту из США если я правильно все помню.
N>>Я не уверен что AES-256 сильно медленнее 3DES, а если ещё учесть вариант аппаратной реализации, то точно быстрее.
A>Даже аппаратной реализации не надо в 90% случаев — хотя в корпорациях часто что-то типа F5 используют чтобы разгрузить сервера приложений.
Неужели всё так хреново с админами и спецами по безопасности даже у банков? Вы случайно не из собственного опыта?
A>В общем случае использовать что-то ниже чем AES-128 смысла не имеет. Все новые браузеры его нормально поддерживают.
Дело не в браузерах а серверах. Браузер то поддерживает, да и сервер тоже, но выбирает сервер.
Re[5]: RC4, 3DES, AES-128 что надежнее?
| От: | Alyash77 |
| Дата: | 19.12.13 17:00 |
| Оценка: |
C>Учитывая, что AES256 в девичестве назывался Rijndael и был разработан в Бельгии — интересно как это могло бы произойти.
ХЗ — деталей не помню — разве что в IE долгое время небыло поддержки каких-то алгоритмов. Но меня это сильно не задело.
C>Запрет на экспорт криптографии был отменён ещё при Клинтоне.
Это Вы корпоративным админам скажите — а то они не всегда в курсе последних событий
Re[5]: RC4, 3DES, AES-128 что надежнее?
| От: | Alyash77 |
| Дата: | 19.12.13 17:02 |
| Оценка: |
N>Неужели всё так хреново с админами и спецами по безопасности даже у банков? Вы случайно не из собственного опыта?
Из собственного в том числе только не банковского а корпоративного. Там артефакты типа кода на asp или софт работающий исключительно пот tomcat 2.0 найти запросто. Даже проприетарные реализации криптографии если поискать хорошо. Что уж о конфигах вебсерверов и списках https протоколов говорить если те конфиги последний раз в прошлом веке правились
N>Дело не в браузерах а серверах. Браузер то поддерживает, да и сервер тоже, но выбирает сервер.
Админам пофигу — и так работает. Чего его менять-то? пока какой-то аудит носом не ткнет — не пошевелятся.
Re[4]: RC4, 3DES, AES-128 что надежнее?
| От: | neokoder |
| Дата: | 19.12.13 17:09 |
| Оценка: |
AB>RC4 ставится на первое место из за BEAST. Надеюсь через пару лет необходимость в нем останется только для очень старых браузеров, которые ССЗБ.
Ну вот уточнил по поводу BEAST.
Уязвим к ней только TLS 1.0 и CBC-mode. Протоколы TLS 1.1 TLS 1.2 не уязвимы к ней. Вот мой пример с тем же Альфа Банком и Chrome, если включить RC4 он будет выбирать RC4 даже по TLS 1.2 Причина?
Кроме того сейчас есть же уже GCM-mode для AES и соответсвующие комплекты шифров. Почему их сервера не выбирают?
Re[4]: RC4, 3DES, AES-128 что надежнее?
| От: | neokoder |
| Дата: | 19.12.13 18:45 |
| Оценка: |
Ну что никто так и не скажет своё мнение по поводу этих алгоритмов?
Как расположатся по надежности в плане шифрования и устойчивости к атакам?
Re[5]: RC4, 3DES, AES-128 что надежнее?
| От: | Cyberax |
| Дата: | 19.12.13 18:56 |
| Оценка: |
Здравствуйте, neokoder, Вы писали:
N>Уязвим к ней только TLS 1.0 и CBC-mode. Протоколы TLS 1.1 TLS 1.2 не уязвимы к ней. Вот мой пример с тем же Альфа Банком и Chrome, если включить RC4 он будет выбирать RC4 даже по TLS 1.2 Причина?
Некоторые клиенты не слишком правильно работают с более новыми шифрами, а банки очень консервативные.
Sapienti sat!
Re: RC4, 3DES, AES-128 что надежнее?
| От: | Pzz | https://github.com/alexpevzner |
| Дата: | 19.12.13 19:15 | |
| Оценка: |
Здравствуйте, neokoder, Вы писали:
N>А по надежности, защищенности шифрования какой порядок будет? Я здесь имею ввиду всё и найденные потенциальные уязвимости и чисто теоретические основания.
Это неправильный вопрос. Ломают в самом уязвимом месте. А самым уязвимым местом обычно является не шифр, как таковой, а способ его применения.
При правильном применении все три шифра, которые вы перечислели, считаются достаточно надежными. 3DES ничем не лучше (видимо, немного хуже), чем AES, но существенно более вычислительно тяжелый, поэтому нет смысла применять его в новых разработках. RC4 очень хорошо исследован, и известны его определенные уязвимости, однако при правильном применении на его основе можно получить вполне надежную криптографию.
Re[5]: RC4, 3DES, AES-128 что надежнее?
| От: | Anton Batenev | https://github.com/abbat |
| Дата: | 19.12.13 19:20 | |
| Оценка: |
Здравствуйте, neokoder, Вы писали:
n> Ну вот уточнил по поводу BEAST.
n> Уязвим к ней только TLS 1.0 и CBC-mode. Протоколы TLS 1.1 TLS 1.2 не уязвимы к ней. Вот мой пример с тем же Альфа Банком и Chrome, если включить RC4 он будет выбирать RC4 даже по TLS 1.2 Причина?
Приоритет задается на стороне сервера для всех версий TLS, браузер выбирает первое совпадение из поддерживаемых им и сервером (а это и будет RC4, т.к. на стороне сервера он идет первым).
n> Кроме того сейчас есть же уже GCM-mode для AES и соответсвующие комплекты шифров. Почему их сервера не выбирают?
Это, если не подводит память, TLS 1.2, а его поддерживают далеко не все (например, браузер FF не поддерживает TLS1.1/1.2, Chrome начал поддерживать 1.2 только недавно). Т.е. нам приходится поддерживать TLS 1.0 для того, чтобы работало у всех, а раз 1.0, то можем использовать только RC4.
P.S. В подавляющем большинстве случаев https на серверах настраивается по принципу «абы работало» и используемый комплект шифров зависит от того, какую статью и какой давности прочитал настройщик на хабре / лоре, по этому делать предположения о выборе по скорости работы или стойкости шифра здесь нельзя.
Re[6]: RC4, 3DES, AES-128 что надежнее?
| От: | neokoder |
| Дата: | 19.12.13 19:20 |
| Оценка: |
C>Некоторые клиенты не слишком правильно работают с более новыми шифрами, а банки очень консервативные.
Так это программисты и админы консервативных банков не слишком умело работают в области безопасности. И их можно понять только с выбором RC4, если мало серверов и надо снизить нагрузку.
Обычный пользователь ничего не меняет в настройках браузера и сервер выбирает всё что ему нужно, обычно дохлый старый алгоритм .
А те некоторые клиенты, которые хотят нормальную безопасность делают всё правильно. Жаль что решающее слово за сервером банка.
Да и дело не только в банках. Есть много ещё httpS-серверов работающих по такому же принципу.
Re[2]: RC4, 3DES, AES-128 что надежнее?
| От: | neokoder |
| Дата: | 19.12.13 19:28 |
| Оценка: |
Здравствуйте, Pzz, Вы писали:
N>>А по надежности, защищенности шифрования какой порядок будет? Я здесь имею ввиду всё и найденные потенциальные уязвимости и чисто теоретические основания.
Pzz>Это неправильный вопрос. Ломают в самом уязвимом месте. А самым уязвимым местом обычно является не шифр, как таковой, а способ его применения.
Какая разница? Если применяется, точнее выбирается для защищенного соединения этот шифр, то о нём и речь.
Pzz>При правильном применении все три шифра, которые вы перечислели, считаются достаточно надежными. 3DES ничем не лучше (видимо, немного хуже), чем AES, но существенно более вычислительно тяжелый, поэтому нет смысла применять его в новых разработках. RC4 очень хорошо исследован, и известны его определенные уязвимости, однако при правильном применении на его основе можно получить вполне надежную криптографию.
Вот, вот и если настройками сервера выбран приоритет 3DES перед AES-128 это как характеризует программистов и админов?
А что по поводу сравнения RC4-128 и 3DES скажите?