Pull to refresh

Comments 63

у Питера взгляд замученный, видать, задолбали его конкретно правооблагатели
Настолько замученный, что про OTR он даже и не вспомнил.
Купил 2 кода. Хорошее дело делают ребята.
Доброе время суток)
Подскажите, после оплаты какое то уведомление пришло?
У меня оплата ушла а уведомление от них не пришло
У них на сайте написано, что вышлют коды после запуска приложения. Просто сохраните квитанцию от PayPal или какое-то подтверждение от Bitcoin и ждите.
Хорошо бы ещё многопользовательский чат сделали. Известные мне программы такого рода (torchat, Gajim) не включают такую возможность.
ХМРР вроде умеет работать с конференциями…
Однако в режиме конференции у меня не получилось добиться шифрования от пользователя до пользователя. Сервер, обслуживающий конференцию, имеет доступ к передаваемым сообщениям — удобное место для мониторинга спецслужбами. Необходим собственный сервер для обслуживания конференции или внедрение шифрования от пользователя до пользователя. Сделать такое шифрование довольно просто: сначала каждый участник публикует свой открытый ключ, после чего каждое сообщение шифруется одноразовым симметричным ключом, который шифруется ключами всех остальных участников и результат прилагается к сообщению. Также необходимо через внешние относительно конференции каналы убедиться, что сервер конференции не производит MITM-атаку.
По уму, надо-бы и регистрацию на таких сервисах отменить и регистрироваться только по хэшу GPG ключа. Своим контактам просто скидывать свой открытый GPG ключ и сразу иметь защищенную связь с ними.
многие криптографические инструменты сложны в освоении и неудобны в работе.
Ну так задача разработчика и состоит в том, что-бы облегчить пользователям работу с этими инструментами. И сделать это более чем просто. Честно говоря, меня удивляют такие заявления. Криптография ничем не сложнее чем любые остальные вычислительные задачи и я не вижу принципиальных проблем с тем, чтобы сделать их удобными для обычного пользователя.
Думаю, было бы просто — давно бы сделали.
Принципиальная проблема есть. Она состоит в том, что криптографией нельзя пользоваться «вслепую», посредством одной кнопки «Вкл.», иначе она теряет смысл. Пользователь либо должен быть настолько грамотным технически, чтобы самому убедиться в том, что все настроено и сделано правильно. Либо доверить это кому-то, кому он доверяет, простите за тавтологию. В этом фундаментальное отличие от, скажем, электронной почты, которым можно пользоваться, не разбираясь в том, как это все работает. Не нравится один провайдер или клиент, перешел на другой, не задумываясь нажал кнопку «Импортировать всё» и снова счастлив. С безопасностью так не выйдет. Security for the masses пока еще не изобрели.

Поэтому очень интересно, как Питер и его команда будут решать эту непростую задачу. Но желаю им успехов.
Эта проблема решается открытыми исходниками и мнениями экспертов о них. У пользователя будет выбор — или доверять мнению экспертов, или разбираться в исходниках самому.
Не поможет. Безопасность и удобство несовместимы. Одного лишь мнения недостаточно. Ну вот я знаю, что TLS/SSL в принципе надёжен. В теории. А на практике я могу надеяться исключительно на собственный контролируемый CA, проверку подписей всех сертификатов и так далее. То есть без квалификации и усилий никуда.
По моему, вы что-то путаете. Для работы защищенного IM нужно только шифрование. Такое, что-бы отправляемое сообщение было доступно только одному получателю. В данной задаче не стоит вопрос о том, что-бы обеспечивать соответствие определенного ключа определенному источнику. Такое соответствие будет обеспечиваться на бытовом уровне. Например, через передачу идентификатора ключа по обычным каналам связи. А такой вариант реализовать удобным для пользователя вполне возможно.
Что такое «передача идентификатора ключа»? Куда его вводить? А кому верить, когда получаешь? А кому можно отдавать, а кому нельзя?

Для полноценного использования технологии абсолютно необходимо её понимание, она просто так не работает. А слово «работает» тут означает «функционирует» плюс «по-настоящему секьюрно». У гиков и так уже есть средства безопасной передачи данных, а не-гики всё равно не смогут это использовать эффективно и надёжно. Безопасность требует серьёзных усилий, этого не миновать никак. Я SSL не просто так в пример приводил, это замечательный пример, как надёжная технология используется неправильно.
Вы с другом или знакомым списываетесь любым образом — по емэйлу или в другом IM (может быть встречаетесь живьем) и передаете друг другу любым образом строку с идентификатором ключа. Эта процедура будет служить вашей личной привязкой данного человека к данному ключу. Вы можете сами выбрать надежность такой передачи используя живой контакт или виртуальный через сеть — все в вашей власти. Ну и кроме этого, не забывайте о наличии такого механизма в OpenGPG, как сеть доверия. Она там несколько корявая, но вполне работоспособная.

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

Для надежной работы такого сервиса, как в любой другой криптографической системе, необходимо только обеспечить недоступность секретного ключа посторонним лицам.

И все это можно реализовать удобным для пользователя способом.
В том-то и дело, что стоит задача передача ключа по доверенным каналам, исключающим атаку MitM как минимум. Как вы представляете удобную и безопасную передачу открытого ключа бит так в 256 хотя бы потенциальному собеседнику обычными каналами связи? Диктовать hex-дамп по телефону? Отправить по мылу или через другой мессенджер? Отправить по открытому каналу в том же мессенджере, чтобы потом его можно было зашифровать? Передать одним кликом через третью сторону?
Вы знаете что такое идентификатор ключа и что такое сервера публичных ключей? Поинтересуйтесь.

При передаче такого ключа, ее надежность будет целиком определяться тем, насколько надежный канал связи вы хотите получить. Хотите надежный — озаботьтесь тем, что-бы удостовериться в том, что идентификатор ключа вам передает именно его владелец. Позвоните ему по телефону или встречайтесь лично. В большинстве случаев такая надежность не нужна. Тем не менее, если она вам понадобиться — все в ваших руках.

Прелесть открытого ключа как раз в том, что его можно распространять публично. Если вам нужна привязка этого ключа к конкретному человеку — это ваша личная задача ее обеспечить. И это никак не задача ПО.
Если вам нужна привязка этого ключа к конкретному человеку — это ваша личная задача ее обеспечить. И это никак не задача ПО.

Вот только обычные пользователи этого не понимают.
А когда пользователи емэйлами обмениваются, они разве не понимают что именно они делают?
Обычно нет. Они думают, что получают канал связи с человеком и никто посторонний доступ к нему иметь не может. А уж о том, что это может быть канал связи с другим человеком или организацией вообще практически никто не задумывается.
>озаботьтесь тем, что-бы удостовериться в том, что
Вот круг и замкнулся. Именно от этого и нужно избавить простого пользователя, не так ли? :)

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

