Comments 22
Особенно это актуально на фоне 256-и более битной криптографии. Кстати, передать 8 байт не более сложно, чем 5.
8 байт — это 64 бита.
Но на разработку средств передачи/хранения информации (а также распространение, обслуживание и предоставление услуг) с 5-ю байтами (7-ю в случае ассимиляторного шифрования) точно не нужна лицензия ФСБ, а вот с 8-ю и более начинаются нюансы, например может или нет конечный пользователь изменить подсистему шифрования в продукте, особенно интересно это в случае открытых кодов — с первого взгляда даже распространение, не говоря уж о разработке, на территории РФ ПО (включая ОС)с открытыми кодами, которые пользователь может изменить/заменить, и содержащие средства шифрования и/или работы с ЭЦП должно лицензироваться. С ПО, поставляемым в бинарном виде, немного проще, хотя кто знает как ФСБ может толковать «криптографические возможности которых не могут быть изменены пользователями» — если пользователь вооружится декомпилятором, отладчиком и т. п., то теоретически получается может.
Я правильно понял, что просто в общих словах рассказали о разработанном и реализованной вами протоколе? Спецификация или реализация не открыты?
Прошу прощения, а в чём отличие от CRAM?
Тем что тут односторонний протокол, и поэтому проверку на то что сервер автентичный убрали ;).
где же протокол односторонний? или Вы имеете в виду один unique challenge?
Актуальные данные судя по всему шлются тока в одну сторону. Мне кажется это стало причиной того что валидируется тока клиент на сервере. Это тока мои мысли. Давайте дождемся автора, мне тож интересно.
Не совсем.
До истечения времени T, мы можем безопасно пересылать данные в обе стороны. Однако, как я и написал в топике, требуется чтобы эти данные теряли актуальность после истечения срока.
До истечения времени T, мы можем безопасно пересылать данные в обе стороны. Однако, как я и написал в топике, требуется чтобы эти данные теряли актуальность после истечения срока.
В CRAM случайное число передается в открытом виде, в MAuth — в зашифрованном. Задача взлома зашифрованного случайного числа, при совпадении его длины и длины блока шифрования, математически неразрешима.
Мен-ин-мидл, судя по всему, может свободно быть сервером. И он настолько долго и нудно может быть сервером, да еще и знающим Ns, что это потенциально может стать проблемой.
Сначала можно прослушивать канал, узнать сессионный ключ, а также сообщения {Ns}Kcs, {K'cs}Kcs. После чего, при следующей попылке создения соединения, стать человеком посередине и отправить клиенту не новый {Ns}Kcs от сервера, а старый. После этого клиент отправит нам {K'cs}Kcs и у нас опять тот же самый сессионный ключ, читаем-пишем что хотим.
Да, забыл сказать, что для этого надо знать какое-либо одно сообщение, по нему взломать сессионный ключ, и Kcs не должен меняться.
Браво! Вы нашли уязвимость! )) Не используя взаимную аутентификацию, описанную вами ситуацию не разрешить.
Правда тут есть пара принципиальных моментов:
1. Описанный вами способ не позволяет получить Kcs;
2. Это больше похоже на вредительство, так как, согласитесь, наша задача как злоумышленника захватить контроль над объектом управления, а ваш «взлом» этого сделать не позволяет.
Правда тут есть пара принципиальных моментов:
1. Описанный вами способ не позволяет получить Kcs;
2. Это больше похоже на вредительство, так как, согласитесь, наша задача как злоумышленника захватить контроль над объектом управления, а ваш «взлом» этого сделать не позволяет.
Sign up to leave a comment.
«Вторая жизнь 40-битного ключа шифрования»