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