Состоялся (https://lists.cypherpunks.ru/pipermail/govpn-devel/2015-Marc... релиз свободного VPN-демона GoVPN 2.0 (http://www.cypherpunks.ru/govpn/), предназначенного для создания шифрованных аутентифицированных каналов связи поверх UDP. Реализация ориентирована на высокую безопасность, простоту и эффективность. Для аутентификации участников соединения используется протокол обмена ключами DH-EKE (Diffie-Hellman Encrypted Key Exchange), при этом разделяемый ключ (pre-shared key) и хэши от него не передаются другой стороне и обеспечивается защита от дешифровки захваченного трафика (даже при получении ключей и совершении атак повторного воспроизведения (http://en.wikipedia.org/wiki/Replay_attack)). Поддерживается работа в GNU/Linux и FreeBSD. Программа полностью написана на языке Go и распространяется (https://github.com/stargrave/govpn) под лицензией GPLv3.Среди новшеств второй версии можно отметить разделение клиентского и серверного кода, поддержку одновременного соединения к серверу нескольких клиентов и добавление в протокол установки соединения средств для идентификации клиента.
URL: https://lists.cypherpunks.ru/pipermail/govpn-devel/2015-Marc...
Новость: http://www.opennet.me/opennews/art.shtml?num=41833
А область применения у него какая?
Защита своего неотчуждаемого права на приватность от MitM-преступников.
Для этого лочичнее всего поставить впн на каком-нибудь роутере. А фиговина на go в этом не помощник. Идея хорошая, а реализация - как обычно у хипстеров.
Какой-то роутер с бекдорами?
> Какой-то роутер с бекдорами?Зачем же с бэкдорами, прошивку надо нормальную лить. Тот же опенврт например.
> А область применения у него какая?Убеждение чудаков в возможности иметь свободный безопасный инет ессно.
А что не на pure ANSI C?
Не модно, не стильно и не молодежно.
Тот неловкий момент когда один из создателей С - Брайан Уилсон Керниган занимается разработкой на Go
- The Go Programming Language (Addison-Wesley Professional Computing Series) by Alan Donovan (Author), Brian W. Kernighan
Но что из этого следует?..Керниган занимался разработкой awk, например. По факту, один из трех его создателей. По вашей логике - значит VPN-клиенты правильнее писать на awk, чем на C?
По моей логике - нет, на awk не надо.
А вот на Go - надо, Вася^W Stax - надо!
Посмотри на код. Peace of cake ...В моём идеальном мире на си надо оставить суровое байтодрочерство, даже asm куски меня там не смутят. Ну ту же криптуху. А потом зацепить это к Go (это просто, постаральсь аффтары) и писать хай левель логджиГ на Ём :)
> Peace of cake ...Дожили, баги у хипстоты даже в восторгах.
> зацепить это к Go (это просто, постаральсь аффтары)
А зачем там Go? В впн ничего и нет кроме пихания байтов и крипто.
> Тот неловкий момент когда один из создателей С - Брайан Уилсон Керниган занимается разработкой на GoЧего тут неловкого то. От одного уродца к другому дорога не сложна.
Потому что перпендикуляр^W HEARTBLEED.
И каким образом Go поможет подобного избежать ?
Дак хипстота же не знает про существование кучи, стека, регистров и прочее. и соответственно считают, что Go всё за них сделает и код будет безопасным. Не хипстерское это дело разбираться в таких материях.
Сорцы даны по ссылке.
Укажи в каком месте ты нашел проблему.
Не укажешь - твоё очко уходит телезрителям.
> Не укажешь - твоё очко уходит телезрителям.Мне хватило того что один из этих совковых циферпанков сосватал мне фрибсдшный генратор случайных чисел. В котором буквально через месяц нашли резкий недостаток энтропии. Ну его нафиг - софтом от таких компетентных личностей пользоваться.
>> Не укажешь - твоё очко уходит телезрителям.
> Мне хватило... играет музыка "прощание пЫoнЭpa с очкoм" :))))
> того что один из этих совковых циферпанков сосватал мне фрибсдшный
> генратор случайных чисел. В котором буквально через месяц нашли резкий недостаток
> энтропии. Ну его нафиг - софтом от таких компетентных личностей пользоваться.И д и о т дeтeктед. Просто кoнчeнный. Нашли уменьшение энтропии в ___пре-альфа___ версии. Для тебя отдельно объясню - это _только_ для девелоперов.
А теперь марш к доске и писать 100500 раз: "Я больше никогда не буду умничать со взрослыми дядями!"
А потом делать уроки, на гopшoк и спать.
Ыгспepд ... мамкин :)
Ого, вот это бомбануло!> ... играет музыка "прощание пЫoнЭpa с очкoм" :))))
...даже с музыкой!
Ты еще манифест на их сайте не читал ))) Там ошибка на ошибке, глаза сломать можно. А про деепричастные обороты они наверно и вовсе не слышали никогда. Наверно такое постиндустриальное общество по их мнению нас и ждёт. Ну и сравнение себя с Брюсом Шнайером вообще доставляет :)) Это как сказать, что запорожец это как феррари (у нее тоже двигатель сзади).
У хипстера бомбануло.
Простите, чтобы спасти своё очко, вы мне предлагаете нырнуть в бочку с жидкими фекалиями?
> Дак хипстота же не знает про существование кучи, стека, регистров и прочее.Почему то я уверен что вы программируя постоянно со списком регистров сверяетесь, ага.
> и соответственно считают, что Go всё за них сделает и код будет безопасным. Не хипстерское это дело разбираться в таких материях.
Между прочим это именно то для чего ЯВУ и создавались. И советую эту мысль дальше развивать - на телевизор, на тачку. Не знаешь термодинамику, так мотор и не включай. Незачет по электродинамике - год без тв.
- Не знаешь термодинамику - не занимайся разработкой двигателей.
- Не знаешь электродинамику - не занимайся разработкой и проектированием микроэлектронники.
В Go нет арифметики указателей.
Я джва года ждал такой демон!
Осталось FreeBSD переписать на Go. (Ядро меньше линуксовового на порядок)
Менеджер памяти (включая сборщик мусора) придётся писать заново если не на Си, то и вовсе на асме, а про схедулер я и вовсе молчу. Удачи.
Также, ожидай, что околореалтаймовые вещи, такие как звук, начнут лажать. Впрочем, "счастливые" пользователи пульсов это навряд ли заметили бы.
Так перепиши, тебя послушать - делов то с рыбью ногу.Кстати, а не знаешь почему хакерье ломает все и вся через вебню, хотя там никакого самостоятельного управления памятью вроде бы и нет?
> Кстати, а не знаешь почему хакерье ломает все и вся через вебню, хотя там никакого самостоятельного управления памятью вроде бы и нет?Знаю — из-за отсутствующего или посредственного контроля типов данных в языке C, на котором написаны веб-сервера и обслуживающие запросы библиотеки, вследствие чего случаются разнообразные "переполнение буфера", "отсутствие завершающего нуля у структуры типа строки", "выхода за границы массива" и др. "детские неожиданности" — мировой привет из 1970-х, от писателей игровых стрылялок для Unix, которым понадобилось во что бы то ни стало перенести их любимые игрушки на другие процессоры; так зародилась цифровая жизнь. Зачем изучать типобезопасность и сложности с этим связанные? Ведь можно фуякс-фуякс и в продакшен.
Фуяк-фуяк и в продакшен это к джаве и гоу. Знаешь чем хорош Си? Он делает ТО, ЧТО ТЫ ЕМУ ГОВОРИШЬ. Хочешь буфер переполнить - на здоровье, он тебя не может ограничить в твоих желаниях, не хочешь завершать строку '\0' - да ради Бога, ты сам решаешь что тебе нужно. Если ты сам написал так, что вышел за границы массива, то почему Си виноват, что айзен дурак? Ну раз он так написал, значит ему так надо.> Зачем изучать типобезопасность и сложности с этим связанные?
Зачем изучать адресную арифметику и операции над указателями сложности с этим связанные? Ведь можно фуякс-фуякс и в продакшен.
> из-за отсутствующего или посредственного контроля типов данных в языке C, на котором написаны веб-сервера и обслуживающие запросы библиотеки
Ну напиши веб-сервер на джаве. Вот только производительность у него будет... ну как у черепахи наверно.
> производительность у него будет... ну как у черепахи наверно.Жабисты протестуют:
www.techempower.com/benchmarks/#section=data-r9&hw=i7&test=plaintext
>> из-за отсутствующего или посредственного контроля типов данных в языке C, на котором написаны веб-сервера и обслуживающие запросы библиотеки
> Ну напиши веб-сервер на джаве. Вот только производительность у него будет... ну
> как у черепахи наверно.Ты не поверишь... Web-сервера на Java только ленивый не писал. Во всех Java EE они самые, отрабатывают полную программу.
Ну ок, но что-то я все равно не вижу ядер ОС на Go и джаве. Ну или там файловых систем. Интересно почему, м?
> Ну ок, но что-то я все равно не вижу ядер ОС на Go и джаве. Ну или там файловых систем. Интересно почему, м?www.jnode.org
Ну и как зохватили мир \ ограбили караваны? Угу. И не светит :-р
> Фуяк-фуяк и в продакшен это к джаве и гоу. Знаешь чем хорош Си? Он делает ТО, ЧТО ТЫ ЕМУ ГОВОРИШЬ.Все особенности языка си от безграмотности его авторов и от возможностей подобраннои ими на помойке машины с 2кб озу для которой он делался. Глубоких мыслей там нет, хотя задним числом конечно можно что угодно в чем угодно искать, адвокаты всегда найдутся.
> Зачем изучать адресную арифметику и операции над указателями сложности с этим связанные?
Указатели там потому, что даже передачу параметров по ссылке авторы не осилили.
Не верно. Ссылки не заменяют указатели, а лишь дополняют. Например, указатели можно инкрементировать, ссылки - нет. Да и не потому они в Си сделали указатели, что не осилили ссылки, а потому что в асме есть квадратные скобки.
> Не верно. Ссылки не заменяют указатели, а лишь дополняют. Например, указатели можно
> инкрементировать, ссылки - нет.Зато ссылки можно копировать и передавать копии ссылок. Внутри методов переданной копии можно присвоить null, и от этого объект, на который указывает ссылка, не потеряется. А что в этом случае произойдёт с указателем? Правильно — memory leak.
Изя, ты такой баклан ))) Какие методы копий ссылок в ANSI C? Memory leak, ага. А для описанного тобой случая ссылки как раз и подходят лучше указателей. Еще раз для джабистов - указатели можно инкрементировать. А в С++ можно делать так, как ты описал.
Представляю как у тебя шаблон порвёт, когда ты узнаешь про void**
> Представляю как у тебя шаблон порвёт, когда ты узнаешь про void**Это я изе, не тебе
Скажи честно, ты идиот? Ссылка это просто константный указатель. Конкретно про передачу параметров в функцию, когда ты объявляешь ф-ю, параметры к-й ссылки, и передаешь туда просто переменную без оператора взятия адреса, то компилятор на этапе компиляции вычисляет адрес. Это не более, чем синтаксический сахар. Передача аргументов в ф-ю лишь одна из областей применения указателей, а есть еще выделение памяти в куче. Выдели-ка мне память из кучи на ссылку, м? То-то же. Короче, перестань ахинею нести. Ну и как уже выше сказали, в большинстве ассемблеров (NASM, YASM) есть квадратные скобки вокруг регистров, к-е суть есть указатель. Логично, что и С должен такое уметь.
> Знаю — из-за отсутствующего или посредственного контроля типов данных в языке C,Вообще-то современные компиляторы си задолбают варнингами, а то и еррорами, если ты будешь левые типы подпихивать, явно не обозначив это действие преобразованием.
> "выхода за границы массива" и др. "детские неожиданности" — мировой привет
> из 1970-х, от писателей игровых стрылялок для Unix,А ничего что проверка границ массива сажает скорость операций в разы? Одно дело при копировании только порцию данных скопировать и совсем другое - если при этом еще ряд математики надо посчитать. Совсем другая производительность получается.
> Ведь можно фуякс-фуякс и в продакшен.
Ну тебе как жабисту виднее.
> А ничего что проверка границ массива сажает скорость операций в разы?cmp reg, lower
jl OutOfBounds
cmp reg, higher
jg OutOfBoundsВпрочем понятно что вам массивы не нужны были, как и создателям си. Даже в с++ так и не сделали нормальный многомерный массив. В стдлиб только жалкий вектор, в бусте просто ужас какой-то.
ну и все равно от этого в итоге никуда не денешься в дырявом мире, так что на очереди
http://en.wikipedia.org/wiki/Intel_MPX
> (Ядро меньше линуксовового на порядок)Чё за бред? Ты вообще линуксового ведра не видел?
А вот тут Зеня не соврал.
Linux — около 17 миллионов строк кода:
https://www.openhub.net/p/linuxFreeBSD — около 13 миллионов строк кода:
https://www.openhub.net/p/freebsdDragonflyBSD — около 16 миллионов строк кода:
https://www.openhub.net/p/dragonflybsdNetBSD — около 18 миллионов строк кода:
https://www.openhub.net/p/netbsdИз этих четырёх больше, чем в линуксе, строк кода только у netbsd. Стрекоза меньше, но приближается.
Это да. 17 больше 13, но не на порядок
> Это да. 17 больше 13, но не на порядокLinux только ядро занимает 13, а FreeBSD ВСЯ система со всеми сервисами и компиляторами 17.
Какая часть из этого дрова и всякие файловые системы и чего из этого в линуксе больше... эм... "на порядок"
Ну дык дрова и всякие ФС тоже придётся переписывать :)
> FreeBSD — около 13 миллионов строк кода:13 мильенов - это если с базой.
А так, само ведро меньше - 4 с половиной миллиона:
clock /usr/src/sys (стабильная десяточка, естественно через любимую путти.екзе =) )
12165 text files.
11520 unique files.
1051 files ignored.
---------------------------------------------------------------------------------------
Language files blank comment code
---------------------------------------------------------------------------------------
C 5024 529753 714218 3092663
C/C++ Header 4620 165620 381387 1345172
Assembly 216 6170 17503 49272
make 492 2748 2729 8669
...
---------------------------------------------------------------------------------------
SUM: 10499 707413 1120345 4518910
---------------------------------------------------------------------------------------
для сравнения -- "все вместе":
cloc /usr/src/
60768 text files.
55478 unique files.
18633 files ignored.
----------------------------------------------------------------------------------------
Language files blank comment code
----------------------------------------------------------------------------------------
C 17435 1346310 1874811 7914185
C/C++ Header 12086 393360 914483 2188250
C++ 2227 205463 234097 1194420
Bourne Shell 2319 133628 141933 872546
m4 299 17067 5441 154551
Assembly 766 15426 33781 137093
HTML 363 7949 1143 99996
Perl 262 10964 11251 89259
...
----------------------------------------------------------------------------------------
SUM: 39434 2176164 3295285 12921097
----------------------------------------------------------------------------------------
Ну ок, и где тут "на порядок"? Не пора ли уже признать что изен спи...л вместо того чтобы его выгораживать? :)
>Осталось FreeBSD переписать на Go. (Ядро меньше линуксовового на порядок)Бздуны, знайте, у вас в тылу засланный M$ казачок.
Да не M$, а гуглом же. M$ бы C# советовал.
Хотя у гугла всё же хватает ума не использовать Go для создания ядер.
> Да не M$, а гуглом же. M$ бы C# советовал.
> Хотя у гугла всё же хватает ума не использовать Go для создания ядер.И вообще Go - это не дяра печь, это для того для чего жабба и C# ...
Так что пусть живёт и пасётся :)
Btw, отечественные "циферпанки" зарекомендовали себя теми еще ламерами в шифровании и прочем. Еще хуже канадских, наворотивших OTR.
А что не так с OTR?
> А что не так с OTR?а OTR это не тали самая штука, типа чат, в котором всё зашифровано.. но при этом не ясно -- с кем ты общаешься -- со своим другом или с ФСБ-шником? :-)
Эти же шифропанки из Канады вместе с OTR поставляют и SMP: zero-knowledge проверку идентификации. С этим SMP пользователи смогут друг друга аутентифицировать. И просто включённый OTR во многих клиентам громко кричит что соединение безопасно, но не аутентифицированно.
С практической точки зрения людям которые немного разбираются проще всего проверить фингерпринты. Остальные варианты - ими как-то сложно пользоваться на практике из-за высокого риска ошибок в легитимных случаях. А кто совсем не разбирается - ему ничего не поможет. А вот наворочено все получилось неимоверно. Проаудитить код OTR нынче не сильно проще чем перечитать openssl. А это плохо для криптографии.
> С практической точки зрения людям которые немного разбираются проще всего проверить фингерпринты.Fingerprint-ы это как правило хэш от ключей. Хэш это уже утечка информации о них. Это не zero-knowledge система. То есть возможна атака когда мы создадим например публичный асимметричный ключ с таким же fingerprint-ом.
> Fingerprint-ы это как правило хэш от ключей. Хэш это уже утечка информации о них.А любые публичные ключи наверное тогда вообще полный пи...ц? Ведь там даже не хэш а целиком ключ бывает. И если что - ремота в OTR знает fingerprint ключа другой стороны.
А если чуть попроще мыслить - там где OTR требуется, отправитель и получатель как правило и так известны на уровне протокола. Если б протокол заботился об этом моменте - OTR поверх него элементарно не требовался бы. По поводу чего о какой-то особой анонимности в случае OTR речь как правило не идет. Только о защите содержимого от чтения.
> Это не zero-knowledge система.
Если мы вообще ничего не знаем о ремоте - то и отличить от MITM не сможем. Поэтому заявления про zero knowledge лишь попытка замаскировать проблему. В результате все приходит к еще более сложному формату чем проверка фингерпринта. А так можно проверять не фингерпринт а например какой-то дериватив от текущегшо временного ключа шифрования, по типу хэшей. Если ключи будут разными (т.е. MITM проксирует в обе стороны) - MITM попался. И сравнить 2 числа с разных сторон линка - может даже обезьяна. А всякие заморочки с совместно знаемым заранее ответом на вопрос... блин, перцы, если у меня уже есть shared secret с ремотой - зачем мне вообще диффи-хеллманы и публичная криптография вообшще, интерсно? Можно втупую симметричное шифрование вкатить и не заморачиваться :)
> То есть возможна атака когда мы создадим например публичный асимметричный
> ключ с таким же fingerprint-ом.Для этого надо или найти коллизии в функции хэширования и там будет много иных проблем, или же атакующий должен угадать приватный ключ. А это уже поимение.
> А любые публичные ключи наверное тогда вообще полный пи...ц? Ведь там даже
> не хэш а целиком ключ бывает. И если что - ремота
> в OTR знает fingerprint ключа другой стороны.Пользователь с другой стороны знает -- отлично. А человек по-середине не должен. В данном случае вы сливаете то что можно будет подобрать (хэш).
> блин, перцы, если у меня уже есть shared secret с
> ремотой - зачем мне вообще диффи-хеллманы и публичная криптография вообшще, интерсно?
> Можно втупую симметричное шифрование вкатить и не заморачиваться :)Вот на этом и закончим этот тред. DH нужен для установления сессионных одноразовых ключей, чтобы при компрометации shared ключа нельзя было дешифровать ранее перехваченный трафик. Свойство это называется perfect forward secrecy. Более того: как вы аутентифицируете противоположную сторону при установлении соединения? Будете просто посылать сразу данные, ведь всё-равно их дешифровать не смогут, сливая факты возникновения пакетов и их размеры? Без всего этого можно обойтись, но для кого-то тот же PFS штука обязательная. Если аутентифицировать противоположную сторону (есть симметричные алгоритмы для этого), то найдутся и симметричные алгоритмы для установления сессионного ключа: но зачем когда есть довольно быстрый curve25519 уже?
> Для этого надо или найти коллизии в функции хэширования
Верно. Но эта возможность остаётся. Тогда как в zero knowledge системах нет.
> Пользователь с другой стороны знает -- отлично. А человек по-середине не должен.Так изначально неизвестно кто с той стороны - 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 не утечет - довольно странно, чтоли.
> Как я понимаю, в OTR фингерпринт ключа не виден лишь пассивному наблюдателю.
> Но те кто проводит активные атаки (mitm перехвативший первую сессию, или
> просто некто лишний, иициирующй OTR сессию с того же сервера) без
> особых проблем узнают fingerprint. А что им помешает то?В OTR -- да. В zero knowledge системах и активный атакующий не сможет.
Если не ясен zero knowledge, то советую например прочитать про это в Прикладной криптографии Шнайера. Я не умелец подобные вещи рассказывать.
> Факт возникновения пакетов - всяко будет виден даже пассивному наблюдателю в канале
Это если они посылаются. Без аутентификации они не будут посылаться.
> На мой взгляд оно довольно бесполезная хрень,
> которая только зря все усложняет. В смысле, на что у меня
> продвинутые знакомые, но эту фиговину применить не вышло, так что практиковалась
> обычная сверка fingerprint-ов.Криптографы другого мнения и считают это полезным и нужным.
> Ну вот я и думаю что циферпанкам могло бы иметь смысл посмотреть
> на все это и сделать заново. В 20 раз компактнее и
> проще и не особо профукав свойства.Ну так приведите пример что конкретно можно было бы упростить. У шифропанков и криптографов вот как-то не выходит. Это если про протоколы и алгоритмы. Про реализацию молчу: тут уже тема больше программистов касается и вообще тенденции в мире неимоверно безумно всё усложнять в коде, вешать кучу абстракций и прочего.
> В OTR -- да. В zero knowledge системах и активный атакующий не сможет.В OTR это можно при сильном желании зарубить. Например, вкостылив политику "1 контакт = 1 ключ". Но реально существюущий софт так не делает. И к тому же чревато DoS атакой - генерация ключа в OTR занимает очень длительное время.
> Если не ясен zero knowledge, то советую например прочитать про это в
> Прикладной криптографии Шнайера. Я не умелец подобные вещи рассказывать.Да не, общий смысл понятен. Вопрос скорее в практической применимости и насколько это практически значимо и какой выигрыш дает. В OTR это получилось как-то не очень: все довольно сильно усложнилось, и по коду, и по протоколу, и по апи с которым надо программе работать, а особого выигрыша ощутимого на практике я как-то не ощутил. Мне такой tradeoff не нравится.
> Это если они посылаются. Без аутентификации они не будут посылаться.
А если с другой стороны зайти: возможность явно отличать прошла ли аутентификация или не прошла - информация для наблюдателя. Даже пассивного. Это чем-то хорошо? Как по мне так наоборот намного лучше если сторонний наблюдатель видит пакеты, но понятия не имеет что с ними сделали и было ли это валидно. Это обеспечивает недоказуемость, что в моем понимании хорошее свойство. Мало ли кто и зачем мусор в провод кидал?! Для пущей убедительности при повышенных требованиях - можно периодически кидать реально мусорные пакеты. Пусть любители реконструировать сессию по времянкам радуются, чтоли.
> Криптографы другого мнения и считают это полезным и нужным.
Хз, мне не понравилось как это сделано на примере OTR.
> Ну так приведите пример что конкретно можно было бы упростить. У шифропанков
> и криптографов вот как-то не выходит. Это если про протоколы и алгоритмы.В результате шифропанки наворотили почти новый OpenSSL, прикладники которые не криптографы уже серьезно напрягаются такое привинчивать себе в программу.
> Про реализацию молчу: тут уже тема больше программистов касается и
> вообще тенденции в мире неимоверно безумно всё усложнять в коде, вешать
> кучу абстракций и прочего.Чем больше фич нечто предоставляет - тем сложнее это технически корректно реализовать и тем больше грабель везде есть. И тем сложнее этим грамотно пользоваться в программе, без глупых продолбов от прикладников. Ну как с fingerprint ключа в OTR: если задаться целью, его можно и не показывать посторонним, как я понимаю. Но этим должны заморачиваться прикладники. Которым это нафиг надо.
> -- со своим другом или с ФСБ-шником? :-)Там можно аутентифицировать собеседников несколькими разными способами. Но в результате все это получилось очень навороченным по коду и таким же геморным по апи.
> Там можно аутентифицировать собеседников несколькими разными способами. Но в результате
> все это получилось очень навороченным по коду и таким же геморным
> по апи.API, реализация -- это одно. А сам протокол вполне себе хорош.
> API, реализация -- это одно. А сам протокол вполне себе хорош.Мне не понравилось. Сложный и по мере набивания шишек накостылировано почти как в openssl.
>> API, реализация -- это одно. А сам протокол вполне себе хорош.
> Мне не понравилось. СложныйСложный? Вы про протокол или реализацию? Если про протокол, то приведите пример более простого и обладающего теми же свойствами что и OTR. OTR по мне так очень прост и чётко выполняет поставленные перед ним задачи.
> Сложный? Вы про протокол или реализацию?И то и другое. К третьей версии оно здорово обрасло всевозможными подпорочками. При том на практике половина из этого мало на что влияет. Говоря за себя - я ни разу не смог эффективно проверить ремоту например одинаковым ответом. Надо чтобы я и ремота ввели одинаковый ответ, с побитовой точностью. Это фигово работает с живыми людьми. А fingerprint сверить можно было и без половины тех наворотов. Т.е. наворотили в общем то почем зря - на практике половина фич малоприменимы, имхо.
> Если про протокол, то приведите пример более простого и обладающего
> теми же свойствами что и OTR.Мне из них по большому счету надо PFS и отсутствие явных подписей для аутентификации ремоты. Это можно сделать в 20 раз проще. И в 20 раз более скромным объемом кода.
> OTR по мне так очень прост и чётко выполняет поставленные перед ним задачи.
Я и говорю - они поставили себе over 9000 задач, от половины которых мало толка на практике, но код усложняется сильно.
На самом деле это было как-то так: знакомый програмер которому надо было защитить чатик - спросил не в курсе ли я решений. Я ему сказал про OTR по старой памяти (версию 1 я смотрел довольно плотно и мне в целом понравилось, т.к. было относительно лаконично и с неплохими в общем то свойствами). А в ответ приехало удивление что я офигел такое советовать. Оказывается, там теперь очень сложное апи, а за две версии протокол перепахивали несколько раз и теперь это еще один монстрятник по типу openssl. Во я обломался. Не, теперь я это не буду советовать знакомым, сорри. Пардон, граждане панки, но в зуде пониже спины надо знать меру и уметь вовремя остановиться с наворачиванием костылей, подпорок и фич. Макаронный монстр в качестве криптолибы и протокола - хуже не бывает.
p.s. неприятным бонусом OTR является наличие характерных сигнатур в каждой дырке. Он трезвонит на всю округу что это - именно OTR, а не что-то еще. Что далеко не самое желательное свойство для подобного протокола.При этом в общем случае видно кто с кем переписывался (там где этого не видно - OTR как правило нафиг не упал) и что они использовали шифрование. Это как-то ощутимо выделяет участников переписки из толпы.
> При этом в общем случае видно кто с кем переписывался (там где
> этого не видно - OTR как правило нафиг не упал) и
> что они использовали шифрование. Это как-то ощутимо выделяет участников переписки из
> толпы.Именно поэтому людям и пытаются рассказать про подобные инструменты. Увеличить anonimity set. Если бы этим пользовался каждый второй, то из толпы уже, грубо говоря, не выделяемся. Что ж поделать что людям абсолютно пофиг на приватность, на безопасность и прочее. Красивый интерфейс с одной кнопочкой (а простота с точки зрения обычного пользователя не совместима с понятием безопасности серьёзной) решают всё. Пока гром не грянет, пока это каждого второго не заденет, то само собой задумываться о шифровании серьёзном никто не станет.
> Увеличить anonimity set.Для начала, то как это сделано - позволяет очень просто и дешево по ресурсам обнаруживать что используется именно шифрование и понимать что это - не случайные данные или что либо еще, а именно шифрование.
> на приватность, на безопасность и прочее.
Поэтому сие должно быть дефолтным и неотключаемым свойством мало-мальски нормального протокола, а не навеской сверху. Ну а если кто пытается сделать навесок - не очень понятно зачем подставлять тех кто им пользуется лишний раз очень характерными хидерами которые легко и дешево по ресурсам обнаруживаются сервером, etc.
> Красивый интерфейс с одной кнопочкой (а простота с точки зрения
> обычного пользователя не совместима с понятием безопасности серьёзной)Вообще, по моим наблюдениям, излишне сложные конструкции имеют свойство испытывать проблемы с безопасностью. Поэтому я за то чтобы криптография была максимально простой и прозрачной. Иначе заканчивается все это монстром по типу TLS, а потом атакующие то версию протокола задаунгрейдят, то дурной набор опций вкатят, то баг в нафигнужной фиче типа heartbeat всплывет.
> второго не заденет, то само собой задумываться о шифровании серьёзном никто
> не станет.Для начала у шифрования имеется масса проблем юзабилити, которые ничем особо не обоснованы. Не знаю нафига это так. Ну и нормально описать человеческим языком базовые принципы мало кто может. А хардкорное математическое описание понятно только ... очень некотрым, скажем так.
> Говоря за себя - я ни разу не смог эффективно проверить
> ремоту например одинаковым ответом. Надо чтобы я и ремота ввели одинаковый
> ответ, с побитовой точностью. Это фигово работает с живыми людьми.Ну... у меня работало с людьми нормально. Не всегда с первого раза, но быстро опять же в этом канале договорившись о формате ответа, так сказать, получалось на 2-3 разы.
> Мне из них по большому счету надо PFS и отсутствие явных подписей
> для аутентификации ремоты. Это можно сделать в 20 раз проще. И
> в 20 раз более скромным объемом кода.Очень любопытно стало как. Для PFS самое простое: взять DH. Для подписей сделать MAC, который зависит от предыдущих сообщений и сессионного ключа. Я не представляю куда проще. Честно.
>[оверквотинг удален]
> ему сказал про OTR по старой памяти (версию 1 я смотрел
> довольно плотно и мне в целом понравилось, т.к. было относительно лаконично
> и с неплохими в общем то свойствами). А в ответ приехало
> удивление что я офигел такое советовать. Оказывается, там теперь очень сложное
> апи, а за две версии протокол перепахивали несколько раз и теперь
> это еще один монстрятник по типу openssl. Во я обломался. Не,
> теперь я это не буду советовать знакомым, сорри. Пардон, граждане панки,
> но в зуде пониже спины надо знать меру и уметь вовремя
> остановиться с наворачиванием костылей, подпорок и фич. Макаронный монстр в качестве
> криптолибы и протокола - хуже не бывает.Первая реализация OTR совершенно не юзабельна? Никто не заставляет использовать как можно более свежие. Для чатов на практике фич первых версий достаточно. Советовать/не советовать: предложите альтернативы. Лично мне приходят разве что только PGP поверх текстового транспорта.
> А что не так с OTR?Сложный и костыльный. И апи у него такое же. Вырос почти в openssl, только под другим соусом.
> Сложный и костыльный.А чем тогда пользоваться? Какие реальные альтернативы? (Торообразных не предлагать)
vpn без скрамблера сейчас уже становится не актуален
> vpn без скрамблера сейчас уже становится не актуаленХорошее шифрование от рандома отличить невозможно. Хотя автор конкретно вот этой конструкции такой мелочью не парился, наскольк я понимаю.
> Хорошее шифрование от рандома отличить невозможно. Хотя автор конкретно вот этой конструкции
> такой мелочью не парился, наскольк я понимаю.Процитирую из документации: Each transport message is indistinguishable from pseudo random noise. Сами данные шифруются симметричных алгоритмом: его выхлоп это шум, аутентификационный тэг каждого сообщения тоже шум, nonce зашифрован блочным шифром (не PRF, но PRP, тоже в данном случае не отличимый от шума).
> Процитирую из документации: Each transport message is indistinguishable from pseudo
> random noise.А как насчет вон тех сообщений в начале сессии? Если DPI прочухает в самом начале сессии что это именно вон тот протокол - дальше уже как-то все-равно что остальной траффик дескать похож на рандом: он уже классифицирован.
> А как насчет вон тех сообщений в начале сессии? Если DPI прочухает
> в самом начале сессии что это именно вон тот протокол -
> дальше уже как-то все-равно что остальной траффик дескать похож на рандом:
> он уже классифицирован.Да, пока это под вопросом. Handshake пакеты оканчиваются на нули. Тут надо думать что с этим делать. Возможно достаточно просто забить на нули и пытаться обработать handshake: не доходят руки у разработчика это оценить. Кроме нулей оставшаяся часть всех handshake-ов это тоже рандом сплошной.
Было бы совсем круто если бы эмулировался http траффик, а в него методом стеганографии пролезал впн. Хотябы как рация.
> Было бы совсем круто если бы эмулировался http траффик, а в него
> методом стеганографии пролезал впн. Хотябы как рация.Опция.
> ...средств для идентификации клиентаа средства для идентификации сервера?
> а средства для идентификации сервера?Клиентов много, сервер один. Он и так будет аутентифицирован по PSK. А PSK у каждого клиента свой. Идентификация клиента: для того чтобы понять какой PSK серверу использовать.
> Программа полностью написана на языке GoПишут так, как будто это что-то хорошее.
>> Программа полностью написана на языке Go
> Пишут так, как будто это что-то хорошее.Потому что это - хорошее.
> Потому что это - хорошее....с точки зрения хипстоты :)
>> Потому что это - хорошее.
> ...с точки зрения хипстоты :)Тебе за твоих виднее :-р
А Go действительно хорошее. Просто надо понимать куда его лепить а куда - нет.
Вот к примеру один клоун тут недавно предлагал на нем ядро. Ну дык - клоун ...
>[оверквотинг удален]
> при этом разделяемый ключ (pre-shared key) и хэши от него не
> передаются другой стороне и обеспечивается защита от дешифровки захваченного трафика (даже
> при получении ключей и совершении атак повторного воспроизведения (http://en.wikipedia.org/wiki/Replay_attack)).
> Поддерживается работа в GNU/Linux и FreeBSD. Программа полностью написана на
> языке Go и распространяется (https://github.com/stargrave/govpn) под лицензией GPLv3.
> Среди новшеств второй версии можно отметить разделение клиентского и серверного кода, поддержку
> одновременного соединения к серверу нескольких клиентов и добавление в протокол установки
> соединения средств для идентификации клиента.
> URL: https://lists.cypherpunks.ru/pipermail/govpn-devel/2015-Marc...
> Новость: http://www.opennet.me/opennews/art.shtml?num=41833Как-же интересно участники обмена должны ключами обмениваться, оставаясь при этом неуязвимыми для MitM. Чудеса.
> Как-же интересно участники обмена должны ключами обмениваться,
> оставаясь при этом неуязвимыми для MitM. Чудеса.Никак. Читай доки внимательно (С)
> Как-же интересно участники обмена должны ключами обмениваться, оставаясь при этом неуязвимыми
> для MitM. Чудеса.Подходите к вашему системному администратору и получаете ключ/id на флешке/бумажке/whatever. Либо пообщайтесь с ним по email используя PGP. Следующий вопрос: как же подтвердить достоверность противоположного PGP ключа? Ну этой теме уже много посвящено статей.
> Поддерживается работа в GNU/Linux и FreeBSD.написать на Go что-то не работающее в Windows и Mac -- надо ухитриться.
авторы или не совсем грамотные джастфофаны, или принципиальные идиоты, которые потом ровно так же заявят, что для андроидов клиент для vpn никому не нужен.
>...каналов связи поверх UDP.Я что-то пропустил?