Добавлена поддержка Ежчана (ejchan.net, ejchan.site). Набегаем, тестируем архивацию, сообщаем о замеченных проблемах.
К сожалению, значительная часть сохранённых до 2024 г. изображений и видео была потеряна (подробности случившегося). Мы призываем всех неравнодушных помочь нам с восстановлением утраченного контента!
Сортировка: за
Сохранен
25
Идея защифрованной детцентрализованной почты! — Сап, Анонимусы! Я тут думал над тем, как можно реализовать по-настоящему децентрализованную почту, с функцией пересылки вложений. Да, я знаю, что уже есть божественный Bitmessage, но там нельзя пересылать вложения, что само по себе разумно, при его схеме работы. Так вот, в чем заключается моя идея работы программы, которая вполне может быть реализована на базе Tox Messenger или Bitmessage: 1-Аннон №1 и Аннон №2 обменялись ключами и добавили друг-друга в адресную книгу. 2-Аннон №1 пишет Аннону №2 письмо и если хочет добавляет вложение, прога шифрует все это, так, чтобы только Аннон №2 смог расшифровать своим ключом. (как и всегда, впрочем). Далее прога автоматически заливает получившийся защифрованный контейнер на какое-нибудь файловое хранилище, Яндекс-Диск, Дропбокс, Гугл-диск и т.д., в котором предварительно регистрируется Аннон №1, и после заливки, как и в проге Bitmessage, в сеть высылается инфо-письмо Аннону №2, которое опять же, как и в Bitmessage, может расшифровать только Аннон №2, в этом письме содержится ссылка на адрес, куда прога Аннона №1 залила зашифрованный контейнер с письмом и вложением. Прога Аннона №2, получив это инфо-сообщение, автоматически скачивает контейнер с письмом, расшифровывает и открывет его для прочтения. Одновременно, даже можно сделать функцию, потверждения прочтения, как в обычных почтовых сервисах, опять же с пересылкой по Bitmessage обратно Аннону №1. Получается, что: -все зашифровано -размер вложений ограничен только возможностями файлового хостинга Как вам такая идея? Давайте свои мнения. Как думаете взлетит или нет? Только обоснуйте нормально!
2025-09-11 06:56:16
Сохранен
3
2025-09-11 06:56:16
Сохранен
3
2025-09-11 06:56:16
Сохранен
1
2025-09-11 06:56:16
Сохранен
11
Авторизации тред. — Перекат из программача /pr/ : https://2ch.hk/pr/res/2035184.html Я думаю, эта тема достойна отдельного треда в криптаче. Добро пожаловать в авторизации тред. Здесь мы рассмотрим, казалось бы, простую задачу - реализацию регистрации-авторизации клиента на сервере. Но рассмотрим мы её, с точки зрения перехвата снифферами данных, передающихся по открытому каналу, а также с точки зрения возможности реализации MITM-атак. Дано: 1. Сервер с базой данных, и таблицей Users внутри. Данные юзеров - попадают в строчки этой таблицы, при их регистрации. Структура таблицы - вариативна, и предлагается здесь. 2. Клиент - юзер, который регистрируется, и который заходит в аккаунт. 3. Алгоритмы работы системы. 3.1. Регистрация. 3.2. Вход с данными. 3.3. Вход по кукам. 3.4. Восстановление доступа. 4. Взломщики: 4.1. Сниффер, перехватывающий данные в открытом канале, в том числе и куки, но не могущий подменять данные. 4.2. Митмщик, который стоит между сервером и клиентом. У него могут быть снифферы, и он может ещё и подменять данные. 4.3. Кулхацкер, взломавший сервер, базу данных внутри него, и имеющий доступ к таблице Users и значениям внутри неё. Задача: Реализовать алгоритмы, чтобы взломщики соснулей. Моё видение решения: 1. Чтобы соснул кулхацкер, надо хранить хэши паролей в базе, а не пароли, а данные хранимые в базе - шифровать. Как шифровать, хз правда, но это интересно. 2. Чтобы соснул сниффер, надо юзать временные куки, которые меняются с каждым перелогином юзера, а также менять их в случае попытки доступа с другого IP/UserAgent. 3. Чтобы соснул митмщик, надо реализовать криптосистему с открытым ключем, и сделать публичный ключ сервера прешаренным, вшить его в исходник скриптов на клиенте, а хэш исходников - опубликовать. Но митмщик, может подделать и хэш, и выкачиваемый исходник - короче пиздос, хз что делать тут. К HTTPS, доверия нет, потому что оно митмается, пик2. Поэтому будем рассматривать, что-нибудь поверх HTTP, то есть работать будем в открытом канале. Митмается также ssh (пик1), Diffie-Hellman Key Exchange (пик3), и RSA (пик4). Поэтому, алсо, это тред о митм-защищённых схемах и алгоритмах обмена ключей, в открытых каналах.
2025-09-11 06:56:16
Сохранен
5
Сап криптач. Я пишу сюда потому что произошло — Сап криптач. Я пишу сюда потому что произошло нечто странное и непонятное. Вообщем, сижу я впараше и переписываюсь со своим другом как вдруг мне на аватарку написали комментарий, просто рандомное слово, смотрю и там лайк (на комментарий) от чела с которым я переписываюсь. Я делаю скриншот и показываю ему, типо что за хуйня, он в недоумении говорит что не лайкал и пошёл менять пароль с мыслями о взломе его аккаунта. Можно было бы подумать что он пиздит, но лайк появился сразу после написания комментария. Он посмотрел в сеансах появления в сети, но кроме его самого пользования больше никого не было. Начал чекать профиль с которого писали: какая то тян, в закрепе у которой пост с намеками на секс и тд. Дата регистрации 2012 год. На стене активность угасла в 2018 году и появилась 6 марта (вчера), сразу несколько репостов, будто бы для отвода глаз и пост с закрепа. На авке фотки тян, которые гуглятся и тоже были загружены 6 марта. Но это все было бы неважно, если бы не комментарий, который оставили на моей аватарке. Мне изначально показалось, что это просто рандомное слово для привлечения внимания к спам-странице, но потом как осенило, что этим словом ориентируются к моему дому где я живу, т.е когда спрашивают как пройти, говорят его (это название магазина, и оно довольно специфичное, поэтому это не могло быть совпадением) и этот странный лайк от моего товарища. Страница впараше у меня фейковая, во френдлистах никого нет, переписку ввёл с людьми, которые далеко от меня в ирле, т.е по странице никак узнать кто я и где нахожусь нереально. Так вот, криптач, кто это может быть? Чего он от меня хочет? Менты? Бред. Нахуй им вообще такие свистоперделки. Недоброжелатель? Бред, я в жизни и мухи не обидел. Прошу, анон, расскажи твои мысли по поводу этой ситуации, тут можно класть хуй или на всякий случай уже начать носить с собой нож?
2025-09-11 06:56:16
Сохранен
2
2025-09-11 06:56:16
Сохранен
1
2022-12-24 12:47:10
Сохранен
24
2025-09-11 06:56:16
Сохранен
10
2025-09-11 06:56:16
Сохранен
4
2025-09-11 06:56:16
Сохранен
13
Сеть HIVE — Я придумал p2p-аналог интернетов, который относительно не трудно реализовать. Сеть не нужно настраивать (zeroconf), и является юзерфрендли. > Зачем? На криптаче такие глупые вопросы не задают. > Чем лучше аналогов? У каждой скрытосети свои плюсы и минусы. Эта сеть - просто еще одна альтернатива. Предлагаю обсудить проект, и может присоединиться к его разработке. Начнем рассматривать с самого высокого уровня сети - обычного пользователя сети (не программиста): 1. Юзер скачивает пакет. 2. Устанавливает. 3. Происходит магия. 4. Заходит в браузер. 5. Набирает hive:410/test.p2p 6. Заходит на сайт. Когда заходит просто на hive:410 - открывает домашнюю страницу проекта с менеджером файлов и прочими настройками и интересностями. Опускаемся ниже : уровень данных. Как вообще выглядит Hive? Представьте себе кучу файлов имеющих фактический адрес (хеш). К любому файлу обраться по адресу hive:410/${hash}. Но для удобства использования сети, мы можем называть файлы человекочитаемыми именами. Делается это с помощью HNS (Hive NameSpace) - распределенной хештаблицы. К примеру, программист создал html-файл, и создал в HNS запись что к данному файлу можно обратиться по "example.hive" и подписал запись. Заметили? Здесь нет концепции "сайта" как некой папки с файлами. Все файлы сети находятся в куче и нет разделения между сайтами. Программист создает папку с проектом и специальная утилита загружает все файлы проекта в "кучу" подписывая в HNS файлы как {"test.p2p/js/main.js": "==Hxkdhiei6473...", к примеру. Обращаться можно как публичному имени, так и по хешу. Хеш удобен в случае медиаконтента, публичное имя удобно в случае рабочих файлов проекта (скриптов, баз данных и тд). Хеш публичного имени можно заменить. Само API улия убийственно простое: 1. GET hive:410/${hash|pubname} - запросить файл по имени или хешу. 2. POST hive:410 - отправить файл в кучу. 3. PUT hive:410/${pubname} - обновить запись в HNS (доказав, что владелец записи). Либо создать запись. 4. DELETE hive:410/${hash|pubname} - в случае с публичным именем - удаляет запись. В случае хеша - удаляет файл в локальной куче пользователя. Есть зарезервированные публичные имена для локальных DB юзера. Еще ниже, уровень пиров: В Hive используется IPv6. Понятное дело, пользователей с IPv6 по пальцам пересчитать, потому используем костыль Miredo/Teredo, идущий как зависимость пакета. Miredo не требует к конфигурации, оно просто устанавливается вместе с пакетом и дает тебе IPv6 без какой-либо задней мысли. На это уровне так же есть DHT включающий все пиры в сети. Как получить Peer DHT если ты в первый раз зашел в сеть? Через публичные пиры, работающие на постоянной основе. Они либо будут прописаны в конфиге изначально, либо надо будет искать на Github список публичных пиров и прописывать их в конфиге ручками, как это надо делать с Yggdrasil. hive:410 как вы уже поняли представляет собой локальный http-сервер. Когда клиент запустился, он пытается обновить все свои DHT. Когда юзер пытается получить файл, сервер смотрит в DHT и ищет там у кого можно этот файл взять, и обращается к ним. Файл скачивается, и юзер начинает раздавать его другим. Он отправляет всем другим юзерам весть о том, что этот файл можно найти у него. Когда юзер постит файл он отправляет другим пирам весть о том, что он добавил новый файл и то, что этот файл можно взять у него. Когда юзер обновляет запись в HNS он подписывает изменения и вещает об этом. Другие пользователи проверяют изменения и в случае мутной хуйни отклоняют изменения в локальной NHS. Тоже самое происходит при удалении записи, правда, запись не пропадает бесследно, вместо нее появляется запись с тем же адресом, но вместо хеша - сообщение о том, что запись удалена подпись владельца(ов) записи. Удаленную запись можно будет обновить с новым хешем позже и уже это уже сможет сделать другой владелец, однако информация о предыдущем владельце остается. И так немного по вопросам к реализации непосредственно опытным криптачерам: Стоит ли писать сервер сразу на bash? Меньше зависимостей будет. Правда, теряется кроссплатформенность. Но над ней в принципе придется поработать в любом случае. Как лучше всего поддвержать и проверять на законность тех или иных изменений в HNS? Как лучше организовать броадкаст по сети? Не будешь же ко всем пирам (их и тысячи могут быть) в сети подключаться. Предлагаю распространять "волной": передаешь запись трем пирам, каждый из них перепадает еще трем и так по всей сети. Как лучше всего получать новые DHT при запуске клиента (особенно при первом)? Не доверять же первому встречному пиру. Как лучше передавать файлы? Искать у случайного владельца файла и качать целиком, или скачивать у всех но порциями (как в торрентах)? мимо ламер
2025-09-11 06:56:16
Сохранен
1
2025-09-11 06:56:16
Сохранен
2
2025-09-11 06:56:16
Сохранен
4
2025-09-11 06:56:16
Сохранен
7
2025-09-11 06:56:16
Сохранен
4
2025-09-11 06:56:16
Сохранен
8
2025-09-11 06:56:16
Сохранен
8
2022-12-24 12:47:10
Сохранен
43
2025-09-11 06:56:16
Сохранен
3
2025-09-11 06:56:16
Сохранен
5
2025-09-11 06:56:16
Сохранен
4
2025-09-11 06:56:16
Сохранен
7
2025-09-11 06:56:16
Сохранен
17
2025-09-11 06:56:16