Дуров ищет разработчиков для нового протокола (+комментарий Павла)

А разве Сергей Кравцов не собирается делать мессенджер? ;-)

Сноудену пусь предложит эту работенку, Ему сейчас все равно делать не хрен…Для него это как два пальца обоссать…

Сижу, пилю для интереса. Дальше «испытательного теста» не думаю, что хватит сил/времени, но попробую таки записать свой айдишнечег. Just4fun. Позволю себе высказать по этому АПИ: 1. Ключевая претензия — это возможность закрыть такой мессенджер фаерволом. Офисный планктон будет отрубаем по прихоти начальства, пакеты все явные, и закроет любой админ. Тот же скайп как раз гордится тем, что пролезает через любой фаервол и любой фильтр, а в случае данного протокола не сделано _НИЧЕГО_ в эту сторону. Поправьте меня, если я ошибаюсь. 2. Секьюрность переписки — это не столько секьюрность канала «клиент-сервер», тут для большинства хватит обычного SSL, а невозможность прочитать переписку при наличии доступа к серверу. Использовать или нет мессенджер ВК лично для меня — это не вопрос надёжности https-соединения, а вопрос доступа к моей переписке на сервере ВК. 3. Ничего нет в сторону голосовой и видео связи. Может быть рано я поднимаю вопрос, но пока по текущим мануалам не видно, что в эту сторону что-то ожидается. Там вопросы поднимаются совсем другие. Я буду приятно удивлён, если окажется, что я ошибся. И что на самом деле в новом протоколе будет шифровка между пользователями напрямую. В идеале — с обменом ключами при личной встрече или хотя бы голосом по телефону. И передача трафика без серверов ВК и тем более расшифрованных сообщений серверам ВК. Но пока лишь, увы, всё сильно напоминает историю с протоколом Мэйлру-агента. Да, трафик теперь шифруется, но даже банальные вещи, которые доступны в связке OTR + jabber, пока в новом протоколе не видны.

И не надоедает же некоторым, кто не обладает профессиональными качествами для успеха, пытаться запрыгнуть на стремительно уходящий поезд тренда. Пусть запилят через конкурс, но итог один и тот же.

Александр, по второму вопросу: там же вроде PGP клиент-сервер с возможной защитой от взлома в будущем. То есть, для чтения переписки нужны оба ключа — серверный и клиентский, а клиентский можно периодически менять. Расшифрованными передаются только служебные команды.

Мессенджер без хранения сообщений на сервере — нафиг не нужная массовому юзеру приблуда.

нафиг не нужная массовому юзеру Зато миллионы контактодрочеров будут форсить этот мессенджер и восхвалять его просто потому что он от ВК, обильно поливая другие мессенджеры помоями

Евгений, вы уже заранее признаете, что продукт будет обречен на высочайшее качество исполнения. Или у Вас боль, что у ВКонтакте самая лояльная аудитория?

Ксерокс, у РЖД, Водоканала и Электросетей еще более лояльная аудитория. Изобретать велосипед в 2013… Дурова разморозили? Воцапп как-то не хвалится протоколом. Все равно победит клиент, а не протокол.

Или у Вас боль, что у ВКонтакте самая лояльная аудитория? Не совсем понял, почему это у меня должна быть «боль»? Я вообще вел к тому, что кол-во глубокозависимых людей, которые идеализируют ВК чуть ли не в религию и готовых сделать почти все, лишь бы с ВК ничего не случилось — достаточно много, для того, чтобы создать твердую почту под данный мессенджер

Евгений, это нормально. Если один процент юзеров сервиса можно отнести к его фанатам, то у ВК один миллион фанатов. Это очень много, поверьте. Мы иногда испытываем их нашествие и оно не всегда нас радует.

>это не вопрос надёжности https-соединения, а вопрос доступа к моей переписке на сервере ВК. Tor же, т.е. новый слой шифрования от точки к точке. переписку хранить в зашифрованном виде на основном сервере и помнить в клиенте какой приватный ключ был актуальным на тот момент времени(обновлять, скажем, по NFC). ЗС: бампнуть телефонами, да это же вэбтринольный формат приветствия в РЛ :)

WinterLard, а мне вот надоели мессенджеры с сохраняемой историей сообщений. Нет, серьезно. Никто чего-то не хлопает в ладоши от диктофонов на встречах, а вот повсеместное копирование переписки — это да, отлично привитый долбанный стандарт.

У Кравцова свои планы, видимо)

