В гугле забанили?

https://code.google.com/p/crypto-js/

Я эту ссылку видел. Оно умеет обращаться к локальному хранилищу сертификатов и ключей?

плугин нужен

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

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

расскажи КАК? Смысл асимметричного шифрования в том и заключается, что открытым ключом можно ТОЛЬКО ШИФРОВАТЬ. Т.е. вражеский сервер не сможет прочитать даже то, что он для тебя зашифровал. Стянуть ключ можно только вирусом или внедрённым в локалхост плагином с бекдором.

и мог расшифровать его в браузере с помощью установленного ключа

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

Это JavaScript. Код, который должен выполняться в браузере пользователя, контролируется непосредственно сервером.

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

А если абстрагироваться от безопасности и паранойи (пусть всё это будет работать исключительно на локалхосте и представляет академический интерес) - такое реализуемо?

В основном библиотеки криптографии ассоциируются с инициативами гугла и некоторыми реализациями хешей, hmac. Для gecko-based браузеров есть библиотеки расширений. Ну и возможности встроенные на базе персональных и нет сертификатов. По крайней мере в мозилле.

и мог расшифровать его в браузере с помощью установленного ключа

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

как раз можно и нужно.

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

ничего не мешает. А кто тебя заставляет всё шифровать одним и тем же ключом? Шифруй всё разными. А ещё лучше — шифруй всё случайным числом, которое генерится тобой каждый раз заново. Тогда вражеский сервер тебя даже не сможет идентифицировать, даже если ты там час назад уже был.

И да, определись: от кого ты шифруешься-то? Где именно враги, и зачем тебе нужна криптография?

А если абстрагироваться от безопасности и паранойи (пусть всё это будет работать исключительно на локалхосте и представляет академический интерес) - такое реализуемо?

какое «такое»? Добавить кусок в JS на локалхосте, который сливает пароли сделанные в локалхосте в локалхост? Да, возможно.

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

Такое - это не гонять user data от сервера клиенту в браузер, а гнать шифртекст, а расшифровывать на стороне клиента. И да, я знаю про https, но хочется построить систему, где сервер не может иметь даже теоретического доступа к user data, так как оно попадает на сервер уже зашифрованное

где сервер не может иметь

Тогда доступ к хранилищам ключей браузера будет только опасен, лучше взять xor и одноразовые блокноты, за вечер на яваскрипте любой слабоумный регистрант осилит.

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

бред какой-то. Кто это сказал? Аргументируй хоть свои фантазии.

бред какой-то.

нет

Кто это сказал?

оторвись от шваброшвабра и форумчиков с примитивными проблемками

Аргументируй хоть свои фантазии.

самому подумать не судьба?

Такое - это не гонять user data от сервера клиенту в браузер, а гнать шифртекст, а расшифровывать на стороне клиента. И да, я знаю про https, но хочется построить систему, где сервер не может иметь даже теоретического доступа к user data, так как оно попадает на сервер уже зашифрованное

ну это возможно. Теоретически. Практически это не реализовано AFAIK, но можно юзать сторонние костыли. Например прогонять через gnupg предварительно. Я так делаю с яндекс-диском, шифрую локально, и отправляю туда зашифрованное. Естественно на этом ЯД нету никаких ключей. А TLS конечно есть, но только лишь потому, что я не знаю как его отключить, да и знать не хочу.

В браузере тоже можно такое замутить, теоретически. Хотя не очень понятно, кому и зачем это надо.

самому подумать не судьба?

начни с себя. Подумай, к чему ты призываешь своей истерией и паранойей? Что-бы все всё кидали в сеть не подписанное и не шифрованное? Типа «всё общее»? Что-бы можно было кого угодно послать нах прикрываясь своей анонимностью, да? Ну и что означает твоя отсылка нах? НИЧЕГО. Потому что ты никто и звать тебя никак. Твои слова ничего не стоят, и на твоё веское мнение всем насрать. Потому что всем очевидно, что ты можешь сейчас агитировать за iMac©, а через минуту за Windows™.

Эти твои слова «повсюду трояны» — глупая сказка для дебилов. Я знаю продолжение: «всё равно хакеры всех поломают и всё украдут, потому компьютеры не нужны, а деньги несите к нам на ***™». Неужели ты вправду думаешь, что на эту твою тупенькую рекламу поведётся кто-то кроме школьников, у которых всё равно нет денег? Особенно за подписью «я говно безымянное».

Кому и зачем надо? Например, чтобы сделать нечто типа lastpass, только без установки плагинов и прочей фигни. Открыл бразуер - и работает. У пользователя в браузере понятные буковки, до сервера шифробелиберда долетает только. Полезно для любого сервиса, которому пользовательские данные не надо обрабатывать никак, только хранить и показывать. Те же IDE и текстовые редакторы в браузере, например (разве что если к IDE среда исполнения прикручена, так не выйдет)

