OTR Messaging: "Незаписываемая переписка"
Вам это понравится.
Никита Борисов и Иан Голдберг выпустили программу Off-the-Record Messaging. Это плагин для GAIM, обеспечивающий защищённую IM-переписку. Внимания заслуживает не столько этот факт, сколько особые свойства программы:
— шифрование сообщений
— аутентификация собеседников
— perfect forward secrecy
— возможность отречения (!)
PFS достигается благодаря эфемерным ключам, согласуемым по Диффи-Хеллману. Даже если текущий ключ будет скомпрометирован, секретность прежней и будущей переписки не пострадает.
Последнее свойство особенно интересно. Обычно аутентификация производится с помощью ЭЦП, но это жёстко привязывает человека к написанным словам: впоследствии он не сможет отказаться от сказанного, поскольку его сообщения заверены его закрытым ключом (этот ключ был известен ему одному).
С OTR ситуация иная. На нижнем уровне протокола с помощью закрытых ключей аутентифицируется MAC-код каждого из собеседников (MAC, или имитовставка, — это хэш-значение, зависимое от сообщения и симметричного ключа). Сами же передаваемые сообщения аутентифицируются с помощью этих MAC'ов (так каждый собеседник может быть уверен в аутентичности и целостности полученного сообщения). А раз оба собеседника знают MAC-коды друг друга, то даже если один из них решит опубликовать протокол переписки, он не сможет доказать, кто писал какие сообщения. Более того, после окончания сеанса переписки каждый из контрагентов может опубликовать MAC-коды в Сети, а раз они опубликованы, то данную беседу мог провести любой.
Вот такая хитрая штучка для тех, кто не хочет быть пойманным за язык. ;)
Версия плагина есть только под Debian или Fedora Core Linux.
комментариев: 225 документов: 8 редакций: 2
Кто-нибудь эту штуку использовал? Пробовал ли OTR прокси с Tor совмещать?
комментариев: 112 документов: 8 редакций: 15
комментариев: 1515 документов: 44 редакций: 5786
© http://www.cypherpunks.ca/otr/Protocol-v2-3.1.0.html
Штука интересная, но больше похожа не детскую поделку.
Видать, не доходит до многих, что писать опознавающие сигнатуры есть зло. Каждый пакет, блин метят через "OTR".
Как понял, у них только 128-битный аес, а это это неучитывает атаки по отношению к КК (сделали хотя бы 256, что есть в стандартных библиотеках).
Ставить gaim только ради OTR... он же не консольный :((
В описании протокола много всякой требухи в стиле домножений, возведений в степень и т.д., а вдруг они не специалисты в крипто, тогда превратится в домашнюю поделку. /me не разбирается, но есть мнение что существующие стандартные библиотеки для ифрования позволяют забыть о подобных действиях... или они решили переписать?
P. S.: раньше видел этот сайт, но тогда идей не было зачем это нужно. А когда появились идеи, забыл что был такой сайт. Спасибо за ссылку.
комментариев: 112 документов: 8 редакций: 15
Есть еще OTR proxy. Собрал я его для посмотреть. Но он тоже не консольный. И джаббер не поддерживает. Посему фтопку.
комментариев: 112 документов: 8 редакций: 15
libotr и otrproxy линкуются со стандартной GNUшной библиотекой libgcrypt.
http://www.xmpp.org/extensions/xep-0116.html
комментариев: 11558 документов: 1036 редакций: 4118
Ну, блин, исходники же открытые!
Это пока!
"The current version is 0.3.1, which means it's still a long way from done."
комментариев: 112 документов: 8 редакций: 15
Последний релиз otrproxy датируется 2005-11-03.
комментариев: 112 документов: 8 редакций: 15
А не кажется ли Вам, что данная ситуация имеет тот же класс эквивалентности, что и использование асимметричного крипто без опубликования открытых ключей (обмен открытыми ключами происходит по третьему каналу)?
Еще задачка: а можно ли построить схему использования асимметрии для согласования симметричного сессионного ключа при наличии на канале пассивно слушающего оппонента, обладающего квантовым компьютером и соответствующими открытыми ключами?
Не специалист в криптографии, так что прошу сильно не пинать.
комментариев: 83 документов: 4 редакций: 4
Если же время взлома сопоставимо с временем генерации – ассиметричная криптография приказывает долго жить. Во всяком случае сегодняшние алгоритмы.
Все остальные схемы (типа использования скрытых каналов для передачи дополнительной ключевой информации) в конце концов сводятся к личному обмену ключами.
Участники высказались за то, что симметричное шифрование лучше асимметричного если принимать угрозу КК (более надёжно, более устойчиво к криптоанализу). Также произносились слова unknown'а о том, что в перспективе сделают асимметрию устойчивой к КК, но пока только идут разговоры и исследования, а принципиальных причин неосуществимости указанного нет. В силу того, что движителем "прогресса" является коммерция, где ценность информации исчезает по прошествии небольшого промежутка времени (со слов SATtva'ы), массовой заинтересованности в криптографии, устойчивой с учётом атак, применимых в будущем, не наблюдается. Грубо говоря, никого не напрягает тот факт, что через каких-то, может быть, 50 лет вся его переписка будет прочитана по первому требованию (открытый ключ, используемый в сообщении, известен, а найти его можно на сервере ключей. Время расшифрования с помощью КК займёт мало времени).
Это как раз речь о том, что уже написал. Разработки идут, ищут оптимальные алгоритмы, исследуют их, сделают когда-нибудь, но совсем не торопятся. Текущее большинство вполне устраивает тот факт, что
- Авторство каждого поста можно проверить независимо.
- Ваш собеседник в принципе может конструктивно доказать что именно вы писали ему то что вы писали, выдав ваши подписанные сообщения после их расшифрования своим ключом.
- По прошествии некоторого времени вся асимметрично зашифрованная информация будет легко расшифрована.
Итог: схема PGP-шифрования/подписи в её стандартном ракурсе вполне подходит для защиты коммерческих секретов, а вот личных... это бААльшой вопрос...комментариев: 112 документов: 8 редакций: 15
Это если использовать исключительно асимметричное крипто, причем в том виде, в котором оно есть сейчас.
А если применить комбинацию приёмов?
Что приходит в голову:
1. Секретом может быть протокол согласования симм. ключей П = П(xij)
2. Секретом могут быть xij
3. Может быть замаскирован сам факт того, что происходит согласование ключей.