Мессенджеры, мессенджеры… Когда-то Дуров обещал всем по ящику для электронной почты, но так до выдачи постоянных e-mail дело и не дошло

Для Александра Панькова: Дуров прокомментировал Ваше сообщение: «Автор ошибается в каждом из трех своих предположений. Протокол разрабатывается больше года, и VoIP, end to end encryption, разные виды транспорта, мультидатацентровость — все это уже успели не только спроектировать, но и протестировать. Чтобы не пугать участников конкурса, 90% документации от них сейчас срыто.»

Почитал я документацию. С высоты своих 13 лет мультипротокольной деятельности с уклоном в VoIP отпишусь: 1) Это не протокол, это транспорт для передачи сообщений. Сообщения могут быть текстовыми или файлами или еще чем. Но звук и видео будет передавать только мнэ…… Никто не будет, в общем :) 2) Описание странное. Обычно идут общие дефиниции, диаграммы сеансов/сессий, сущности (клиент/если есть — сервер), ограничения. Этого нет. Вместо этого мощный уклон в криптографию и низкоуровневую структуру. Почему не используются BNF или ASN нотации для описания сообщений — неясно. 3) Самописным голосом и видео там не пахнет, это сказки. В лучшем случае будет использоваться SDP (как в SIP протоколе) и RTP стеки и кодеки. Или libjingle. 4) Криптостойкость вызывает вопросы. Я вдумчиво не вчитывался, но потенциально опасные моменты есть. 5) Бинарный протокол — это не комильфо. Если уж хочется бинарности, то уже есть IAX. 6) «Все числа записываются как little-endian. Однако очень большие числа (2048-битные), используемые в RSA и DH, записываются как big-endian, потому что так делает библиотека OpenSSL» — это позор даже для школоты. Привязка к одной единственной библиотеки криптования???? 7) «Если время на клиенте сильно отличается от времени на сервере, может так получиться, что сервер начнет игнорировать сообщения клиента» — «сильно» — это сколько? Это инженеры писали или маркетологи? 8) Чего хорошего — поддерживает TCP/UDP/HTTP 9) Странное: — не проходит через прокси и HTTPS прокси — странные дефиниции в спеках — поддержка IPv6? — поддержка STUN/TURN/H.460.x? — голоса/виде нет и не будет. Резюме — реинкарнация джаббера для целей воцаппа. Полагаю, на коротких сообщениях все и завершиться.

вы не забывайте о правительстве и силовых структурах. Не смогут сливать инфу о пользователях — не смогут работать. Они просто не могут позволить себе хранить инфу в зашифрованном виде.

Чтобы не пугать участников конкурса, 90% документации от них сейчас срыто. При этом делаются куча заявлений о каком-то фантастическом требовании IQ >130, которое, надо полагать, привлечёт к конкурсу? Ответ «мы на самом деле всё сделали, просто никому не показываем и на РОЕМе не каментим» вообще странен. Любое описание протокола как раз начинается с описания его возможностей, его целей создания и способов внедрения. Даже если что-то и не завершено, озвучиваются хотя бы идеологические предпосылки.

Maxim Surkiz, вы преувеличиваете. Даже сейчас я могу на обычном ВКонтакте переписываться секьюрно, и ни одна спецслужба не прочитает. Рецепт простой. ВК умеет работать по протоколу jabber, поэтому если оба собеседника поставят джаббер с OTR-ом, то ZOG не сможет прочитать. Лучше бы трансфер в другие джабберы прикрутили.

Ну, переводя на язык обывателя — новый мессенджер есть попил денежек Дурова?

А в ВК адресация пользователей в Jabber до сих пор по vkmessages или как их там идёт?

Jabber давно на @vk.com http://vk.com/help.php?page=jabber временные e-mail для диалогов по электропочте, инициированные из VK, на @vkmessenger.com

«новый мессенджер есть попил денежек Дурова?» Ох, вот откуда такие юзеры берутся? То у них Николай Дуров по блату устроился к Павлу Дурову на работу, то ВК решил попилить три миллиона рублей. Это ж в два раза больше, чем Навальный!

Это ж в два раза больше, чем Навальный! Не в два, а в пять, и не больше, а меньше :-)