Что-бы все всё кидали в сеть не подписанное и не шифрованное?

приведи мою цитату, где я об этом написал? Я говорю о том, что страница не должна иметь доступа к хранилищам ключей браузера, и как мы наблюдаем, этого мнения придерживаются разработчики браузеров, которые эту возможность не реализуют. Зато мы отчётливо видим, что для работы страницы с ключами пользователей создана тьма тьмущая апплетов и браузерных плугинов. Остальной абац — демонстрация твоей уязвлённой ущербности.

Эти твои слова «повсюду трояны» — глупая сказка для дебилов.

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

А я не одинок: http://stackoverflow.com/questions/12764725/browser-based-encryption-decrypti...

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

а теперь включи мозг, и подумай, зачем это надо google.com? Так у них есть огромная БД исходников и разных приватных документов. А по твоему у них будет билиберда. Пчёлы против мёда?

приведи мою цитату, где я об этом написал?

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

Я говорю о том, что страница не должна иметь доступа к хранилищам ключей браузера

ОК, пусть не имеет. Я разве против? Можно сделать плагин, который имеет своё хранилище ключей.

и как мы наблюдаем, этого мнения придерживаются разработчики браузеров, которые эту возможность не реализуют. Зато мы отчётливо видим, что для работы страницы с ключами пользователей создана тьма тьмущая апплетов и браузерных плугинов. Остальной абац — демонстрация твоей уязвлённой ущербности.

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

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

зачем это мне? Тебе нужно, ты и мучайся.

я мудак

да, всё остальное — чушь.

А теперь включи мозг и подумай: я спрашиваю google.com или где?

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

Что может послужить компроментацией данных:

• Незащищенный канал передачи JS от сервера (обычный HTTP без шифрования, самоподписанный сертификат (с оговорками)).
• Инъекция зловредного JS сервером владельцами
• Инъекция зловредного JS любым сторонним сервером, JS которого подключается на странице (привет соц.виджетам, библиотекам прямо из cdn, счётчикам, капчам и прочему)
• Атака MitM, например, через подставной сертификат, выданный центром сертификации (уже были случаи).
• XSS
• Взлом сервера ВНЕЗАПНО компроментирует данные, так как злоумышленник тоже может незаметно сделать инъекцию JS и стянуть ключи всех юзеров.
• Уязвимость в браузере, когда сторонний скрипт сможет несанкционированно получить доступ к локальному ключу, опять же, уже были такие уязвимости.

В общем, для любого безопасника ясно, что такая схема только делает видимость защиты данных клиента, но непригодна для чего-либо серьёзного.

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

Более того, по такой схеме работает одиозный файлообменник — Mega https://ru.wikipedia.org/wiki/Mega

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

А теперь включи мозг и подумай: я спрашиваю google.com или где?

а что я тебе отвечу? Ты будешь юзать emulek.docs? Думаю — вряд-ли. Скорее google.docs. Как и все остальные.

Но я повторюсь, все эти уверения, что сервер не может получить доступ к данным — чушь.

не совсем. Теоретически это возможно. На практике это тупо никому не нужно.

Валидность ключа можно проверить выбрав несколько рандомных клиентов например, и запросить подтверждение у них. Шифровать можно только локально, и только плагином(а не JS конечно).

Про JS я согласен, оно и небезопасно(никак), и с быстродействием проблемы.

На практике это тупо никому не нужно.

На практике за такие отмазки безопасника могут и вые^W наказать или уволить.

На практике за такие отмазки безопасника могут и вые^W наказать или уволить.

за какие? За использование браузера со своим сервером и со своим плагином? Что в этом опасного? Учитывая естественно TLS(возможно с самоподписаным сертификатом).

Тогда предложи архитектуру, при которой сервер гарантированно не имеет доступа к тому, что хранит. Я имею ввиду, что сервер не может извлечь семантику хранимых данных.

Повторюсь, это носит академический характер

Любая архитектура, где серверу не позволено передавать клиенту код, который при исполнении на клиенте имеет доступ к данным (будь то куки/LSO или даже полноценный доступ к ФС).

Т.е., с этим справится плагин к браузеру (хотя мне лично это не нравится), или же полноценное клиентское приложение, которое общается с сервером по определенному протоколу (будь то RESTful, WebSocket или даже UDP).

Архитектура обычная, клиент-сервер. Только клиент должен быть самодостаточным.

а какие? За использование браузера со своим сервером и со своим плагином? Что в этом опасного? Учитывая естественно TLS(возможно с самоподписаным сертификатом).

А я не уточнял, что речь _обязательно_ идёт про свой сервер и свой плагин.

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

Это понятно и такие системы я знаю. Хочу браузер в качестве клиента

Твоё дело. Я тебя предупредил про дыры.

Так во итоге: можно ли из js добраться до ключевого хранилища?

ключевого хранилища

Уточни.

К хранилищу ключей в браузере