Прототип чата с шифрованием, что использовать?

У меня была немного схожая проблема, но не в виде чата, правда.

Я использовал SJCL bitwiseshiftleft.github.io/sjcl/demo/ для шифрования AES в браузере, так как без java апплетов и активХ ты к данным SSL сертификатов никакого доступа не получишь из клиентских скриптов.

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

Pravir Chandra, Matt Meiser, John Viega — Network Security with OpenSSL.

Nikos Mavrogiannopoulos, Simon Josefsson — GnuTLS.

Pravir Chandra, Matt Meiser, John Viega — Network Security with OpenSSL.

Nikos Mavrogiannopoulos, Simon Josefsson — GnuTLS.

Ты предлагаешь клиентам свой браузер с AlveToolbar'ом ставить? Если нет - то фейл катят.

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

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

Ты предлагаешь клиентам свой браузер с AlveToolbar'ом ставить?

Где в исходном сообщении хоть слово про браузер?

OTR

Почитайте про PGP подробней, все достаточно просто.
Два клиента генерируют пары открытый и закрытый ключ и обмениваются открытыми ключами. Такая процедура должна быть для каждого из контактов.
Сообщение шифруется вашим закрытым ключом и передается на сервер, клиент на другой стороне забирает сообщение и расшифровывает его открытым ключом полученным от вас. И в обратном порядке с парой ключей на другой стороне. Необходимо предусмотреть механизм автоматической замены ключей, дабы не быть поснифанным.

Само собой, в момент передачи - ключ можно соснифать.

Да хоть сам раздавай публичную часть ключа - толку от него?

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

И вдогонку вопрос: мне тут зал подсказывает, что это вроде как запрещено законодательно, ну т.е. использовать без лицензии шифрованную передачу данных и её хранение?

Хоть бы язык указал и фреймворк (если будешь юзать).

По поводу раздачи открытого ключа, где гарантия, что адресат передающий его неподдельный?

Что-то ты не дочитал... До двойного шифрования не дошёл?

Будь анархистом, зайди на https: //www.linux.org.ru/

Ничего не запрещено, что за глупости?

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

Речь шла о спуфинге открытого ключа... Решалось применением сертификата от третьего лица, либо шифрованием открытого ключа симметричным алгоритмом со всеми вытекающими.

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

Ключевое - доверительное соединение, среду предечи интернет такой назвать нельзя. Впрочем для задачи ТС, вполне может оказаться достаточным и простое решение, на крайний случай на сервере можно держать токен.

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

Да не просто, но возможно. Как я уже писал, врятли кому-то будет нужно. Не банк клиент же.

что это вроде как запрещено законодательно

Что за бред? Хватит мифы форсить, затруднись выяснить - чего касаются соотвествующие статьи и их цель.

https://www.coursera.org/course/crypto , сильно сокращать если обучение, - ошибок наделаете в том, как используете криптографию, а любая ошибка в криптографии - сродни отсутствию криптографии ;)

man otr.

OTR

Я уже делаю это, подключайся к проекту:
https://github.com/Novator/Pandora

При выборе СКЗИ остановился на OpenSSL.

Из ассиметричного шифрования сейчас реализовано RSA.
Из симметричного AES и BlowFish.

а чем не устраивают существующие решения?

А можно поподробнее об этом?

libotr