И это только верхушка айсберга. Еще нужно быть уверенным, что ключи генерируются достаточной длины, обеспечить сохранность приватного ключа от троянов, иметь работающий механизм оповещения о возможной его компрометации, и т. д., и т. д.
Пишу еще раз — для данной конкретной задачи IM менеджера с защитой передаваемых данных, все можно сделать очень удобно для пользователей. Не сложнее чем в обычных IM менеджерах. В принципе, вообще всю работу с криптографией можно спрятать во внутренней логике приложения, так что пользователь с нею не будет иметь никакого дела.
И верить производителю на слово, что данные шифруются и никто кроме адресата их расшифровать не может.
Верить на слово не производителю, а сообществу разработчиков, которое будет разбираться в открытых кода софта.
Так предложите такую схему! Мне правда очень интересно. Напишите пост, например.
Может потому что в PGP все проще с передачей сообщений и файлов когда твой собеседник находится в оффлайн?
А вот и ответ, отсюда:
Why not use OTR?
Even though we love OTR it’s not really feasible to use in a mobile environment. The problem is that OTR needs both parties to be online for a session to start, but a normal phone would not always be online. It would not work at all for offline messages neither.
Да, это аргумент. Хотя можно было бы сделать оба режима и переключаться по ситуации. Спасибо!
UFO just landed and posted this here
Я считаю, что любое ПО для шифрования, должно быть с открытым кодом. И, как писали выше, наверно стоит использовать OTR, т.к. если будут потеряны секретные ключи, прошлая переписка не будет скомпрометирована.
поддерживаю, только опенс сорс, только хардкор.
Что весьма занятно — ребята продают коды для анлока фич. :) И… как бы посылают Apple подальше с 30% комиссией за инаппы. Посмотрим каким будет их старт под iOS.
Никаким, для использования криптографии в приложениях для аппстора нужны специальные документы, которые выдаются специально обученными органами в США. Которые естественно этой программе их не выдадут.
И конечно продажа кодов в обмен аппстора не будет пропущена.
По большому счету нужен будет повод. Т.к. регистрация ERN получается не сложно и там есть исключения. Опять таки такой вот подход к анлоку встроеных функций тоже вызывает опасения.

С другой стороны надо ежегодно подавать сведения о шифровании в своем приложении даже если оно использует https. И большинство приложений которые используют стороннюю аналитику (flurry или google analytics) или crashtlytics — попадают под эти требования. Большинство разработчиков забивают болт на эти требования, не по злому умыслу, а просто по незнанию, и неплохо живут при этом.
Мои секреты не стоят $50. Пару баксов я бы еще дал.
Действительно, уже давно есть этот SJ. Один в один джаббер (XMPP) с GnuPGP. Даже с исходниками.
как это забавно, сооснователь the pirate bay выпускает платный софт (там будут доп.фишки за деньги продавать в нем)!!!
Как это забавно, человек хочет работать за что-то, а не просто так.
да, но одновременно он через свой the pirate bay лишает выручки от продаж авторов ПО, фильмов и музыки СО ВСЕГО МИРА, плюс зарабатывает на рекламе на сайте the pirate bay.

И вот теперь он решил заработать на платном софте.
Софт сам бесплатный же будет. Только дополнительные фишечки и шашечки платные будут. Это распространенная схема. Даже у опен-сорсного Редхата тоже есть платная фишечка — тех.поддержка.
Странно, что не планируют десктопный и веб-клиенты — очень бы не помешало в связи с пертурбациями в Hangouts и гугловском джаббере.
Спасибо, что обратили внимание, а то я уже за картой полез.
ответ на вопрос про веб клиенты, с намеком на google hangouts:
«At this point a web-client is not planned. But since the fundraiser went very well
we have decided to look at other platforms as well.
We will most likely start with other phone platforms tho.»
Обломно(
Немного сомнительно — говорят вроде как о безопасности, но проект не OSS и даже спецификация протокола закрыта. Соответственно ни сторонних серверов, ни альтернативных клиентов — какая, к лешему, безопасность? Построенная на доверии что вот эти клёвые чуваки точно сделали крутой сервис и не украдут мои данные? Хотел пожертвовать, но быстро передумал. Пока не откроют исходники хотя бы сервера и протокола — очередная ненужная хрень.
Ну ладно, хорошо.
Где гарантия что под видом обновления вам в следующей версии шифрование не отключат?
Сам алгоритм шифрования насколько стоек(вполне вероятны огрехи кои приведут к значительному снижению стойкости.
Как они собираются боротся с MiM атакой?
Ну как они собственно написали что потеря железки=полный провал.
Сервер или провайдер сервера вполне себе думаю ведет логи, при желании можно сверить кто кому и когда писал, что тоже в какой то мере компрометация.

Ну и собственно ниже напишу как бы это видел я(параноик_моде_он)
Делаем прошивку под андроид(в иОС не знаю как)

Меняем авторизацию и добавляем там асиметричного криптопровайдера кой сохраняет сообщения с открытым ключем закрытый ключ шифруется паролем разблокировки ( можно с модмешиванием биометрии) т.е. на заблокированном устройстве сообщения уже не прочитать даже если напрямую считать с микрухи, старые хранятся зашифрованными новые еще зашифрованы, ключик по которому новые расшифруются лежит в той же зашифрованной области что и история. Собственно сам факт приема сообщения мы видим а что в нем пока не разблокируем не узнаем.
Алсо надо будет из памяти все остатки расшифрованных данных подтереть перед блокировкой(включая видеопамять и всячские кеши)… иногда замечал при разблокировке любых устройств на экране сохраняются старые данные.

Отправлять/забирать сообщения с сервера тоже стоит пачками(собственно недавно писали пример habrahabr.ru/post/186000/) ну или как вариант делаем возможной смену контакта или вобще делаем контакты плавающими т.е. раз в 100 сообщений вы переплываете на новый сервер/логин без смены ключа, и даем возможность по новому адресу старым адресатам доказать что вы это таки вы.

Ну и все это в опенсорсе выкладываем на суд общественности.

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

Собственно и это только клиентская сторона, если добавлять анонимность тогда в полный рост встает вопрос о защите от ДДОС-ов как сервера так и отдельных клиентов. Если вводить капчи то клиент задолбется их вводить, если заставлять клиентское устройство генерировать чтото то где гарантия что не появится устройство которое будет делать эту работу в тысячи раз быстрее (см. историю с биткоинами)

Вобщем анонимности для масс не получится ИМХО.
обмен фотографиями за деньги? спасибо, я лучше как-нибудь по старинке, i2p, tor, вот это всё.
1337 Services LLC
отличное название компании )

Скинулся конечно, хорошее дело.
>Единственный способ прочитать частную переписку — получить контроль над телефоном одного из собеседников.

Мне кажется сейчас это не проблема. А если так, то нафига нужен этот месенджер?
коллеги, добрый день, вопрос сообществу: как соотносится этот мессенджер с нотификацией , по своей сути, которая запрещает массовое использование криптотехнологий в народе (только по сертификату, но сертификатом как бы пользователь попадает в список)?
то есть я правильно понимаю, чтобы пользоваться таким мессенджером на телефоне, нужно получить сертификат?
По Вашей ссылке прямо написано: "Ввоз и вывоз шифровальных средств… осуществляется на основании… нотификации". Вы собираетесь что-то ввозить или вывозить?
Хм. Я тут задумался. Собираюсь на Украину ехать «гастарбайтерить» :) и, естественно, хочу взять с собой свой андроид-планшет. А там криптографии даже встроенной куча, не говоря об установленной… Дома оставить, закон нарушать или что?
Сомневаюсь, что будут проблемы. Вряд ли на таможне будут проверять, что установлено у Вас на планшете )))) Но, если следовать совсем параноидальному пути — сделайте бэкап системы, установите на планшет чистую, когда пересечете границу — восстановите из бэкапа ))))))
Я про формальную сторону дела. Ввоз и вывоз шифровальных средств массово осуществляется ежедневно и вроде как с нарушением закона. Практически любой современный девай так или иначе эти средства содержит (хотя бы браузер с поддержкой https), но никто при их ввозе-вывозе нотификации не шлёт.
Оплата на их сайте кажется уже под Хабраэффектом.
>Бэкеры имеют приоритетную возможность зарегистрировать имя пользователя
после этого задумался и почитал FAQ.

>Your server only?
>Yes! The way to make the system secure is that we can control the infrastructure.

Короче, очередное |-|@36@]|080.
Sign up to leave a comment.

Articles