Хороший вопрос. В своё время у нас тоже появлялась необходимость в такой операции, но, в итоге, мы решили реализовать и применять её во «фронтенде». То есть Crypto API лишь обрабатывает данные на некотором, установленном ранее, ключе. А вот та часть, что непосредственно этот ключ устанавливает — проводит диверсификацию, не обращаясь для этого к Crypto API.
Насчёт регистрации нового алгоритма не уверен, поскольку в Crypto API нет подходящего для диверсификации типа преобразования. И да, я забыл написать об это в статье, но возможность реализовать свой шаблон похоже есть.
Таким образом, указ не коснется звонков между мессенджерами, однако, например, для возможности совершения звонка из Беларуси через Skype на городские/международные номера, мессенджеру придется заключить договор с оператором.
Если честно, то я плохо осведомлён о том, как обстоят дела в России, поскольку сам живу и работаю в Беларуси, а у нас с этим пока всё в порядке. Где-то полтора года назад я слышал о проблемах в зашифрованным VoIP'ом, но о том, что SRTP запрещён законодательно слышу впервые.
А в чём там собственно проблема? В неиспользовании национальной крипты, или что-то другое?
Изначально, в предисловии я собирался упомянуть о том, что некоторые иллюстрации не переведены, но, позже, эту фразу я убрал. Если вам это будет интересно, то я могу доперевести оставшиеся иллюстрации.
Стоит отметить, что моя работа здесь — это лишь перевод и публикация (если под «вашей работой» вы имели ввиду, непосредственно, сравнение). Однако, как отмечено в предисловии, с момента моего первого знакомства с оригиналом, я поработал с обоими подходами, и поэтому, некоторые мысли на этот счёт у меня всё же есть.
На сегодняшний день, я вижу, что преимущество TLS/SRTP, обоснованное в статье, если не увеличилось, то как минимум сохранилось на том же уровне. Мне так же не известно ни об одном VoIP-приложении интегрирующим IPsec. Ещё можно сказать о том, что если от безопасности SIP нам требуется только защита процесса согласования ключей, то TLS заменяется на ZRTP, что значительно упрощает разработку.
Однако, если задача поставлена чуть шире, и требуется обеспечить безопасность не только VoIP, но и в принципе любых данных передаваемых по IP, то тут вполне обоснованно можно использовать IPsec (как отдельное приложение), поскольку он, в том числе, закроет и VoIP.
К примеру, мы делали такую вещь: на серверную машину ставили Asterisk и IPsec-реализацию — StrongSwan; на клиентские Android-устройства ставили VoIP-звонилки — CSipSimple и клиентский StrongSwan. Сначала клиенты поднимают туннель с сервером через StrongSwan, а после общаются через CSipSimple, в результате весь SIP/RTP оказывается закрыт IPsec'ом. В то же время, можно выкинуть StrongSwan и настоить в CSipSimple защиту ZRTP/SRTP. Получим тот же результат.
Насчёт регистрации нового алгоритма не уверен, поскольку в Crypto API нет подходящего для диверсификации типа преобразования. И да, я забыл написать об это в статье, но возможность реализовать свой шаблон похоже есть.
Вот как раз из-за того, что изучать приходилось по исходникам, я и решил эти знания, так сказать, увековечить)
А в чём там собственно проблема? В неиспользовании национальной крипты, или что-то другое?
На сегодняшний день, я вижу, что преимущество TLS/SRTP, обоснованное в статье, если не увеличилось, то как минимум сохранилось на том же уровне. Мне так же не известно ни об одном VoIP-приложении интегрирующим IPsec. Ещё можно сказать о том, что если от безопасности SIP нам требуется только защита процесса согласования ключей, то TLS заменяется на ZRTP, что значительно упрощает разработку.
Однако, если задача поставлена чуть шире, и требуется обеспечить безопасность не только VoIP, но и в принципе любых данных передаваемых по IP, то тут вполне обоснованно можно использовать IPsec (как отдельное приложение), поскольку он, в том числе, закроет и VoIP.
К примеру, мы делали такую вещь: на серверную машину ставили Asterisk и IPsec-реализацию — StrongSwan; на клиентские Android-устройства ставили VoIP-звонилки — CSipSimple и клиентский StrongSwan. Сначала клиенты поднимают туннель с сервером через StrongSwan, а после общаются через CSipSimple, в результате весь SIP/RTP оказывается закрыт IPsec'ом. В то же время, можно выкинуть StrongSwan и настоить в CSipSimple защиту ZRTP/SRTP. Получим тот же результат.