The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

Продолжение разработки и выпуск P2P VPN 0.10, opennews (ok), 22-Авг-23, (0) [смотреть все]

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


63. "Продолжение разработки и выпуск P2P VPN 0.10"  +/
Сообщение от Аноним (21), 22-Авг-23, 18:58 
Выходи к нам из своей реальности
Ответить | Правка | Наверх | Cообщить модератору

65. "Продолжение разработки и выпуск P2P VPN 0.10"  +/
Сообщение от Skullnetemail (ok), 22-Авг-23, 19:11 
Спасибо, мне нормально с нормальными людьми, а не с плоскоземельщиками.
Ответить | Правка | Наверх | Cообщить модератору

83. "Продолжение разработки и выпуск P2P VPN 0.10"  –1 +/
Сообщение от Аноним (83), 22-Авг-23, 23:26 
> Спасибо, мне нормально с нормальными людьми, а не с плоскоземельщиками.

Жябист который не может исползовать либы которым более десятка лет да вдруг про плоскость земли вспомнил? Вы, типа, будете настаивать что земля плоская? А то амплуа разъезжается :)

p.s. а чуть более умные люди, писавшие Tox и его DHT - сделали DHT по ширине ключа 25519, т.е. 256 битов а не 160 (это из-за SHA1) как в торенте. Это им сиииииильно упростило p2p layer и многие вещи в нем по части начала секурных коммуникаций. Там если идентификатор в DHT знаешь, можешь ему секурно пакет послать. Пустячок а продуманный сетевой дизайн видно как-то так...

Ответить | Правка | Наверх | Cообщить модератору

100. "Продолжение разработки и выпуск P2P VPN 0.10"  +/
Сообщение от Skullnetemail (ok), 23-Авг-23, 02:23 
> Жябист который не может исползовать либы которым более десятка лет да вдруг про плоскость земли вспомнил?

На самом деле по правде, пока что руки не дошли. И да, я на С++ пишу чаще чем на Java.

>  а чуть более умные люди, писавшие Tox и его DHT - сделали DHT по ширине ключа 25519, т.е. 256 битов а не 160 (это из-за SHA1) как в торенте. Это им сиииииильно упростило p2p layer и многие вещи в нем по части начала секурных коммуникаций. Там если идентификатор в DHT знаешь, можешь ему секурно пакет послать. Пустячок а продуманный сетевой дизайн видно как-то так...

Нужно будет сделать поддержку нескольких алгоритмов:

RSA 2048, RSA 4096, Ed25519 и AES128, AES256, ChaCha20 для симметричных ключей.

Либо выбрать наилучшие, но RSA 2048 пока что тоже норм.

Ответить | Правка | Наверх | Cообщить модератору

125. "Продолжение разработки и выпуск P2P VPN 0.10"  +/
Сообщение от Аноним (-), 23-Авг-23, 20:28 
> RSA 2048, RSA 4096, Ed25519 и AES128, AES256, ChaCha20 для симметричных ключей.

25519 сам по себе != Ed25519. И позволяет ряд эффектных фокусов.

Как то: секрет посчитаный через(their_public, our_secret) == секрет через (our_public, their_secret). Это такой себе диффи-хеллман, но размер ключей такой что они могут быть переданы заранее, "голубем" или смской или QR или даже вбиты с клавы или скопипащены если приспичило.

Там же и красивое апи crypto_box() в котором сложно наломать дров даже будучи дилетантом. Требования простые, их могут выполнить даже "двое из ларца". Оно как раз довольно удобно для пакетных штук с 1 стороны, с другой обеспечивает кучу желаемых свойств от PFS малой кровью (достаточно передать ремоте в энном пакете временный сессионный пубкей и получить их временный пубкей в ответ, а при завершении сессии выпилить временные секретные ключи назло атакующим). С RSA так конечно тоже можно - но keypair(RSA) для временных ключей зело медленная и дорогая операция чтоб на лету в сессии ее так уж регулярно делать. А для 25519 вполне вариант.

> Либо выбрать наилучшие, но RSA 2048 пока что тоже норм.

Да просто не понимаю чего этот RSA всем дался. Доисторический урод с кучей проблем и с безопасностью у него - весьма так себе. Особенно если не понимать что делаешь. А хреновая скорость оперций зарубаят ряд начинаний по чисто практическим мотивам. Пары ключей 25519 можно генерить как захотелось ключ линка в PFS сменить, хоть каждую минуту. И если через минуту временные ключи аннулированы - атакующий может что угодно делать но в памяти Алисы и Боба уже нет приватных ключей. Расшифровывать перехваченое чисто технически уже нечем: два публичных ключа не ведут к расшифровке трафика. Только к рантайм-аутентификации что алиса это алиса а боб это боб, раз могут шифровать этим ключом. С RSA сие задолбает нагрузкой на проц, там генерация ключей весьма нетривиальный процесс. Мало того что огромная математика так еще отсев проблемных ключей и проч, и проч.

Ответить | Правка | Наверх | Cообщить модератору

126. "Продолжение разработки и выпуск P2P VPN 0.10"  +/
Сообщение от Аноним (-), 23-Авг-23, 20:39 
А, да, в чем профит? Если гонять данные в стиле crypto_box() там явных подписей как раз НЕТ и доказательств что это именно Алиса и Боб послали - тоже. Кто угодно может заявить что это packet(our_privkey, their_pubkey). Но только адресат с парным "theor_privkey" сможет вообще понять - легитимный пакет оно или фэйк. У атакующего в канале нет приватных частей ключа, поэтому он не знает правда ли это алиса и боб или кто-то косит под них - доказать ничего нельзя.

А подтверждение что алиса это алиса и боб это боб - возможность в рантайм шифровать вон то и вон то, соответственно. Если Алиса может расшифровать число кинутое бобом с (bob_private, alice_public) - окей, это и правда Алиса, а пакет и правда послал Боб. Можно, вот, "рантайм" аутентификацию (именно онлайн - по возможности шифровать и расшифровывать) без явных подписей. А ed25519 это как раз схема с явными подписями уже. Иногда неявная аутентификация не катит. Скажем пакетный менеджер явно предпочтет "офлайн" подпись майнтайнера, чем каждый раз делать онлайн-сессию к майнтайнеру чтобы тот доказал что он это он, скроив данные с шифрованием именно своим ключом, именно этому клиенту. Но вот для впн та механика что доктор прописал. Кент примерно это и сделал но у него там продвинутости есть, как я понимаю на основе идеи dual ratchet. Это дополнительно портит атакующим карму т.к. там дополнительный фактор аутентификации появляется на основе истории обмена пакетами. А у атакуюшего его разумеется нет без вообще совсем полного взлома истории обмена от и до - что крайне неудобное требование для атаки. А если хоть немнго трафика атакующему не досталось и что-то не доломано - с энного момента траф не расшифровывается. Это позволяет немного потрепыхаться даже при утечке долговременного ключа, если у атакующего нет части трафика - он может пролететь.

Ответить | Правка | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру