|
Авторизация без сервера
|
|||
---|---|---|---|
#18+
maytonХм. В твоей схеме шифрование-то вобщем не нужно. В момент регистрации когад клиент как-то получает логин/пароль - сервер получает публичный ключ клиента. Подписывает его. И сохраняет в свою базу. И с этого момента все участники чата если обращаются на сервер могут получить образ этой базы и кешировать его так-же как браузер хранит "печенюшки". Основываясь на TTL каждой записи. (Помним что сертификаты имеют срок годности). Есть еще схема когда участники между собой могут передавать образ этой базы. Поскольку все записи заверены сервером (хардкод главного сертификата) то все имеют возможность видеть публичные ключи всех.в принципе да, схема с сертификатами для идентификации вполне работоспособна Клиент1 генерит открытый и закрытый ключ для сессии Клиент1 отправляет серверу запрос авторизации со сгенеренным паблик-ключом Сервер например добавляет время, берёт подпись хэшсумму с этого добра, подписывает её своим закрытым ключом и отправляет подпись назад клиенту клиент1 подцепляется к клиенту2 отправив свой открытый ключ и ответ сервера клиент2 знает паблик-ключ сервера и расшифровывает исходную хэш-сумму из предполагаемого ответа сервера, считает хэш-сумму по тому же алгоритму из предоставленных данных и сравнивает. Совпадает - доверяет но естественно ключи должны быть адекватной длины ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2018, 00:36 |
|
Авторизация без сервера
|
|||
---|---|---|---|
#18+
https://crypto.stackexchange.com/questions/12479/how-to-perform-authentication-without-central-server-in-p2p там правда ссылка на проект битая. Ещё можно использовать https://en.m.wikipedia.org/wiki/Public_key_fingerprint для идентификации. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2018, 10:52 |
|
Авторизация без сервера
|
|||
---|---|---|---|
#18+
maytonВобщем сумбурно. Это разные части одной большой системы, но к теме это не относится. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2018, 11:50 |
|
Авторизация без сервера
|
|||
---|---|---|---|
#18+
kealon(Ruslan)maytonХм. В твоей схеме шифрование-то вобщем не нужно. В момент регистрации когад клиент как-то получает логин/пароль - сервер получает публичный ключ клиента. Подписывает его. И сохраняет в свою базу. И с этого момента все участники чата если обращаются на сервер могут получить образ этой базы и кешировать его так-же как браузер хранит "печенюшки". Основываясь на TTL каждой записи. (Помним что сертификаты имеют срок годности). Есть еще схема когда участники между собой могут передавать образ этой базы. Поскольку все записи заверены сервером (хардкод главного сертификата) то все имеют возможность видеть публичные ключи всех.в принципе да, схема с сертификатами для идентификации вполне работоспособна Клиент1 генерит открытый и закрытый ключ для сессии Клиент1 отправляет серверу запрос авторизации со сгенеренным паблик-ключом Сервер например добавляет время, берёт подпись хэшсумму с этого добра, подписывает её своим закрытым ключом и отправляет подпись назад клиенту клиент1 подцепляется к клиенту2 отправив свой открытый ключ и ответ сервера клиент2 знает паблик-ключ сервера и расшифровывает исходную хэш-сумму из предполагаемого ответа сервера, считает хэш-сумму по тому же алгоритму из предоставленных данных и сравнивает. Совпадает - доверяет но естественно ключи должны быть адекватной длины ИМХО Сервер выступает в роли удостоверяющего центра, просто подтверждает своей подписью валидность сертификата внутри которого указан логин и его открытый ключ. Дальше как угодно можно взаимодействовать. Желающий что-то послать сначала посылает рандомный секрет (ключ сессии) получателю, зашифрованный его открытым ключом, затем сообщение зашифрованное рандомным секретом. В общем я пришел к выводу что надо задействовать полноценное шифрование. Делаем один сервер подписывающий сертификаты (логин, открытый ключ, срок действия), т.е. УЦ, а дальше логины как угодно могут общаться, любыми каналами. PS Велосипед проиграл :( ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2018, 19:43 |
|
Авторизация без сервера
|
|||
---|---|---|---|
#18+
maytonДима. Ты когда нибудь с этой штукой разбирался? Должна поверх UDP работать на порту 4672 Не разбирался. Судя по ссылке - это классический P2P. Обмен файлами. Интересно порешана проблема обхода законодательства об авторских правах ))) Что по теме топика, то, как понял, там доступ открыт всем желающим, т.е. никому не интересно Алиса ты или Боб. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2019, 08:26 |
|
Авторизация без сервера
|
|||
---|---|---|---|
#18+
Dima TmaytonДима. Ты когда нибудь с этой штукой разбирался? Должна поверх UDP работать на порту 4672 Не разбирался. Судя по ссылке - это классический P2P. Обмен файлами. Интересно порешана проблема обхода законодательства об авторских правах ))) Что по теме топика, то, как понял, там доступ открыт всем желающим, т.е. никому не интересно Алиса ты или Боб. Обмен файлами это уже финал. И это не интересно. Интересно как работает DHT. (Параллельно меня интересовало как работает ZooKeeper, и как вообще реплицировать настройки в распределенной среде (интернет) где нет централизованного управления) Кое-что я начал писать для себя и собирать сведения. автор Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41.
Основной API этого протокола содержит всего 4 команды PING, STORE, FIND_NODE, FIND_VALUE. Благодаря им узлы обмениваются сведениями и ищут и что характерно находят информацию по хешу. Это настоящая магия, чувак. Здесь 21768887 один господин выкладывал полноценный Torrent клиент. Но он меня не интересовал. Мне была нужна только та часть клиента которая оперирует с DHT. Если тебе интересна тема распределенных хеш таблиц и поиска - можем поднять отдельный топик. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2019, 12:49 |
|
Авторизация без сервера
|
|||
---|---|---|---|
#18+
maytonЭто настоящая магия, чувак. Это хрень. Там ни слова про надежность. Ну не смог скачать ты сейчас кинчик который искал, ну и ладно, скачай другой. Лично меня интересует гарантированная доступность искомых данных, а тут никаких гарантий, носители куска скачиваемого недоступны - обломись. Для обмена кино-аудио сгодится, но не более того. PS Повторю: они порешали проблему обхода авторских прав. Ни одна их нод не хранит файл целиком, т.е. не предъявить незаконное копирование. Это основная мысль той системы ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2019, 20:14 |
|
Авторизация без сервера
|
|||
---|---|---|---|
#18+
maytonЕсли тебе интересна тема распределенных хеш таблиц и поиска - можем поднять отдельный топик. Неинтересна. Это понижение надежности. Распределяем данные на 2 узла, надежность получения данных снижается в два раза. Мне интересна тема как записать сообщение на несколько (минимум) узлов и получить гарантированную возможность получения сообщения в любой момент. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2019, 20:35 |
|
Авторизация без сервера
|
|||
---|---|---|---|
#18+
Dima TmaytonЭто настоящая магия, чувак. Это хрень. Там ни слова про надежность. Ну не смог скачать ты сейчас кинчик который искал, ну и ладно, скачай другой. Лично меня интересует гарантированная доступность искомых данных, а тут никаких гарантий, носители куска скачиваемого недоступны - обломись. Для обмена кино-аудио сгодится, но не более того. PS Повторю: они порешали проблему обхода авторских прав. Ни одна их нод не хранит файл целиком, т.е. не предъявить незаконное копирование. Это основная мысль той системы Ну... DHT - то вообще не про файлы. Это про обмен ключей и значений в распеделённом интернете. Где половина хостов в любой момент времени могут быть выключены или недоступны. Где в сеть заходят новые машины за NAT, proxy и vpn. Где непрерывно идет репликация и появляются и исчезают новые ключи. Вобщем если захочешь - продолжим отдельным топиком. Меня в этой модели интересует вариант как быстро (после публикации) ключ станет доступен в условиях этой неопределённой доступности хостов. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2019, 21:35 |
|
Авторизация без сервера
|
|||
---|---|---|---|
#18+
Dima TmaytonЕсли тебе интересна тема распределенных хеш таблиц и поиска - можем поднять отдельный топик. Неинтересна. Это понижение надежности. Распределяем данные на 2 узла, надежность получения данных снижается в два раза. Мне интересна тема как записать сообщение на несколько (минимум) узлов и получить гарантированную возможность получения сообщения в любой момент. Ну... это вообще не про надёжность. Это про ... Криптономикон что-ли. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2019, 21:36 |
|
Авторизация без сервера
|
|||
---|---|---|---|
#18+
Dima Tтема как записать сообщение на несколько (минимум) узлов и получить гарантированную возможность получения сообщения в любой момент. Опаньки!! Уж полночь близится, снова на работу скоро, а они всё о своём ... Не смог удержаться: может это в сторону кодирования с автоматическим исправлением ошибок? хэмминг и т.п.? вспомнились раиды, где можно на лету выдёргивать не только диск из общей кучи, но и процессор ... Но это заведомая избыточность записи, чудес не бывает. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2019, 23:45 |
|
Авторизация без сервера
|
|||
---|---|---|---|
#18+
exp98Dima Tтема как записать сообщение на несколько (минимум) узлов и получить гарантированную возможность получения сообщения в любой момент. Опаньки!! Уж полночь близится, снова на работу скоро, а они всё о своём ... Не смог удержаться: может это в сторону кодирования с автоматическим исправлением ошибок? хэмминг и т.п.? вспомнились раиды, где можно на лету выдёргивать не только диск из общей кучи, но и процессор ... Но это заведомая избыточность записи, чудес не бывает. В блокчейн писать можно. В FreeNet или DarkNet Не помню точно где есть репликация контента по машинкам юзеров. Можно публиковать ресурс на torrent-ах, и надеятся что кто-то пару раз скачал. AWS S3. Google Drive. Microsoft Drive. Или просто купить любой жлобский хостинг для хомяка. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2019, 00:05 |
|
Авторизация без сервера
|
|||
---|---|---|---|
#18+
Dima TЭто понижение надежности. Распределяем данные на 2 узла, надежность получения данных снижается в два раза. Наоборот, она повышается. Это RAID уровня 1, а не 0. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2019, 14:53 |
|
Авторизация без сервера
|
|||
---|---|---|---|
#18+
Может я невнимательно прочитал, понял что куски файлов по нодам рассовываются. Не важно. Все-равно речь о протоколе P2P для хранения файлов, а это другое, не то что нужно мне. Меня интересует обмен сообщениями, которые никак хранить не надо. P2P в моем случае это прямая отправка между получателем и отправителем. Есть отдельная подтема оффлайн доставки при недоступности получателя, но ее можно пока не рассматривать. Я не собираюсь отказываться от центральной части, которая разрешает вход клиентам, помогает находить друг-друга, вводить новых участников и т.д. Задача не стоит сделать абсолютно децентрализованную систему. Меня и централизованная устроила бы, но она должна быть неубиваемой. Неубиваемость серверной части я вижу в подъеме нескольких серверов и репликации их состояний. Т.е. каждый сервер имеет инфу о всех открытых клиентских сессиях. Каждый клиент знает все сервера, поэтому при падении одного сервера клиент может легко переключиться на другой даже не теряя сессии. От P2P мне нужна только передача данных между клиентами, где все будет быстро и без ограничений, хоть гигабайты бэкапов гоняй. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2019, 19:14 |
|
Авторизация без сервера
|
|||
---|---|---|---|
#18+
И блокчейн не особо интересен. Да, туда можно внести логины клиентов с их открытыми ключами. Но это не все функции центра. Т.к. это UDP, то одна из задач сервера определить внешний IP:порт клиента и сообщить тому кто захочет с ним связаться. Т.к. связаться в одностороннем порядке не получится из-за NAT, из-за брэндмауэра, то кто-то третий должен сообщить клиенту что с ним хотят связаться с такого-то IP:порт. Нужен центр. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2019, 19:29 |
|
Авторизация без сервера
|
|||
---|---|---|---|
#18+
Dima TМожет я невнимательно прочитал, понял что куски файлов по нодам рассовываются. Не важно. Все-равно речь о протоколе P2P для хранения файлов, а это другое, не то что нужно мне. Меня интересует обмен сообщениями, которые никак хранить не надо. P2P в моем случае это прямая отправка между получателем и отправителем. Есть отдельная подтема оффлайн доставки при недоступности получателя, но ее можно пока не рассматривать. Я не собираюсь отказываться от центральной части, которая разрешает вход клиентам, помогает находить друг-друга, вводить новых участников и т.д. Задача не стоит сделать абсолютно децентрализованную систему. Меня и централизованная устроила бы, но она должна быть неубиваемой. Неубиваемость серверной части я вижу в подъеме нескольких серверов и репликации их состояний. Т.е. каждый сервер имеет инфу о всех открытых клиентских сессиях. Каждый клиент знает все сервера, поэтому при падении одного сервера клиент может легко переключиться на другой даже не теряя сессии. От P2P мне нужна только передача данных между клиентами, где все будет быстро и без ограничений, хоть гигабайты бэкапов гоняй. Коробочное решение - Infinispan. Посмотри. Возможно сойдет. http://infinispan.org/ ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2019, 21:44 |
|
|
start [/forum/topic.php?fid=16&gotonew=1&tid=1340007]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
59ms |
get topic data: |
14ms |
get first new msg: |
9ms |
get forum data: |
3ms |
get page messages: |
68ms |
get tp. blocked users: |
2ms |
others: | 246ms |
total: | 433ms |
0 / 0 |