Главная задача этого конкурса не создание очередного мессенджера (они-то как раз у ВКонтакте есть), а формирование комьюнити разработчиков, у которых будет опыт работы с новейшим протоколом. Это быстрый и безопасный протокол, разработанный лучшими мировыми инженерами, который в последствии может быть применен в любом другом мобильном коммуникационном сервисе. Подобная технология — это еще один шаг для укрепления позиций отечественных компаний (одних из лучших в мире). Почему начали с мессенджера — скорость и безопасность имеют критическое значение именно здесь. Почему Андроид — наша команда считает, что это самая перспективная платформа на сегодняшний день. Впрочем, если из этого конкурса получится отличный мессенджер, который сможет составить конкуренцию Вотсапу, то почему и нет? Не забывайте, что ВКонтакте появился, когда вопрос социальных сетей в России ‘закрыли’ Одноклассники; ФБ, когда вопрос соц.сетей ‘закрыл’ Майспейс и т.д.

Ксерокс, умные люди указали вам на проблемы с вашим месенджером. ВК — вы соцсеть, во и оставайтесь соцсетью. Попытки сделать что-то вне пределов ВК так и останутся попытками восторженных неофитов. Делайте свой мессенджер/слушайте свои валенки и не лезьте в области, где люди гораздо умнее и опытнее вас (удивительно, но в контакте вовсе не гении по сравнению с западом и Китаем). Придумайте SPDY какой-нибудь, наконец. Напомните мне, кто из «лучших мировых инженеров» засветился в соавторах RFC, советах ITU и прочих IEEE? Иначе фейл с «новым протоколом» WebRTC от меил.ру окажется цветочками.

>>во и оставайтесь соцсетью >>и не лезьте в области, где люди гораздо умнее и опытнее вас Всё, даем отбой ребятам.

Я верю в успех начинания. Сейчас наблюдается пустая ниша — засилье кривущего skype и чисто мобильные whatsapp и viber. Альтернатива skype востребована.

>> Альтернатива skype востребована. Можно подумать, у skype нет альтернатив…

Ксерокс, а можно узнать о преимуществах нового протокола? И кто его будет поддерживать кроме ВК? Это не подколки, я серьезно хочу понять, есть ли на него RFC и реализация на языке Си? Когда ожидается появление пакетов libmtproto и libmtproto-dev в ЦентОС и Убунту (хотя бы)? Может быть, стоит рассчитывать на скорое появление врапперов для Питона, ПХП и Руби? Пока ваши слова выглядят лозугнами, а протокол — задачкой для конкурса.

