Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Релиз свободного безопасного VPN-демона GoVPN 2.0, opennews (??), 12-Мрт-15, (0) [смотреть все] А область применения у него какая , SHRDLU (ok), 07:06 , 13-Мрт-15, (7) // Защита своего неотчуждаемого права на приватность от MitM-преступников , Аноним (-), 08:16 , 13-Мрт-15, (8) +5 // Для этого лочичнее всего поставить впн на каком-нибудь роутере А фиговина на go, Аноним (-), 08:24 , 13-Мрт-15, (9) –6 // Какой-то роутер с бекдорами , Аноним (-), 13:41 , 13-Мрт-15, (28) +1 Зачем же с бэкдорами, прошивку надо нормальную лить Тот же опенврт например , Аноним (-), 15:33 , 13-Мрт-15, (33) Убеждение чудаков в возможности иметь свободный безопасный инет ессно , dfafverv (?), 02:07 , 15-Мрт-15, (86) А что не на pure ANSI C , Аноним (-), 08:31 , 13-Мрт-15, (10) // Не модно, не стильно и не молодежно , Аноним (-), 09:50 , 13-Мрт-15, (12) +1 // Тот неловкий момент когда один из создателей С - Брайан Уилсон Керниган занимает, Аноним (-), 13:08 , 13-Мрт-15, (26) +2 // Но что из этого следует Керниган занимался разработкой awk, например По факту, Stax (ok), 18:03 , 13-Мрт-15, (47) По моей логике - нет, на awk не надо А вот на Go - надо, Вася W Stax - надо Пос, Аноним (-), 00:07 , 14-Мрт-15, (58) Дожили, баги у хипстоты даже в восторгах А зачем там Go В впн ничего и нет кром, Аноним (-), 12:52 , 14-Мрт-15, (70) Чего тут неловкого то От одного уродца к другому дорога не сложна , dfafverv (?), 02:39 , 15-Мрт-15, (89) –2 Потому что перпендикуляр W HEARTBLEED , Аноним (-), 10:39 , 13-Мрт-15, (13) –1 // И каким образом Go поможет подобного избежать , Аноним (-), 12:38 , 13-Мрт-15, (24) // Дак хипстота же не знает про существование кучи, стека, регистров и прочее и со, Аноним (-), 12:52 , 13-Мрт-15, (25) Сорцы даны по ссылке Укажи в каком месте ты нашел проблему Не укажешь - твоё очк, Аноним (-), 16:58 , 13-Мрт-15, (40) Мне хватило того что один из этих совковых циферпанков сосватал мне фрибсдшный г, Аноним (-), 19:35 , 13-Мрт-15, (53) играет музыка прощание пЫoнЭpa с очкoм И д и о т дeтeктед Просто , Аноним (-), 00:14 , 14-Мрт-15, (59) Ого, вот это бомбануло даже с музыкой , Аноним (-), 12:53 , 14-Мрт-15, (71) Ты еще манифест на их сайте не читал Там ошибка на ошибке, глаза сломать мож, Аноним (-), 00:14 , 15-Мрт-15, (85) У хипстера бомбануло , Аноним (-), 20:40 , 13-Мрт-15, (56) Простите, чтобы спасти своё очко, вы мне предлагаете нырнуть в бочку с жидкими ф, Аноним (-), 21:33 , 14-Мрт-15, (84) Почему то я уверен что вы программируя постоянно со списком регистров сверяетесь, dfafverv (?), 02:45 , 15-Мрт-15, (90) –1 - Не знаешь термодинамику - не занимайся разработкой двигателей - Не знаешь элек, Аноним (-), 18:22 , 16-Мрт-15, (104) В Go нет арифметики указателей , Аноним (-), 07:17 , 18-Мрт-15, (106) Я джва года ждал такой демон , Аноним (-), 10:43 , 13-Мрт-15, (14) +3 Осталось FreeBSD переписать на Go Ядро меньше линуксовового на порядок , iZEN (ok), 10:54 , 13-Мрт-15, (15) –4 // Менеджер памяти включая сборщик мусора придётся писать заново если не на Си, т, Аноним (-), 11:03 , 13-Мрт-15, (16) –2 Так перепиши, тебя послушать - делов то с рыбью ногу Кстати, а не знаешь почему, Аноним (-), 11:12 , 13-Мрт-15, (17) // Знаю 8212 из-за отсутствующего или посредственного контроля типов данных в яз, iZEN (ok), 22:50 , 13-Мрт-15, (57) –1 // Фуяк-фуяк и в продакшен это к джаве и гоу Знаешь чем хорош Си Он делает ТО, ЧТ, Аноним (-), 00:19 , 14-Мрт-15, (61) +1 Жабисты протестуют www techempower com benchmarks section data-r9 hw i7 test pl, Аноним (-), 00:35 , 14-Мрт-15, (62) Ты не поверишь Web-сервера на Java только ленивый не писал Во всех Java EE о, iZEN (ok), 00:45 , 14-Мрт-15, (63) –1 Ну ок, но что-то я все равно не вижу ядер ОС на Go и джаве Ну или там файловых , Аноним (-), 00:54 , 14-Мрт-15, (66) www jnode org, iZEN (ok), 01:11 , 14-Мрт-15, (68) –1 Ну и как зохватили мир ограбили караваны Угу И не светит -р, Аноним (-), 05:18 , 14-Мрт-15, (69) Все особенности языка си от безграмотности его авторов и от возможностей подобра, dfafverv (?), 02:26 , 15-Мрт-15, (87) –1 Не верно Ссылки не заменяют указатели, а лишь дополняют Например, указатели мо, Аноним (-), 15:12 , 15-Мрт-15, (93) Зато ссылки можно копировать и передавать копии ссылок Внутри методов переданно, iZEN (ok), 17:11 , 15-Мрт-15, (96) –2 Изя, ты такой баклан Какие методы копий ссылок в ANSI C Memory leak, ага А, Аноним (-), 18:13 , 15-Мрт-15, (97) +1 Представляю как у тебя шаблон порвёт, когда ты узнаешь про void , Аноним (-), 18:22 , 15-Мрт-15, (99) Это я изе, не тебе, Аноним (-), 18:22 , 15-Мрт-15, (100) Скажи честно, ты идиот Ссылка это просто константный указатель Конкретно про п, Аноним (-), 23:28 , 15-Мрт-15, (102) +1 Вообще-то современные компиляторы си задолбают варнингами, а то и еррорами, если, Аноним (-), 12:59 , 14-Мрт-15, (72) +1 cmp reg, lowerjl OutOfBoundscmp reg, higherjg OutOfBoundsВпрочем понятно что вам, dfafverv (?), 02:38 , 15-Мрт-15, (88) –1 Чё за бред Ты вообще линуксового ведра не видел , Аноним (-), 11:37 , 13-Мрт-15, (19) –1 // А вот тут Зеня не соврал Linux 8212 около 17 миллионов строк кода https www, Аноним (-), 12:01 , 13-Мрт-15, (21) –1 // Это да 17 больше 13, но не на порядок, soarin (?), 13:12 , 13-Мрт-15, (27) Linux только ядро занимает 13, а FreeBSD ВСЯ система со всеми сервисами и компил, iZEN (ok), 00:48 , 14-Мрт-15, (65) –1 Какая часть из этого дрова и всякие файловые системы и чего из этого в линуксе б, Аноним (-), 13:44 , 13-Мрт-15, (29) +1 Ну дык дрова и всякие ФС тоже придётся переписывать , Аноним (-), 15:31 , 13-Мрт-15, (32) 13 мильенов - это если с базой А так, само ведро меньше - 4 с половиной миллион, anonym0use (?), 00:48 , 14-Мрт-15, (64) Ну ок, и где тут на порядок Не пора ли уже признать что изен спи л вместо т, Аноним (-), 13:00 , 14-Мрт-15, (73) –1 Бздуны, знайте, у вас в тылу засланный M казачок , Аноним (-), 16:17 , 13-Мрт-15, (37) +2 // Да не M , а гуглом же M бы C советовал Хотя у гугла всё же хватает ума не исп, Аноним (-), 16:46 , 13-Мрт-15, (39) // И вообще Go - это не дяра печь, это для того для чего жабба и C Так что пуст, Аноним (-), 17:01 , 13-Мрт-15, (41) Btw, отечественные циферпанки зарекомендовали себя теми еще ламерами в шифрова, Аноним (-), 11:14 , 13-Мрт-15, (18)   // А что не так с OTR , Аноним (-), 12:19 , 13-Мрт-15, (23) +2   // а OTR это не тали самая штука, типа чат, в котором всё зашифровано но при этом, Xasd (ok), 15:14 , 13-Мрт-15, (31) –2   // Эти же шифропанки из Канады вместе с OTR поставляют и SMP zero-knowledge провер, Sergey (??), 17:13 , 13-Мрт-15, (44)   С практической точки зрения людям которые немного разбираются проще всего провер, Аноним (-), 19:26 , 13-Мрт-15, (48)   Fingerprint-ы это как правило хэш от ключей Хэш это уже утечка информации о них, Sergey (??), 19:51 , 13-Мрт-15, (55)   А любые публичные ключи наверное тогда вообще полный пи ц Ведь там даже не хэ, Аноним (-), 13:16 , 14-Мрт-15, (74)   Пользователь с другой стороны знает -- отлично А человек по-середине не должен , Sergey (??), 13:34 , 14-Мрт-15, (76)   Так изначально неизвестно кто с той стороны - MITM или легитимный пользователь , Аноним (-), 15:29 , 15-Мрт-15, (94)   В OTR -- да В zero knowledge системах и активный атакующий не сможет Если не яс, Sergey (??), 16:46 , 15-Мрт-15, (95)   В OTR это можно при сильном желании зарубить Например, вкостылив политику 1 ко, Аноним (-), 13:31 , 16-Мрт-15, (103)   Там можно аутентифицировать собеседников несколькими разными способами Но в рез, Аноним (-), 19:32 , 13-Мрт-15, (51)   API, реализация -- это одно А сам протокол вполне себе хорош , Sergey (??), 19:38 , 13-Мрт-15, (54)   Мне не понравилось Сложный и по мере набивания шишек накостылировано почти как , Аноним (-), 13:17 , 14-Мрт-15, (75)   Сложный Вы про протокол или реализацию Если про протокол, то приведите пример , Sergey (??), 13:36 , 14-Мрт-15, (77)   И то и другое К третьей версии оно здорово обрасло всевозможными подпорочками , Аноним (-), 14:54 , 14-Мрт-15, (79)   p s неприятным бонусом OTR является наличие характерных сигнатур в каждой дырке, Аноним (-), 14:59 , 14-Мрт-15, (80)   Именно поэтому людям и пытаются рассказать про подобные инструменты Увеличить a, Sergey (??), 15:05 , 14-Мрт-15, (82)   Для начала, то как это сделано - позволяет очень просто и дешево по ресурсам обн, Аноним (-), 21:03 , 14-Мрт-15, (83)   Ну у меня работало с людьми нормально Не всегда с первого раза, но быстро оп, Sergey (??), 15:03 , 14-Мрт-15, (81)   Сложный и костыльный И апи у него такое же Вырос почти в openssl, только под д, Аноним (-), 15:35 , 13-Мрт-15, (34)   // А чем тогда пользоваться Какие реальные альтернативы Торообразных не предлага, Аноним (-), 01:06 , 14-Мрт-15, (67) +1   vpn без скрамблера сейчас уже становится не актуален, Аноним (-), 12:06 , 13-Мрт-15, (22) // Хорошее шифрование от рандома отличить невозможно Хотя автор конкретно вот этой, Аноним (-), 15:35 , 13-Мрт-15, (35) // Процитирую из документации Each transport message is indistinguishable from pse, Sergey (??), 17:17 , 13-Мрт-15, (45) // А как насчет вон тех сообщений в начале сессии Если DPI прочухает в самом начал, Аноним (-), 19:28 , 13-Мрт-15, (49) Да, пока это под вопросом Handshake пакеты оканчиваются на нули Тут надо думат, Sergey (??), 19:34 , 13-Мрт-15, (52) Было бы совсем круто если бы эмулировался http траффик, а в него методом стегано, Аноним (-), 12:21 , 15-Мрт-15, (91) Опция , Аноним (-), 12:22 , 15-Мрт-15, (92) а средства для идентификации сервера , Xasd (ok), 15:12 , 13-Мрт-15, (30) –1 // Клиентов много, сервер один Он и так будет аутентифицирован по PSK А PSK у каж, Sergey (??), 13:38 , 14-Мрт-15, (78) Пишут так, как будто это что-то хорошее , Аноним (-), 16:14 , 13-Мрт-15, (36) // Потому что это - хорошее , Аноним (-), 17:02 , 13-Мрт-15, (42) // с точки зрения хипстоты , Аноним (-), 19:29 , 13-Мрт-15, (50) –4 // Тебе за твоих виднее -рА Go действительно хорошее Просто надо понимать куда ег, Аноним (-), 00:19 , 14-Мрт-15, (60) gt оверквотинг удален Как-же интересно участники обмена должны ключами обменив, Легион (?), 16:25 , 13-Мрт-15, (38) // Никак Читай доки внимательно С , Аноним (-), 17:03 , 13-Мрт-15, (43) Подходите к вашему системному администратору и получаете ключ id на флешке бумаж, Sergey (??), 17:19 , 13-Мрт-15, (46) написать на Go что-то не работающее в Windows и Mac -- надо ухитриться авторы ил, й (?), 18:50 , 15-Мрт-15, (101) –1 Я что-то пропустил , Аноним (-), 18:24 , 16-Мрт-15, (105) –1 7,10,14,15,18,22,30,36,38,101,105

