24 декабря Архивач восстановлен после серьёзной аварии. К сожалению, значительная часть сохранённых изображений и видео была потеряна. Подробности случившегося. Мы призываем всех неравнодушных помочь нам с восстановлением утраченного контента!
Сортировка: за
Активный
2
27 мая 8:52
Активный
2
Главная проблема это анонимность а не шифрование. — Главная проблема это анонимность а не шифрование. Потому что нет нет проблем придти за отправителем или получателем зашифрованного сообщения и узнать у них как либо сообщение.А не взламываемый алгоритм уже есть это шифр Вернама вот таблица в десятичной форме для работы в ручную на бумаге под названием одноразовый шифроблокнот для компьютерных сетей таблица вот она называется XOR. Интернет не может быть анонимным по определению не какие TOR,I2P,VPN и прочие потому что у любого этого сервиса есть входные сервера в сеть а так же сервера для запутывания ну и выходные сервера в обычный интернет,а это значит что при желании эти сервера можно взять под контроль потому что это обычные сервера. Ну а так же не стоит забывать что при входе в эту сеть так же это видно. С шпионами вопрос решается проще коротковолновый передатчик(КВ волны по русски и SW волны)передает сообщение голосом а агент ловит его на обычный приемник,для агента это анонимно а вот для отправителя нет можно запеленговать передатчик и захватить радиста,но стоит понимать что разведцентр находится в тылу под надежной охраной но у анона такого нет так что и эта возможность отметается. Таким образом у анона возникает вопрос как передать и принять сообщение так что бы отправителя и получателя не заметили? Сразу говорю передача писем через животных например голубями это не вариант это очень долго и надо отправлять по нескольку голубей,мало ли вдруг с каким то голубем что то случится. Тайник(закладка)тоже не вариант мало ли может отправитель или получатель предатель и сдаст тайник и там уже засада противника. Так что в этой теме фантазируем как передать и принять сообщение безопасно?
27 мая 8:52
Активный
5
27 мая 8:52
Активный
2
27 мая 8:52
Активный
6
27 мая 8:52
Активный
13
27 мая 8:52
Активный
3
27 мая 8:52
Активный
1
27 мая 8:52
Активный
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). Поэтому, алсо, это тред о митм-защищённых схемах и алгоритмах обмена ключей, в открытых каналах.
27 мая 8:52
Активный
41
27 мая 8:52
Активный
4
27 мая 8:52
Активный
4
27 мая 8:52
Активный
32
27 мая 8:52
Активный
4
27 мая 8:52
Активный
9
27 мая 8:52
Активный
4
27 мая 8:52
Активный
4
27 мая 8:52
Активный
8
TideCoin thread! Tidecoin (TDC) был создан по образцу великих — TideCoin thread! Tidecoin (TDC) был создан по образцу великих криптовалют, таких как биткойн и лайткойн. Его главная особенность - пост-квантовая технология шифрования FALCON-512 ( https://csrc.nist.gov/projects/post-quantum-cryptography/round-3-submissions & https://falcon-sign.info ), что означает, что он будет защищен от квантовых компьютеров, которые могут выполнять вычисления в миллиарды раз быстрее, чем современные серверы. Биткойн, в частности, уязвим для таких атак, а это означает, что монеты потеряют ценность, когда такие компьютеры станут обычным явлением. Монета также является F/LOSS ПО, Bы можете проверить все исходные коды на github (например, подтвердить наличие шифрования). ОСНОВНОЙ FAQ: https://te.legra.ph/Tidecoin-04-24 NIST's Post-Quantum security standard Open Source Software Total supply: 21000000 TDC One minute block time, faster payment CPU friendly Pow algorithm, more inclusive Exponential increase halving time: 0.5, 1, 2, 4, ...Years Главный сайт: http://tidecoin.org/ Сайт новый от комьюнити:: https://tidecoin.pqcsf.com/ Bitcointalk: https://bitcointalk.org/index.php?topic=5306694.0 Whitepaper: https://github.com/tidecoin/whitepaper/blob/master/tidecoin.pdf Основной канал: https://t.me/TidecoinTDC Биржа: https://www.tidecoin.exchange/ Кошелек: https://github.com/tidecoin/tidecoin/releases Twitter:https://twitter.com/tidecoin Discord:https://discord.gg/8twPh8hjwU Explorer: http://explorer.tdc.cash/ FAQ: https://te.legra.ph/Tidecoin-04-24 ФОРУМ: https://tidecoin.ru/index.php Актуальные треды в /сс/: https://2ch.hk/cc/res/691475.html https://2ch.hk/cc/res/603769.html
27 мая 8:52
Активный
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 при запуске клиента (особенно при первом)? Не доверять же первому встречному пиру. Как лучше передавать файлы? Искать у случайного владельца файла и качать целиком, или скачивать у всех но порциями (как в торрентах)? мимо ламер
27 мая 8:52
Активный
8
27 мая 8:52
Активный
2
Apple Mac OS X — С какой версии там зондовкак в windows 10? Какая на уровне windows 7? Чтобы система не делала всякие скриншоты и не отправляла данные ввода клавиатуры, чтобы apple без меня не могли получить удаленный доступ к компьютеру, сейчас же если позвонить в сапорт они могут сами подключиться без моего участия, это работает только если ввёл Apple ID? > Доступ к моему Mac — это функция службы iCloud, которая позволяет настроить сетевое подключение между компьютерами Mac для удаленного доступа к ним. В 10.7 lion появился icloud, значит с этой версии это как винда 10? Но handoff появился только в 10.10 а буфер обмена между устройствами и Siri с 10.12 В 10.13 завезли всяких нейросетей которые сканируют файлы, посещаемые сайты и т.д. С 10.14 , а может и в более старых с обновлением, отправляет в Apple хэш при запуске каждой программы Выходит последняя Mac OS по уровню зондов как windows 7 это 10.6 snow leopard 2009 года?
27 мая 8:52
Активный
3
27 мая 8:52
Активный
4
27 мая 8:52
Активный
3
27 мая 8:52
Активный
17
27 мая 8:52

Отзывы и предложения