По итогам чтения документации к протоколу возникла куча вопросов, по всем пунктам. Начну с криптографического слоя: 1. Почему нет никакого механизма проверки целостности сообщения? Мало того, что отсутствие MAC добавляет геморроя при выявлении транспортных ошибок, оно еще и ведет к простору в использовании CCA (http://en.wikipedia.org/wiki/Chosen-ciphertext_attack). Ну и в целом, я не понимаю, как можно в 21 веке использовать слова «большая криптоустойчивость» по отношении к чему-то, не выполняющему требования Authenticated Encryption (http://en.wikipedia.org/wiki/Authenticated_encryption). Насколько я помню, после эпик фейла под названием WEP, не было разработано ни одного криптографического стандарта, не требующего передачи MAC. 2. Почему для шифрования выбран последовательный IGE, в то время, как существует куча параллельных схем (что особенно актуально на мобилках с кучей медленных ядер). Например, прекрасный GCM (http://en.wikipedia.org/wiki/Galois/Counter_Mode), имплементации которого существуют во всех криптографических библиотеках. Кроме того, он еще и аппаратно акселерируется на процессорах Intel. А учитывая, что он выбран в качестве стандарта в TLS 1.2, IEEE 802.11 ad (http://en.wikipedia.org/wiki/WiGig) и т.д., можно ждать аппаратную акселерацию и на мобильных процессорах. Кстати, GCM поддерживает режим AEAD, что заодно решает проблему целостности сообщения. Что касается RPC-слоя: 1. Зачем было изобретать еще один протокол сериализации? Уже есть ProtoBuf, поддерживающий Schema Evolution. Есть Thrift, заточенный под RPC (и также поддерживающий Schema Evolution). Есть BSON, вообще не имеющий схемы (хоть и менее компактный, чем все предыдущие). И есть Avro (имхо, самый подходящий для этой задачи), позволяющий генерировать динамическую схему и передавать ее клиенту только в случае изменения. В итоге, с задачей экономии байтиков Avro справляется гораздо лучше. Если взять пример вот с этой страницы: http://dev.stel.com/mtproto/TL (самый низ, «Пример RPC-запроса»), то запрос на Avro будет занимать 6-8 байт вместо 12, а ответ на него, по прикидкам, также будет в 1.5-2 раза короче (сорри, лень считать точнее). Так как схема передается только при изменении (что бывает, например, раз в месяц), то она не добавляет байтиков к RPC-вызовам. Честно говоря, после этих вычислений, слова «меньше байтов» выглядят несколько бледно. И самое главное: не надо писать еще одну библиотеку сериализации на всех существующих языках программирования. Дальше, собственно говоря, пошли мелочи. Если бы все предыдущие пункты были сделаны с использованием промышленных стандартов, то все, что написано ниже, отпало бы само собой: 1. Почему бы вместо CRC32 при вычислении ID поля не использовать, например, Murmur3-32 (http://en.wikipedia.org/wiki/MurmurHash), исключающий коллизии? 2. Почему бы для сериализации int’ов (везде, в том числе и при передаче длины строк) не использовать VarInt (возможно, с ZigZag encoding), являющийся де-факто стандартом (см., например, тут: https://developers.google.com/protocol-buffers/docs/encoding). Во-первых, он экономит байтики на строках до 16к символов (что вполне соответствует размеру поста в социальной сети, сообщения в IM и т.д.). Во-вторых, он позволяет не различать типы int и long при сериализации. В третьих, с ZigZag encoding, он позволяет компактно передавать отрицательные числа (что вполне актуально для API VK, в котором много где используются отрицательные ID групп). 3. Зачем нужно такое адское количество исключений из правил? Вот, например, мое любимое: «Существует сокращённая версия этого протокола: если клиент отправляет первым байтом (важно: только перед самым первым пакетом данных) 0xef, то после этого длина пакета кодируется одним байтом (0x01..0x7e = длина данных, делённая на 4; либо 0x7f, а затем 3 байта длины (little-endian), делённой на 4), а далее идут сами данные (порядковый номер или CRC32 не добавляются). Ответы сервера в этом случае имеют тот же вид (при этом сервер не отсылает первый байт 0xef).» Все эти исключения добавляют сложность имплементации и потенциальные баги, Имхо, выигрыш от этих хаков совершенно непропорционален затратам на разработку. 4. Почему в описании протокола нет ни слова об обработке ошибок? Работа вменяемого приложения невозможна без понимания, что пошло не так. А учитывая, что мы имеем дело с тремя слоями (транспорт, криптография, RPC), то нужны, соответственно, 3 уровня диагностики. 5. Почему в описании протокола нет ни слова о других моделях коммуникации, помимо RPC? Из описании совершенно не следует, что протокол подойдет, например, для потоковой передачи данных. Может и подойти, но это ниоткуда не следует(это к вопросу о voice/video, который уже задавали). Резюме Разработки, претендующие на стандартизацию, обычно ведутся широким кругом экспертов с публичными обсуждениями и т.д. При этом, эксперты в криптографии отвечают за криптографические решения, эксперты в транспортных протоколах — за транспортные решения, а эксперты по байтикам — за экономию байтиков. Побочным результатом этих обсуждений является документированная мотивация выбора тех или иных решений. Я вполне допускаю, что у разработчиков протокола есть ответы на все мои вопросы (тем более, что я не претендую на экспертизу в криптографии/транспортах), но без ответов я вынужден оценивать эту разработку со своей колокольни (как, впрочем, и другие потенциальные разработчики). А для меня протокол выглядит неоптимальным, избыточно сложным и недостаточно документированным. В общем, хорошим упражнением для имеющих время и желание в нем поковыряться, но, простите за бедность речи, адским геморроем при необходимости инвестирования в разработку под этот протокол и дальнейшего использования в коммерческих продуктах.

По итогам чтения документации к протоколу возникла куча вопросов, по всем пунктам. Начну с криптографического слоя: 1. Почему для проверки целостности сообщения используется MAC, а не HMAC? Это было бы логичнее и безопаснее. 2. Почему используется схема Encrypt-and-Mac, а не Encrypt-then-Mac? Во-первых, она считается более безопасной, а во-вторых, позволяет отбрасывать сообщения, битые из-за ошибок на уровне транспорта, до расшифровки. 3. Почему для шифрования выбран последовательный IGE, в то время, как существует куча параллельных схем (что особенно актуально на мобилках с кучей медленных ядер). Например, использование GCM (http://en.wikipedia.org/wiki/Galois/Counter_Mode) в режиме AEAD, имплементации которого существуют во всех криптографических библиотеках, убрало бы все эти вопросы. Кроме того, он еще и аппаратно акселерируется на процессорах Intel. А учитывая, что он выбран в качестве стандарта в TLS 1.2, IEEE 802.11 ad (http://en.wikipedia.org/wiki/WiGig) и т.д., можно ждать аппаратную акселерацию и на мобильных процессорах. Что касается RPC-слоя: Зачем было изобретать еще один протокол сериализации? Уже есть ProtoBuf, поддерживающий Schema Evolution. Есть Thrift, заточенный под RPC (и также поддерживающий Schema Evolution). Есть BSON, вообще не имеющий схемы (хоть и менее компактный, чем все предыдущие). И есть Avro (имхо, самый подходящий для этой задачи), позволяющий генерировать динамическую схему и передавать ее клиенту только в случае изменения. В итоге, с задачей экономии байтиков Avro справляется гораздо лучше. Если взять пример вот с этой страницы: http://dev.stel.com/mtproto/TL (самый низ, «Пример RPC-запроса»), то запрос на Avro будет занимать 6-8 байт вместо 12, а ответ на него также будет в 1.5-2 раза короче (сорри, лень считать точнее). Так как схема передается только при изменении (что бывает, например, раз в месяц), то она не добавляет байтиков к RPC-вызовам. Честно говоря, после этих вычислений, слова «меньше байтов» выглядят несколько бледно. И самое главное: не надо писать еще одну библиотеку сериализации на всех существующих языках программирования. Дальше, собственно говоря, пошли мелочи. Если бы все предыдущие пункты были сделаны с использованием промышленных стандартов, то все, что написано ниже, отпало бы само собой: 1. Почему бы вместо CRC32 при вычислении ID поля не использовать, например, Murmur3-32 (http://en.wikipedia.org/wiki/MurmurHash), исключающий коллизии? 2. Почему бы для сериализации int’ов не использовать VarInt (возможно, с ZigZag encoding), являющийся де-факто стандартом (см., например, тут: https://developers.google.com/protocol-buffers/docs/encoding). Во-первых, он экономит байтики на строках до 16к символов (что вполне соответствует размеру поста в социальной сети/сообщения в IM и т.д.). Во-вторых, он позволяет не различать типы int и long при сериализации. В третьих, с ZigZag encoding, он позволяет компактно передавать отрицательные числа (что вполне актуально для API VK, в котором много где используются отрицательные ID групп). 3. Зачем нужно такое адское количество исключений из правил? Вот, например, мое любимое: «Существует сокращённая версия этого протокола: если клиент отправляет первым байтом (важно: только перед самым первым пакетом данных) 0xef, то после этого длина пакета кодируется одним байтом (0x01..0x7e = длина данных, делённая на 4; либо 0x7f, а затем 3 байта длины (little-endian), делённой на 4), а далее идут сами данные (порядковый номер или CRC32 не добавляются). Ответы сервера в этом случае имеют тот же вид (при этом сервер не отсылает первый байт 0xef).» Все эти исключения добавляют сложность имплементации и потенциальные баги, Имхо, выигрыш от этих хаков совершенно непропорционален затратам на разработку. 4. Почему в описании протокола нет ни слова об обработке ошибок? Работа вменяемого приложения невозможна без понимания, что пошло не так. А учитывая, что мы имеем дело с тремя слоями (транспорт, криптография, RPC), то нужны, соответственно, 3 уровня диагностики. 5. Почему в описании протокола нет ни слова о других моделях коммуникации, помимо RPC? Из описании совершенно не следует, что протокол подойдет, например, для потоковой передачи данных (может и подойдет, но это ниоткуда не следует). Это к вопросу о voice/video, который уже задавали. Резюме Разработки, претендующие на стандартизацию, обычно ведутся широким кругом экспертов с публичными обсуждениями и т.д. При этом, эксперты в криптографии отвечают за криптографические решения, эксперты в транспортных протоколах — за транспортные решения, а эксперты по байтикам — за экономию байтиков. Побочным результатом этих обсуждений является документированная мотивация выбора тех или иных решений. Я вполне допускаю, что у разработчиков протокола есть ответы на все мои вопросы (тем более, что я не претендую на экспертизу в криптографии/транспортах), но без ответов на вопросы я вынужден оценивать эту разработку со своей колокольни (как, впрочем, и другие потенциальные разработчики). А для меня протокол выглядит неоптимальным, избыточно сложным и недостаточно документированным. В общем, хорошим упражнением для имеющих время и желание в нем поковыряться, но, простите за бедность речи, адским геморроем при необходимости инвестирования в разработку под этот протокол и дальнейшего использовании в коммерческих продуктах.

А тем временем вышла болталка для iPhone использующая MTProto — Telegram Messenger.