Сразу хотелось бы оговориться, что под криптопротоколом понимается протокол "высокого" уровня с использованием различных криптографических операций. Например, таковым является протокол Нидхема-Шрёдера. Исходные данные: есть клиент и сервер, задача которых действовать (общаться друг с другом) в соответствии с каким-либо криптопротоколом. Что бы хотелось сделать: реализовать ПО для клиента и сервера так, чтобы при смене криптопотокола не требовалась перекомпиляция программ. Т.е. считается, что описание протокола (Клиент отправляет Серверу такую-то тему, Сервер другую) хранится в каком-либо конфигурационном файле. Отсюда созрел вопрос: Как оптимальным образом задать криптопротокол в файле, чтобы были справедливы следующие условия: 1. Человек, открыв в текстовом редакторе конфигурационный файл мог легко понять кто что конкретно отправляет. Т.е. описание должно быть понятным человеку. 2. Программный разбор записанной инфы в конфигурационном файле должен быть простым, например, чтобы работал метод рекурсивного спуска или около того. Таким образом хочется облегчить жизнь программисту и сделать его код более приятным. 3. (Опционально) Существование возможности подать данный файл на вход в какую-либо программу, чтобы она проанализировала его (протокол) на стойкость с помощью современных методов проверки стойкости (одних или нескольких), например, BAN logic... 4. Соответствие какому-либо стандарту (пусть и негласному). Очень не хочется изобретать свой велосипед, свою грамматику, а взять за основу что-нибудь готовое. Кто сталкивался с подобной задачей, поделитесь пожалуйста умными мыслями и опытом. Спасибо!
Первое правило создания криптопротоколов: "Никогда не создавай криптопротоколы". Банально подводных камней очень много, начиная той же процедурой обмена ключами, заканчивая генератором псевдослучайных чисел. Используйте OpenSSL и не изобретайте велосипеда, а в файле можно хранить настройки, сертификаты и п.р.
Спасибо большое за совет, но он в моем случае не поможет, увы) И ещё я полагаю, что правило "не создавать протоколы" относится к изобретению новых протоколов (вот тут камней действительно немерено), а не программной реализации старых добрых протоколов (стандартизованных, например ISO). Сомневаюсь, что мой ГПСЧ будет хуже, чем SSL-ский. Сам протокол создавать не буду, возьму существующий. Остались ли ещё подводные камни? Первоначальный вопрос пока что остается открытым...
Прошу прощения, я неверно выразился. Под стандартом я имею ввиду не сам протокол, а именно способ описания конфигурационного файла. Т.е. я уверен, что где-то в мире существуют общепринятые нормы, которые повествуют как именно описать протокол для того, чтобы его в дальнейшем скормить на вход какой-нибудь программе-проверке (см. пункт 3 в 1-м посте).
1. Правило не трогать относится не только к самим алгоритмам, но и к их использованию. Я не являюсь экспертом-криптоаналитиком, но 90% того что я встречал ломалось именно из-за кривого использования, при внешней видимости использования надежных алгоритмов и протоколов. 2. Приведите хоть один довод в пользу вашего PRNG (если вы собрались его с нуля реализовывать) против существующих? Нет, нет, я вас совершенно не хочу переубеждать, но ломать потом будут ваши продукты З.Ы. Ко всем вашим 1-4 вопросам в первом посте подходит SSL и аутентификация по сертификатам.
К сожалению не получится отделаться уже готовой реализацией SSL никак( И на этот факт я не могу повлиять. Мой PRNG не будет лучше, но и хуже он будет вряд ли. Насколько я осведомлен (поправьте меня если я ошибаюсь), SSL не использует какой-либо физический источник энтропии, а это, очевидно, не комильфо по криптографическим правилам хорошего тона. Сейчас мы рискуем наткнуться на очень обширную тему - ГПСЧ, которая хоть и интересна, но выходит за рамки текущего вопроса. И на него пока что, увы, ответ не получен...
