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