Не может этого быть :)

конфиденциальная процедура репортинга уязвимостей

это как? От анонимусов?

А для java что есть подобное?

Классный ник.

Ну почему не может?
Сервис может работать только как API, принимать и отдавать пользователю зашифрованные данные.

А уже у пользователя должен стоять софт/браузер с плагином который расшифровывает данные и работает с ними.

Кстати, описания способа работы нет. Только сорцы

Бред же.

Торрент-трекер знает о содержимом торрентов? :)

Сервис может работать только как API, принимать и отдавать пользователю зашифрованные данные.

Тогда этот бесполезно для общества.

Торрент-трекер знает о содержимом торрентов? :)

Можно сказать что да :)
Но как может быть:
сервер, на котором запущено приложение, не сможет прочитать данные приложения ?

У SpiderOak еще есть сервис, похожий на Dropbox. Там тоже Zero Knowledge и прочее.

Вротмненоги, надеюсь они не запилят ещё шифрования/дешифрование в браузере пользователя на JavaScript?

//хотя для standalone-приложений идея стара.

Возможно дополнительным требованием есть невозможность читать оперативную память. Или незашифрованные данные в памяти существуют очень малое количество времени.

Короче говоря данные+сессия юзера = зашифрованные данные.

Тоесть речь идет о том, что нельзя прочитать данные из базы

у них есть ссылка на какой-то AES.io который так делает

Можно сказать что да :)

Ничего он не знает. Он не получает сами данные от клиентов

а как докажут что на сервере стоит именно эта штука в неизменном виде?

Хм, думаю задача заключается в том чтобы злоумышленники не украли данные пользователей завладев сервером

Хороший вопрос, лично я о таких не знаю, но надеюсь что безопасность из коробки станет трендом. Поимели ведь недавно всякие linkedin и last.fm, может и остальные задумаются.

Короче говоря данные+сессия юзера = зашифрованные данные.

Но как сервер может работать с этими данными ?
Хранить - да, может, но не работать с данными. Если сервер может с данными работать, то это все фигня. Единственное что можно предположить, что сервер не может работать с данными без участия клиента, но в любом случае при необходимости эти данные могут быть прочитаны хозяином сервера :)

Ничего он не знает. Он не получает сами данные от клиентов

Но ничто не мешает при необходимости эти данные получить.

Из источника:

When we release v0.1.0 we'll also create security contact procedures: a GPG key, a core security team, guaranteed response times, etc. We'll also be doing our own internal review before releasing v0.1.0.

Думаю, переводить не надо.

"Browser based" crypto - шифрование на основе возможностей браузера.

Chaser_Andrey

Вротмненоги, надеюсь они не запилят ещё шифрования/дешифрование в браузере пользователя на JavaScript?

Насколько я понял из сайта crypton.io, именно этим они и занимаются.

How is Crypton's reference implementation built?

Crypton's reference implementation uses Nodejs, Redis and PostgreSQL on the backend. The client is Javascript suitable for browser environment or app packaging.

When building an application with Crypton, the cryptography is entirely encapsulated and hidden.

There are additional concerns and arguments about «Browser based» crypto. (приведены ссылки на статьи по вопросу Javascript Cryptography).

Chrome and Safari include a native secure random number generator. Firefox is working on it.

Прозреваю RTCDataChannel...oh shi, он же ещё не готов, значит, опять костыли какие-то с перегоном дынных® через червер™.

punya

а как докажут что на сервере стоит именно эта штука в неизменном виде?

+1. Хороший вопрос.

Вот, какие компоненты будут работать у них на сервере:

Crypton's reference implementation uses Nodejs, Redis and PostgreSQL on the backend.

Спасибо, как оно будет ясно. Зачем оно так будет - неочень.

Чем оно лучше дропбокса с encfs?

Что значит работать? Нафига сервису типа evernote знать о чем я пишу? Мы тут не про фейсбук говорим.

но в любом случае при необходимости эти данные могут быть прочитаны хозяином сервера :)

Спасибо, посмеялся. Почитайте, что-ли. А то говорить даже не о чем.

По ссылке информация от СЕОшников. Никаких подробностей реализации, даже основная идея не затронута.

Как я понимаю, «Zero knowledge» - это когда незашифрованные данные вообще не попадают на сервер, и ключей для их расшифрования у него нет. При этом сервер выполняет только роль ретранслятора-файлохранилища.

Но тогда непонятно, зачем вообще серверная часть фреймворка? В общем, что-то у них не чисто.

Они что, предлагают заниматься шифрованием в браузере?

Вобщем, ЯННП

Дропбокс - это не фреймворк, ЕМНИП.

Да, действительно. Но, все равно, чем оно отличается от любого другого облачного хранилища? Зачем єто все?

Ты так говоришь, как будто это что-то плохое. Да, шифрованием в браузере. Но тем не менее, я тоже ННП, зачем им черверная часть. Ладно бы ещё обычный TURN-сервер для RTCDataChannel держали, но приплетать редиску и постгре... странно.

Тогда этот бесполезно для общества.

Обществу вообще наплевать на конфиденциальность данных.
Людей совершенно не волнует, что их паспортные данные знает каждый школьник, а фотки не удаляют для уменьшения фрагментации.
Ну и вообще их вполне устраивает использование уязвимых систем (и не важно будет то винда или линукс), если данные не пропадают, то плевать на то, что данные карточки продают за 2 бакса.

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

Если тебе не нравится javascript, то шифрование можно реализовать нативным плагином, какие проблемы?

segfault

Никаких подробностей реализации, даже основная идея не затронута.

Согласен в данном вопросе.

segfault

Как я понимаю, «Zero knowledge» - это когда незашифрованные данные вообще не попадают на сервер, и ключей для их расшифрования у него нет. При этом сервер выполняет только роль ретранслятора-файлохранилища.

Придерживаюсь такого же мнения.

Что значит работать? Нафига сервису типа evernote знать о чем я пишу? Мы тут не про фейсбук говорим.

Если мы говорим про хранение инфы, то такой сервер ничем не отличается от FTP+GPG, которые придуманы еще в прошлом веке =)
Если мы говорим про обработку сервером инфы, хотя бы про индексирование, поиск и т.д., выполняемое на стороне сервера, то это совсем другое...

Спасибо, посмеялся. Почитайте, что-ли. А то говорить даже не о чем.

Расскажите мне, как я должен применить эти знания к Торрент-трекеру ?

Это как tomcat или jetty которые не могут получит доступ к данным движка Лора. Не понятно только зачем нужен сервер в этом случае. Реализуйте свой httpd йопт )))

Если мы говорим про обработку сервером инфы, хотя бы про индексирование, поиск и т.д., выполняемое на стороне сервера, то это совсем другое...

А если эти задачи, ранее выполняемые на стороне сервера, теперь распределяются по клиентам с их никуда не выходящими ключами?

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

Ну так для него самого - для хранения. Чтобы с любого телефона работать можно было. А профит идет с подписок.

Ты так говоришь, как будто это что-то плохое.

У шифрования в браузере есть пара проблем - канал загрузки алгоритма считывания секрета и канал загрузки алгоритма криптографического преобразования. Если бы и то и другое брал на себя браузер, было бы более-менее.

Но облака тоже могут быть уязвимы, поэтому подобный фреймворк нужен.

Зачем нужен этот фреймворк, если шифрование/дешифроваие один хрен нужно на стороне клиента в целях безопасности ?
Если что-то шифруется в облаке, то это по определению решето =)

Если тебе не нравится javascript, то шифрование можно реализовать нативным плагином, какие проблемы?

Проблемы в том, что нативным плагином это не реализовано, а в коде в примерах/клиенте - js

Алгоритм считывания секрета - см. браузерный элемент формы <keygen> (надо и мне его потихоньку осиливать, shame on me). Начальный алгоритм криптографического преобразования вполне может быть загружен по SSL, с этим вообще проблем не вижу, любой нехомяк может открыть view-source или WebInspector и проверить, а затем вообще оффлайново сохранить или код криптоутилиты в localStorage записать.

Нене, ты не понял. Само собой от левых чуваков это прокатит. А вот если криптон тебя захочет пощекотать за яйца, он это без труда организует. Хоть и не может, как бе, читать твои секреты

А если эти задачи, ранее выполняемые на стороне сервера, теперь распределяются по клиентам с их никуда не выходящими ключами?

То мы упремся в банальный FTP+GPG.
Конечно эту связку мы можем как-то пафосно обозвать, да замутить донейты под это дело =)

Да, все верно. Покопался в коде серверной части и не нашел там никакой крипты, кроме функций аутентификации. Претензия только к документации, или почему мне для этого пришлось залезть в код?

Если грамотно продумать архитектуру, очистка всего localStorage без ведома пользователя незаметно не прокатит.

Только в том случае, если пользователь знает, что этого следует ожидать. Вобщем, все это печально, в любом случае. Контроль средства КЗИ заинтересованной стороной недопустим.

Сервис может работать только как API, принимать и отдавать пользователю зашифрованные данные.

и что полезного этот сервис сможет сделать с зашифрованными данными?

Сортировку и поиск он не сможет осуществлять, например