Сообщения

[Сортировка по времени | RSS]

18. "Релиз свободного безопасного VPN-демона GoVPN 2.0"	+/–
Сообщение от Аноним (-), 13-Мрт-15, 11:14
Btw, отечественные "циферпанки" зарекомендовали себя теми еще ламерами в шифровании и прочем. Еще хуже канадских, наворотивших OTR.
Ответить | Правка | Наверх | Cообщить модератору

	23. "Релиз свободного безопасного VPN-демона GoVPN 2.0"	+2 +/–
	Сообщение от Аноним (-), 13-Мрт-15, 12:19
	А что не так с OTR?
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Релиз свободного безопасного VPN-демона GoVPN 2.0"	–2 +/–
	Сообщение от Xasd (ok), 13-Мрт-15, 15:14
	> А что не так с OTR? а OTR это не тали самая штука, типа чат, в котором всё зашифровано.. но при этом не ясно -- с кем ты общаешься -- со своим другом или с ФСБ-шником? :-)
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Релиз свободного безопасного VPN-демона GoVPN 2.0"	+/–
	Сообщение от Sergey (??), 13-Мрт-15, 17:13
	Эти же шифропанки из Канады вместе с OTR поставляют и SMP: zero-knowledge проверку идентификации. С этим SMP пользователи смогут друг друга аутентифицировать. И просто включённый OTR во многих клиентам громко кричит что соединение безопасно, но не аутентифицированно.
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Релиз свободного безопасного VPN-демона GoVPN 2.0"	+/–
	Сообщение от Аноним (-), 13-Мрт-15, 19:26
	С практической точки зрения людям которые немного разбираются проще всего проверить фингерпринты. Остальные варианты - ими как-то сложно пользоваться на практике из-за высокого риска ошибок в легитимных случаях. А кто совсем не разбирается - ему ничего не поможет. А вот наворочено все получилось неимоверно. Проаудитить код OTR нынче не сильно проще чем перечитать openssl. А это плохо для криптографии.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Релиз свободного безопасного VPN-демона GoVPN 2.0"	+/–
	Сообщение от Sergey (??), 13-Мрт-15, 19:51
	> С практической точки зрения людям которые немного разбираются проще всего проверить фингерпринты. Fingerprint-ы это как правило хэш от ключей. Хэш это уже утечка информации о них. Это не zero-knowledge система. То есть возможна атака когда мы создадим например публичный асимметричный ключ с таким же fingerprint-ом.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Релиз свободного безопасного VPN-демона GoVPN 2.0"	+/–
	Сообщение от Аноним (-), 14-Мрт-15, 13:16
	> Fingerprint-ы это как правило хэш от ключей. Хэш это уже утечка информации о них. А любые публичные ключи наверное тогда вообще полный пи...ц? Ведь там даже не хэш а целиком ключ бывает. И если что - ремота в OTR знает fingerprint ключа другой стороны. А если чуть попроще мыслить - там где OTR требуется, отправитель и получатель как правило и так известны на уровне протокола. Если б протокол заботился об этом моменте - OTR поверх него элементарно не требовался бы. По поводу чего о какой-то особой анонимности в случае OTR речь как правило не идет. Только о защите содержимого от чтения. > Это не zero-knowledge система. Если мы вообще ничего не знаем о ремоте - то и отличить от MITM не сможем. Поэтому заявления про zero knowledge лишь попытка замаскировать проблему. В результате все приходит к еще более сложному формату чем проверка фингерпринта. А так можно проверять не фингерпринт а например какой-то дериватив от текущегшо временного ключа шифрования, по типу хэшей. Если ключи будут разными (т.е. MITM проксирует в обе стороны) - MITM попался. И сравнить 2 числа с разных сторон линка - может даже обезьяна. А всякие заморочки с совместно знаемым заранее ответом на вопрос... блин, перцы, если у меня уже есть shared secret с ремотой - зачем мне вообще диффи-хеллманы и публичная криптография вообшще, интерсно? Можно втупую симметричное шифрование вкатить и не заморачиваться :) > То есть возможна атака когда мы создадим например публичный асимметричный > ключ с таким же fingerprint-ом. Для этого надо или найти коллизии в функции хэширования и там будет много иных проблем, или же атакующий должен угадать приватный ключ. А это уже поимение.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Релиз свободного безопасного VPN-демона GoVPN 2.0"	+/–
	Сообщение от Sergey (??), 14-Мрт-15, 13:34
	> А любые публичные ключи наверное тогда вообще полный пи...ц? Ведь там даже > не хэш а целиком ключ бывает. И если что - ремота > в OTR знает fingerprint ключа другой стороны. Пользователь с другой стороны знает -- отлично. А человек по-середине не должен. В данном случае вы сливаете то что можно будет подобрать (хэш). > блин, перцы, если у меня уже есть shared secret с > ремотой - зачем мне вообще диффи-хеллманы и публичная криптография вообшще, интерсно? > Можно втупую симметричное шифрование вкатить и не заморачиваться :) Вот на этом и закончим этот тред. DH нужен для установления сессионных одноразовых ключей, чтобы при компрометации shared ключа нельзя было дешифровать ранее перехваченный трафик. Свойство это называется perfect forward secrecy. Более того: как вы аутентифицируете противоположную сторону при установлении соединения? Будете просто посылать сразу данные, ведь всё-равно их дешифровать не смогут, сливая факты возникновения пакетов и их размеры? Без всего этого можно обойтись, но для кого-то тот же PFS штука обязательная. Если аутентифицировать противоположную сторону (есть симметричные алгоритмы для этого), то найдутся и симметричные алгоритмы для установления сессионного ключа: но зачем когда есть довольно быстрый curve25519 уже? > Для этого надо или найти коллизии в функции хэширования Верно. Но эта возможность остаётся. Тогда как в zero knowledge системах нет.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Релиз свободного безопасного VPN-демона GoVPN 2.0"	+/–
	Сообщение от Аноним (-), 15-Мрт-15, 15:29
	> Пользователь с другой стороны знает -- отлично. А человек по-середине не должен. Так изначально неизвестно кто с той стороны - MITM или легитимный пользователь. И большинстве практически существующих применений - MITM может запросто получить fingerprint. Просто начав с пользователем OTR новую сессию как новый пользователь, например. Так даже сервер на автомате может fingerprint получать, если захочет. Как раз удобные хидеры везде для ненапряжного обнаружения OTR'а в остальном траффике :) Как я понимаю, в OTR фингерпринт ключа не виден лишь пассивному наблюдателю. Но те кто проводит активные атаки (mitm перехвативший первую сессию, или просто некто лишний, иициирующй OTR сессию с того же сервера) без особых проблем узнают fingerprint. А что им помешает то? > В данном случае вы сливаете то что можно будет подобрать (хэш). Ну если уж на то пошло - можно и приватный ключ подобрать, и отдельные части DH - восстановить, решив проблему дискретного логарифмирования (или что там выбрано базой в энном подвиде DH). Вопрос сводится сложности задачи. Чего ради поиск коллизий в качественной функции хэширования декларируется более простой задачей? Откуда это следует? > Вот на этом и закончим этот тред. DH нужен для установления сессионных > одноразовых ключей, чтобы при компрометации shared ключа нельзя было дешифровать ранее > перехваченный трафик. Ну если 1 раз секретным дуплом можно пользоваться, то наверное можно и 2 раза. Изничтожив старый ключ. Получится PFS с ручным приводом. DH хорош тем что позволяет снизить требования в плане дупел и автоматизирует процесс. Но вот рассуждения про zero knowledge и buzz вокруг оного мне малопонятен. На практике обоим сторонам линка надо знать некий shared secret, что по сути является вариантом на тему секретного дупла. И на практике то как это в OTR сделано - я вообще не очень понимаю как этим можно воспользоваться и чтобы это еще и работало. А код распух изрядно, да и весь протокол. > Свойство это называется perfect forward secrecy. Спасибо, Кэп. Я в курсе. Но кажется немного увлекся с утрированием. > Более того: как вы аутентифицируете противоположную сторону при установлении соединения? Будете просто > посылать сразу данные, ведь всё-равно их дешифровать не смогут, сливая факты > возникновения пакетов и их размеры? Факт возникновения пакетов - всяко будет виден даже пассивному наблюдателю в канале (хоть тому же серверу, который сообщения между пользователями OTR посылал). Если это не нравится - это уже заявка на какую-то стеганографию и серьезное "кондиционирование" траффика. В otr этим никто не заморачивался особо и это уже заявка на более другие подходы, имхо. Сервер (пассивный сниффер, ...) видят времянки и примерные размеры. И факт что Вася и Петя сообщения кидали (за счет большинства протоколов поверх которых OTR запускался). Хоть и шифрованные OTR (для полного счастья там еще и хидеры характерные долеплены, чтобы никто не сомневался). В результате даже пассивный сниффер получает не так уж и мало информации как могло бы в принципе хотеться Васе и Пете. Так что насчет свойств - истинный параноик всегда будет недоволен :P. > Без всего этого можно обойтись, но для кого-то тот же PFS штука обязательная. Ну если очень хотеть - его можно и педально-дупельным методом устроить. Но с DH разумеется практичнее получается. Но той "zero knowledge" проверки это как-то особо не касается. На мой взгляд оно довольно бесполезная хрень, которая только зря все усложняет. В смысле, на что у меня продвинутые знакомые, но эту фиговину применить не вышло, так что практиковалась обычная сверка fingerprint-ов. > установления сессионного ключа: но зачем когда есть довольно быстрый curve25519 уже? Ну вот я и думаю что циферпанкам могло бы иметь смысл посмотреть на все это и сделать заново. В 20 раз компактнее и проще и не особо профукав свойства. > Верно. Но эта возможность остаётся. Тогда как в zero knowledge системах нет. В случае OTR ремота с которой сессия установлена - видит fingerprint. Хоть там что. А этой ремотой может быть в общем случае кто угодно вплоть до MITM и уповать в таких условиях на то что fingerprint не утечет - довольно странно, чтоли.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Релиз свободного безопасного VPN-демона GoVPN 2.0"	+/–
	Сообщение от Sergey (??), 15-Мрт-15, 16:46
	> Как я понимаю, в OTR фингерпринт ключа не виден лишь пассивному наблюдателю. > Но те кто проводит активные атаки (mitm перехвативший первую сессию, или > просто некто лишний, иициирующй OTR сессию с того же сервера) без > особых проблем узнают fingerprint. А что им помешает то? В OTR -- да. В zero knowledge системах и активный атакующий не сможет. Если не ясен zero knowledge, то советую например прочитать про это в Прикладной криптографии Шнайера. Я не умелец подобные вещи рассказывать. > Факт возникновения пакетов - всяко будет виден даже пассивному наблюдателю в канале Это если они посылаются. Без аутентификации они не будут посылаться. > На мой взгляд оно довольно бесполезная хрень, > которая только зря все усложняет. В смысле, на что у меня > продвинутые знакомые, но эту фиговину применить не вышло, так что практиковалась > обычная сверка fingerprint-ов. Криптографы другого мнения и считают это полезным и нужным. > Ну вот я и думаю что циферпанкам могло бы иметь смысл посмотреть > на все это и сделать заново. В 20 раз компактнее и > проще и не особо профукав свойства. Ну так приведите пример что конкретно можно было бы упростить. У шифропанков и криптографов вот как-то не выходит. Это если про протоколы и алгоритмы. Про реализацию молчу: тут уже тема больше программистов касается и вообще тенденции в мире неимоверно безумно всё усложнять в коде, вешать кучу абстракций и прочего.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Релиз свободного безопасного VPN-демона GoVPN 2.0"	+/–
	Сообщение от Аноним (-), 16-Мрт-15, 13:31
	> В OTR -- да. В zero knowledge системах и активный атакующий не сможет. В OTR это можно при сильном желании зарубить. Например, вкостылив политику "1 контакт = 1 ключ". Но реально существюущий софт так не делает. И к тому же чревато DoS атакой - генерация ключа в OTR занимает очень длительное время. > Если не ясен zero knowledge, то советую например прочитать про это в > Прикладной криптографии Шнайера. Я не умелец подобные вещи рассказывать. Да не, общий смысл понятен. Вопрос скорее в практической применимости и насколько это практически значимо и какой выигрыш дает. В OTR это получилось как-то не очень: все довольно сильно усложнилось, и по коду, и по протоколу, и по апи с которым надо программе работать, а особого выигрыша ощутимого на практике я как-то не ощутил. Мне такой tradeoff не нравится. > Это если они посылаются. Без аутентификации они не будут посылаться. А если с другой стороны зайти: возможность явно отличать прошла ли аутентификация или не прошла - информация для наблюдателя. Даже пассивного. Это чем-то хорошо? Как по мне так наоборот намного лучше если сторонний наблюдатель видит пакеты, но понятия не имеет что с ними сделали и было ли это валидно. Это обеспечивает недоказуемость, что в моем понимании хорошее свойство. Мало ли кто и зачем мусор в провод кидал?! Для пущей убедительности при повышенных требованиях - можно периодически кидать реально мусорные пакеты. Пусть любители реконструировать сессию по времянкам радуются, чтоли. > Криптографы другого мнения и считают это полезным и нужным. Хз, мне не понравилось как это сделано на примере OTR. > Ну так приведите пример что конкретно можно было бы упростить. У шифропанков > и криптографов вот как-то не выходит. Это если про протоколы и алгоритмы. В результате шифропанки наворотили почти новый OpenSSL, прикладники которые не криптографы уже серьезно напрягаются такое привинчивать себе в программу. > Про реализацию молчу: тут уже тема больше программистов касается и > вообще тенденции в мире неимоверно безумно всё усложнять в коде, вешать > кучу абстракций и прочего. Чем больше фич нечто предоставляет - тем сложнее это технически корректно реализовать и тем больше грабель везде есть. И тем сложнее этим грамотно пользоваться в программе, без глупых продолбов от прикладников. Ну как с fingerprint ключа в OTR: если задаться целью, его можно и не показывать посторонним, как я понимаю. Но этим должны заморачиваться прикладники. Которым это нафиг надо.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Релиз свободного безопасного VPN-демона GoVPN 2.0"	+/–
	Сообщение от Аноним (-), 13-Мрт-15, 19:32
	> -- со своим другом или с ФСБ-шником? :-) Там можно аутентифицировать собеседников несколькими разными способами. Но в результате все это получилось очень навороченным по коду и таким же геморным по апи.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	54. "Релиз свободного безопасного VPN-демона GoVPN 2.0"	+/–
	Сообщение от Sergey (??), 13-Мрт-15, 19:38
	> Там можно аутентифицировать собеседников несколькими разными способами. Но в результате > все это получилось очень навороченным по коду и таким же геморным > по апи. API, реализация -- это одно. А сам протокол вполне себе хорош.
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Релиз свободного безопасного VPN-демона GoVPN 2.0"	+/–
	Сообщение от Аноним (-), 14-Мрт-15, 13:17
	> API, реализация -- это одно. А сам протокол вполне себе хорош. Мне не понравилось. Сложный и по мере набивания шишек накостылировано почти как в openssl.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Релиз свободного безопасного VPN-демона GoVPN 2.0"	+/–
	Сообщение от Sergey (??), 14-Мрт-15, 13:36
	>> API, реализация -- это одно. А сам протокол вполне себе хорош. > Мне не понравилось. Сложный Сложный? Вы про протокол или реализацию? Если про протокол, то приведите пример более простого и обладающего теми же свойствами что и OTR. OTR по мне так очень прост и чётко выполняет поставленные перед ним задачи.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Релиз свободного безопасного VPN-демона GoVPN 2.0"	+/–
	Сообщение от Аноним (-), 14-Мрт-15, 14:54
	> Сложный? Вы про протокол или реализацию? И то и другое. К третьей версии оно здорово обрасло всевозможными подпорочками. При том на практике половина из этого мало на что влияет. Говоря за себя - я ни разу не смог эффективно проверить ремоту например одинаковым ответом. Надо чтобы я и ремота ввели одинаковый ответ, с побитовой точностью. Это фигово работает с живыми людьми. А fingerprint сверить можно было и без половины тех наворотов. Т.е. наворотили в общем то почем зря - на практике половина фич малоприменимы, имхо. > Если про протокол, то приведите пример более простого и обладающего > теми же свойствами что и OTR. Мне из них по большому счету надо PFS и отсутствие явных подписей для аутентификации ремоты. Это можно сделать в 20 раз проще. И в 20 раз более скромным объемом кода. > OTR по мне так очень прост и чётко выполняет поставленные перед ним задачи. Я и говорю - они поставили себе over 9000 задач, от половины которых мало толка на практике, но код усложняется сильно. На самом деле это было как-то так: знакомый програмер которому надо было защитить чатик - спросил не в курсе ли я решений. Я ему сказал про OTR по старой памяти (версию 1 я смотрел довольно плотно и мне в целом понравилось, т.к. было относительно лаконично и с неплохими в общем то свойствами). А в ответ приехало удивление что я офигел такое советовать. Оказывается, там теперь очень сложное апи, а за две версии протокол перепахивали несколько раз и теперь это еще один монстрятник по типу openssl. Во я обломался. Не, теперь я это не буду советовать знакомым, сорри. Пардон, граждане панки, но в зуде пониже спины надо знать меру и уметь вовремя остановиться с наворачиванием костылей, подпорок и фич. Макаронный монстр в качестве криптолибы и протокола - хуже не бывает.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Релиз свободного безопасного VPN-демона GoVPN 2.0"	+/–
	Сообщение от Аноним (-), 14-Мрт-15, 14:59
	p.s. неприятным бонусом OTR является наличие характерных сигнатур в каждой дырке. Он трезвонит на всю округу что это - именно OTR, а не что-то еще. Что далеко не самое желательное свойство для подобного протокола. При этом в общем случае видно кто с кем переписывался (там где этого не видно - OTR как правило нафиг не упал) и что они использовали шифрование. Это как-то ощутимо выделяет участников переписки из толпы.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Релиз свободного безопасного VPN-демона GoVPN 2.0"	+/–
	Сообщение от Sergey (??), 14-Мрт-15, 15:05
	> При этом в общем случае видно кто с кем переписывался (там где > этого не видно - OTR как правило нафиг не упал) и > что они использовали шифрование. Это как-то ощутимо выделяет участников переписки из > толпы. Именно поэтому людям и пытаются рассказать про подобные инструменты. Увеличить anonimity set. Если бы этим пользовался каждый второй, то из толпы уже, грубо говоря, не выделяемся. Что ж поделать что людям абсолютно пофиг на приватность, на безопасность и прочее. Красивый интерфейс с одной кнопочкой (а простота с точки зрения обычного пользователя не совместима с понятием безопасности серьёзной) решают всё. Пока гром не грянет, пока это каждого второго не заденет, то само собой задумываться о шифровании серьёзном никто не станет.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Релиз свободного безопасного VPN-демона GoVPN 2.0"	+/–
	Сообщение от Аноним (-), 14-Мрт-15, 21:03
	> Увеличить anonimity set. Для начала, то как это сделано - позволяет очень просто и дешево по ресурсам обнаруживать что используется именно шифрование и понимать что это - не случайные данные или что либо еще, а именно шифрование. > на приватность, на безопасность и прочее. Поэтому сие должно быть дефолтным и неотключаемым свойством мало-мальски нормального протокола, а не навеской сверху. Ну а если кто пытается сделать навесок - не очень понятно зачем подставлять тех кто им пользуется лишний раз очень характерными хидерами которые легко и дешево по ресурсам обнаруживаются сервером, etc. > Красивый интерфейс с одной кнопочкой (а простота с точки зрения > обычного пользователя не совместима с понятием безопасности серьёзной) Вообще, по моим наблюдениям, излишне сложные конструкции имеют свойство испытывать проблемы с безопасностью. Поэтому я за то чтобы криптография была максимально простой и прозрачной. Иначе заканчивается все это монстром по типу TLS, а потом атакующие то версию протокола задаунгрейдят, то дурной набор опций вкатят, то баг в нафигнужной фиче типа heartbeat всплывет. > второго не заденет, то само собой задумываться о шифровании серьёзном никто > не станет. Для начала у шифрования имеется масса проблем юзабилити, которые ничем особо не обоснованы. Не знаю нафига это так. Ну и нормально описать человеческим языком базовые принципы мало кто может. А хардкорное математическое описание понятно только ... очень некотрым, скажем так.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Релиз свободного безопасного VPN-демона GoVPN 2.0"	+/–
	Сообщение от Sergey (??), 14-Мрт-15, 15:03
	> Говоря за себя - я ни разу не смог эффективно проверить > ремоту например одинаковым ответом. Надо чтобы я и ремота ввели одинаковый > ответ, с побитовой точностью. Это фигово работает с живыми людьми. Ну... у меня работало с людьми нормально. Не всегда с первого раза, но быстро опять же в этом канале договорившись о формате ответа, так сказать, получалось на 2-3 разы. > Мне из них по большому счету надо PFS и отсутствие явных подписей > для аутентификации ремоты. Это можно сделать в 20 раз проще. И > в 20 раз более скромным объемом кода. Очень любопытно стало как. Для PFS самое простое: взять DH. Для подписей сделать MAC, который зависит от предыдущих сообщений и сессионного ключа. Я не представляю куда проще. Честно. >[оверквотинг удален] > ему сказал про OTR по старой памяти (версию 1 я смотрел > довольно плотно и мне в целом понравилось, т.к. было относительно лаконично > и с неплохими в общем то свойствами). А в ответ приехало > удивление что я офигел такое советовать. Оказывается, там теперь очень сложное > апи, а за две версии протокол перепахивали несколько раз и теперь > это еще один монстрятник по типу openssl. Во я обломался. Не, > теперь я это не буду советовать знакомым, сорри. Пардон, граждане панки, > но в зуде пониже спины надо знать меру и уметь вовремя > остановиться с наворачиванием костылей, подпорок и фич. Макаронный монстр в качестве > криптолибы и протокола - хуже не бывает. Первая реализация OTR совершенно не юзабельна? Никто не заставляет использовать как можно более свежие. Для чатов на практике фич первых версий достаточно. Советовать/не советовать: предложите альтернативы. Лично мне приходят разве что только PGP поверх текстового транспорта.
	Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

	34. "Релиз свободного безопасного VPN-демона GoVPN 2.0"	+/–
	Сообщение от Аноним (-), 13-Мрт-15, 15:35
	> А что не так с OTR? Сложный и костыльный. И апи у него такое же. Вырос почти в openssl, только под другим соусом.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	67. "Релиз свободного безопасного VPN-демона GoVPN 2.0"	+1 +/–
	Сообщение от Аноним (-), 14-Мрт-15, 01:06
	> Сложный и костыльный. А чем тогда пользоваться? Какие реальные альтернативы? (Торообразных не предлагать)
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема