Этропия для 4х4 - 68 бит, а у 3х3 - 38 бит. То есть по рассчетам, время на подбора 3х3 кратно ниже: подобрать изображение, где не совпадает 1 символ - около 1 часа, полная идентичность - 9 дней, а если атакующий использует rainbow таблицы, это может сильно ускорить.
Более того, мне непонятно желание искать адрес счета Алисы в этом самом списке
Тут возможны различные сценарии: 1. Использование блокчейн эксплорера вместо списка транзакций кошелька (ну они зачастую быстрее или когда открыто окно отправки транзакции, неудобно лезть в другой фрейм)
2. Автодополнение адреса самим кошельком, с сортировкой по времени транзакций (такая проблема была в Trust Wallet, но вроде пофиксили)
Мне кажется, самое главное - подсветить проблему, показать пример решения, объяснить разработчикам и пользователям. А по итогу конечный пользователь выберет наиболее удобное решение: можно ведь разные словари использовать: картинки, тэги, emoji, хеши и т. д.
Исходное предложение показывать хэш картинкой (Random Art), потому что люди сравнивают изображения лучше, чем строки. Отправная точка всей области и hh.
Онлайн-исследование более 400 человек, десять способов показа хэша. При одинаковых 24 битах T-Flag (8 блоков, 8 цветов, различимых при дальтонизме) дал 85 % верных ответов на трудных парах, Flag Extension (цвет плюс форма в блоке) 88 %, а Flag с 64 мелкими оттенками упал до 50 %, то есть до случайного угадывания. Отсюда правила hh: мало категориальных цветов, форма поверх цвета, никаких тонких оттенков.
Отмечает, что люди надёжно различают не более примерно 30 бит существующих визуальных хэшей, и строит CLPS (цвета, линии, узоры, фигуры) на 60 бит. Трудные пары распознаны верно в 96,6 % случаев рядом в лаборатории, но в 73,4 % в реалистичной проверке электронного голосования и в 78,6 % при проверке сертификата HTTPS. Поэтому hh считает картинку дополнением к проверке текста и требует сравнения бок о бок.
1 047 участников и шесть текстовых форматов: привычная шестнадцатеричная запись сильнее других уязвима для атак частичного совпадения, а изменения люди замечают в основном на «якорях» (начало, конец, переносы строк). Именно эту слабость использует отравление адресов.
Пакет и статья, скорее вредные, чем полезные: 1. Неверная работа с big numeric ( просто деление не прокатит), а также в Tron и EVM сетях разные юниты данных (10^6 и 10^18) соответственно 2. Во всех приведенных сетях формирование транзакций и подсчет газа отличается, а не "только адрес" (к стати в Tron представление адреса может быть и в HEX формате). В BSC до используются legacy транзакции, когда как в EVM после EIP-1559 - динамические, а Tron считается условно-совместимой EVM сетью, и там цена на газ и транзакции формируются иначе. 3. Вы используете для формирования пары ключей BIP-44 деривативный адрес для сети TRX, без описания (ну и сохранения мнемоники, указания энтропии passphrase, которая, к примеру используется при эталонных векторах тестирования). 4. Нет информации про кусок вашего ABI (причем для одного метода).
Примеры также не информативны и "вредны". В таком виде не подает информацию даже ChatGPT.
Раньше это открыто писали. KeyMap, интерфейс и функции взаимодействия с окнами аналогичны NetBeans. Я 3 года использовал NetBeans, потом перешел на продукты jet brains, так как раньше плагин golang поддерживался NetBeans, а затем запилили отдельную Goland.
Микс "блокчейн для чайников и выдранные углубленные вещи" с информацией 2 летней давности. Начали про Events, перешли к оракулам, так и не упомянув этот термин. Приводится устаревший, до EIP-1559 механизм подсчета газа.
У браузерных расширений и скриптов, криптография не самое слабое место. Более распостранены XSS, hijacking (в следствие выполнения кода в пользовательской среде). В зависимости от сценария, что-то можно упаковать в wasm, но вот если пользователь установил зловредное расширение, то inject и выполнение произвольного кода может производиться на любой странице.
Глаз Бога предоставляет информацию о тематике посещаемых пользователем групп по типу, вероятно получаемую от функциональных ботов, размещенных в группах или же модифицированных клиентов. Или вам предоставили дословные запросы?
Я написал в п. 2 "сообщение", без конкретного типа. В мессенджерах файл обычно отправляется сразу (проверка уникальности происходит на сервере), или в два этапа: сначала вычисляется хэш сумма на устройстве пользвателя, а затем проверяется наличие аналогичного файла в файловом хранилище сервиса. И при отрицательном результате, файл загружается на сервер. После чего получатель получает сообщение с сылкой на файл, клиентское приложение прозводит поиск в локальном кэше, и, если он отсутствует, пользователь может принять решение о его загрузке.
Наиболее простыми решениями мне видятся - тонкая настройка QoS (для выравнивания потока объема трафика) и бесконечный запущеный download agent, торрент клиент, или генератор трафика вроде Jperf.
Суть вышеописанного алгоритма также описана в тайминг-атаках Traffic confirmation attack, Малозатратная атака для сетей Tor, так как суть в сопоставлении трафика между отправителем и получателем.
Этропия для 4х4 - 68 бит, а у 3х3 - 38 бит.
То есть по рассчетам, время на подбора 3х3 кратно ниже: подобрать изображение, где не совпадает 1 символ - около 1 часа, полная идентичность - 9 дней, а если атакующий использует rainbow таблицы, это может сильно ускорить.
Тут возможны различные сценарии:
1. Использование блокчейн эксплорера вместо списка транзакций кошелька (ну они зачастую быстрее или когда открыто окно отправки транзакции, неудобно лезть в другой фрейм)
2. Автодополнение адреса самим кошельком, с сортировкой по времени транзакций (такая проблема была в Trust Wallet, но вроде пофиксили)
Мне кажется, самое главное - подсветить проблему, показать пример решения, объяснить разработчикам и пользователям. А по итогу конечный пользователь выберет наиболее удобное решение: можно ведь разные словари использовать: картинки, тэги, emoji, хеши и т. д.
Так об этом, собственно и расписано, просто материалов было очень много, я на все не сослался в статье:
Как люди сравнивают отпечатки:
Perrig, Song. Hash Visualization: a New Technique to Improve Real-World Security. 1999. https://users.ece.cmu.edu/~adrian/projects/validation/validation.pdf
Исходное предложение показывать хэш картинкой (Random Art), потому что люди сравнивают изображения лучше, чем строки. Отправная точка всей области и hh.
Hsiao, Lin, Studer, Studer, Wang, Kikuchi, Perrig, Sun, Yang. A Study of User-Friendly Hash Comparison Schemes. ACSAC 2009. https://netsec.ethz.ch/publications/papers/visual_hash_acsac09.pdf
Онлайн-исследование более 400 человек, десять способов показа хэша. При одинаковых 24 битах T-Flag (8 блоков, 8 цветов, различимых при дальтонизме) дал 85 % верных ответов на трудных парах, Flag Extension (цвет плюс форма в блоке) 88 %, а Flag с 64 мелкими оттенками упал до 50 %, то есть до случайного угадывания. Отсюда правила hh: мало категориальных цветов, форма поверх цвета, никаких тонких оттенков.
Olembo, Kilian, Stockhardt, Hülsing, Volkamer. Developing and Testing a Visual Hash Scheme. HAISA 2013. https://huelsing.net/wordpress/wp-content/uploads/2013/05/haisa-visualhash.pdf
Отмечает, что люди надёжно различают не более примерно 30 бит существующих визуальных хэшей, и строит CLPS (цвета, линии, узоры, фигуры) на 60 бит. Трудные пары распознаны верно в 96,6 % случаев рядом в лаборатории, но в 73,4 % в реалистичной проверке электронного голосования и в 78,6 % при проверке сертификата HTTPS. Поэтому hh считает картинку дополнением к проверке текста и требует сравнения бок о бок.
Dechand, Schürmann, Busse, Acar, Fahl, Smith. An Empirical Study of Textual Key-Fingerprint Representations. USENIX Security 2016. https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_dechand.pdf
1 047 участников и шесть текстовых форматов: привычная шестнадцатеричная запись сильнее других уязвима для атак частичного совпадения, а изменения люди замечают в основном на «якорях» (начало, конец, переносы строк). Именно эту слабость использует отравление адресов.
Пакет и статья, скорее вредные, чем полезные:
1. Неверная работа с big numeric ( просто деление не прокатит), а также в Tron и EVM сетях разные юниты данных (10^6 и 10^18) соответственно
2. Во всех приведенных сетях формирование транзакций и подсчет газа отличается, а не "только адрес" (к стати в Tron представление адреса может быть и в HEX формате). В BSC до используются legacy транзакции, когда как в EVM после EIP-1559 - динамические, а Tron считается условно-совместимой EVM сетью, и там цена на газ и транзакции формируются иначе.
3. Вы используете для формирования пары ключей BIP-44 деривативный адрес для сети TRX, без описания (ну и сохранения мнемоники, указания энтропии passphrase, которая, к примеру используется при эталонных векторах тестирования).
4. Нет информации про кусок вашего ABI (причем для одного метода).
Примеры также не информативны и "вредны". В таком виде не подает информацию даже ChatGPT.
Это Symphony Helio 80 из Бангладеша. Там он стоит 14000 рублей. В летних новостях, аннонсировали цену Р-ФОН в 40 тыс рублей
https://habr.com/ru/news/755222/
Раньше это открыто писали. KeyMap, интерфейс и функции взаимодействия с окнами аналогичны NetBeans.
Я 3 года использовал NetBeans, потом перешел на продукты jet brains, так как раньше плагин golang поддерживался NetBeans, а затем запилили отдельную Goland.
Я не смог это дочитать.
Микс "блокчейн для чайников и выдранные углубленные вещи" с информацией 2 летней давности. Начали про Events, перешли к оракулам, так и не упомянув этот термин. Приводится устаревший, до EIP-1559 механизм подсчета газа.
Снимаю шляпу перед автором, огромная работа проделана.
А как вы оценивали риски того, что в любой момент удаленка для сотрудников, находящихся вне РФ может быть запрещена?
JetBrains по сути форкнули и допилили NetBeans
Лучше docker
К сожалению, у меня нет ответа на данный вопрос.
У браузерных расширений и скриптов, криптография не самое слабое место. Более распостранены XSS, hijacking (в следствие выполнения кода в пользовательской среде). В зависимости от сценария, что-то можно упаковать в
wasm, но вот если пользователь установил зловредное расширение, то inject и выполнение произвольного кода может производиться на любой странице.Не стоит забывать, что родители и родственники Павла Дурова до сих пор живут в РФ
Это весьма серьезный прецедент, требующий огласки и исследования
Глаз Бога предоставляет информацию о тематике посещаемых пользователем групп по типу, вероятно получаемую от функциональных ботов, размещенных в группах или же модифицированных клиентов.
Или вам предоставили дословные запросы?
Я написал в п. 2 "сообщение", без конкретного типа.
В мессенджерах файл обычно отправляется сразу (проверка уникальности происходит на сервере), или в два этапа: сначала вычисляется хэш сумма на устройстве пользвателя, а затем проверяется наличие аналогичного файла в файловом хранилище сервиса. И при отрицательном результате, файл загружается на сервер. После чего получатель получает сообщение с сылкой на файл, клиентское приложение прозводит поиск в локальном кэше, и, если он отсутствует, пользователь может принять решение о его загрузке.
Наиболее простыми решениями мне видятся - тонкая настройка QoS (для выравнивания потока объема трафика) и бесконечный запущеный download agent, торрент клиент, или генератор трафика вроде Jperf.
Суть вышеописанного алгоритма также описана в тайминг-атаках Traffic confirmation attack, Малозатратная атака для сетей Tor, так как суть в сопоставлении трафика между отправителем и получателем.