У генератора слишком много сайдэффектов. И какая разница, быстрее выполняется for, чем while? Пишите понятный код, а скорость придет естественным образом. Сравните ваш генератор и:
import logging
from itertools import islice
from pathlib import Path
from random import randrange
logging.basicConfig(level=logging.DEBUG)
logger = logging.getLogger(__name__)
def ips():
while True:
a = randrange(256)
b = randrange(256)
c = randrange(256)
d = randrange(256)
yield f'{a}.{b}.{c}.{d}'
def write_out(filename, lines):
with Path(filename).open('a', encoding='utf8') as fp:
for line in lines:
fp.write(f'{line}\n')
write_out('ip-addresses.txt', islice(ips(), 100))
logger.info('Complete!')
Самое главное, судя по иллюстрациям — отодвинуть монитор метра на полтора, а лучше на три. Несомненно развивает остроту зрения, да и радиация убывает по закону шагающих кубов, что крайне положительно влияет на осанку.
Выглядит, как что-то очень крутое. Однозначный плюс — это удачное, по всей видимости, сочетание метапрограммирования, системного программирования и интерпретатора. Минус — недостаточно знать только C — нужно знать еще и Lua.
И не до конца понятно, правда, где это предлагается использовать. Вместо чистой Lua? В качестве самостоятельного системного языка?
Выходит, можно при первом визите пользователя провести все тесты при помощи JS, затем отправить результат на сервер, сохранить его в cookie, и сервер сможет выдавать правильные сгенерированные стили под именно этот браузер, исходя из уровня актуальной поддержки.
Учитывая, что пару дней назад сценаристом HL2 был опубликован «фанфик», раскрывающий сюжет HL2 Ep3, то можно с уверенностью заявить, что HL2 Ep3 либо HL3 не выйдут никогда. Вообще никогда.
Если отказаться от sizzle, умрет поддержка CSS4-селекторов типа :has(), которой много где нет. Ну и sizzle по возможности и так старается использовать нативные функции для селекторов.
Насчет IoT — насколько вероятна угроза цензуры общения между IoT-устройствами? Если не слишком вероятна, то, возможно, подобные меры просто не стоит в них использовать?
Например, "десктопное" устройство может сначала пытаться работать с прологом, как с настоящим пакетом, и в случае некорректных входящих данных, пытаться декодировать его, как пакет с мусорными блоками. IoT-устройства могут даже не пытаться декодировать мусор и просто считать это некорректной передачей.
т.к. вероятность что что-то осмысленное получится после 1000 раундов SHA256 очень мала, а умножив это на количество блоков мы получим вообще исчезающе малую величину.
Вы не совсем правы. В предложенной мной схеме речь не идет о поиске такого прообраза, после хэширования которого мы получим "осмысленный пакет" (т.е. некую фиксированную битовую последовательность) — вероятность угадать такой прообраз, учитывая, что выхлоп сильной хэш-функции можно полагать случайным, составляет 2**(-N), где N — длина искомого "смысла". 100-битный осмысленный пакет можно искать неимоверно долго, и абсолютно впустую — добывать биткоины при таком количестве свободного времени и ресурсов явно выгоднее :)
Предложенную схему не стоит рассматривать как средство сокрытия информации — очевидно же, что если ваш пакет начинается с "Lorem ipsum" (88 бит), то каждый 309485009821345068724781056-й в среднем пакет должен будет "расшировываться" в "Lorem ipsum", и если наблюдаемая частота таких сообщений значительно превышает ожидаемый среднестатистический, то это "бжжж" тут явно неспроста.
Суть же предложенной мной схемы как раз заключается в том, чтобы сделать слежку невозможной именно в глобальных масштабах, основываясь на, скажем, эдаком proof-of-work. Если невозможно заранее, глядя только на мусорные блоки, отличить их от настоящего мусора, то атакующей стороне в любом случае потребуется потратить энное количество ватт (времени, денег) на вычисление хэш-функции от этого мусорного блока.
И если поток сквозных данных превысит возможности атакующей стороны по вычислению хэшей, им придется либо пропускать часть трафика, либо в принципе отказаться от идеи вычислять хэши для произвольных данных. Причем инициатору соединения даже необязательно использовать истинно случайные блоки — можно притворяться чем-то другим, лишь бы все еще было достаточно степеней свободы для подбора хэша с требуемыми свойствами.
Утрируя, мы можем передавать 1 бит данных в 128 битах мусора. Уже даже с такой избыточностью невозможно составить таблицу соответствия мусорных данных истинным данным, значит, DPI-фильтру придется "играть честно", и чем сложнее будет для вычисления хэш-функция (pbkdf2? scrypt? bcrypt?), тем меньшее количество сообщений выйдет декодировать, потратив 1 кВт, и тем быстрее правительству^W атакующей стороне это надоест.
Ну а процент "ложноположительных срабатываний" у этой схемы и так статистически неотличим от шума, куда уж лучше?
Как уже упомянул Sklott несколькими комментариями выше, этот протокол очень легко обнаружить по хендшейку и отфильтровать посредством DPI. Несколько лет назад у меня возникла идея, как можно с этим бороться и сделать создание правила для DPI-фильтра невозможным на практике.
Суть идеи заключается в том, чтобы вместо открытых данных пересылать случайные данные, но которые можно по некоторому заранее известному, желательно трудозатратному алгоритму без секретной компоненты, преобразовать обратно в открытые данные.
Таким образом, это не добавит какой-либо секретности в пересылаемые данные, но затруднит их непосредственный анализ без предварительной обработки, которая в масштабах глобального прослушивания повлечет за собой как минимум ложнопозитивные сработки, и как максимум — невозможность справиться с потоком данных с точки зрения требуемых ресурсов.
Для кодирования следует разбить открытые данные на чанки по N бит, затем для каждого чанка нужно брутфорсом подобрать такой случайный блок данных фиксированного размера H, который при декодировании превратится в ожидаемый чанк открытых данных в N бит размером. Пример такой процедуры декодирования — циклически посчитать SHA256 от блока случайных данных 1000 раз, и затем вернуть младшие N бит хэша.
Приведу пример декодирования готовой строки. Допустим, у нас есть следующие бинарные данные:
Мы заранее знаем, что открытый текст делился на блоки по 8 бит каждый, и что мы использовали блоки "шифротекста" по 32 бита.
Первый блок — 4b 82 93 6a.
SHA256 от него = 486b84b02736885238a0d8ba871a78262362f1dfe7422f1d50b257ed6c99bcc3.
Младшие 8 байт этого хэша в little endian = 0x48, т.е. "H" в ASCII.
Следующий блок — b5 0f 39 9b.
SHA256 от него = 6546ec1ccea61e68c70671b6a04d9a074c0bf024f92d72d9103e78c3641801eb.
Младшие 8 байт этого хэша в little endian = 0x65, т.е. "e" в ASCII.
Продолжая декодирование таким же образом, получим строку "Hello, world!".
Насчет учетных данных, мне казалось, что дело обстоит иначе. Я где-то читал, что сайты, на которых хранятся научные работы, имеют белый список IP-сетей, принадлежащих университетам, которые оплатили подписку, и с которых разрешается доступ к требуемым материалам без авторизации. И, собственно, sci-hub работает по принципу агрегации прокси, которые расположены в университетских сетях.
У генератора слишком много сайдэффектов. И какая разница, быстрее выполняется for, чем while? Пишите понятный код, а скорость придет естественным образом. Сравните ваш генератор и:
Теперь можно и поддержку подсетей в ips() реализовать, и ничего не сломается, и https://docs.python.org/3/library/ipaddress.html использовать, да и вообще, немного чище все стало :)
Портировать Linux-подсистему, и на ней уже запускать нативный ELF с Wine, и уже с его помощью запускать JVM и Windows-приложения :)
Восхитительный продукт! Надеемся увидеть версию на WCT, Mihip вам в помощь!
Выглядит, как что-то очень крутое. Однозначный плюс — это удачное, по всей видимости, сочетание метапрограммирования, системного программирования и интерпретатора. Минус — недостаточно знать только C — нужно знать еще и Lua.
И не до конца понятно, правда, где это предлагается использовать. Вместо чистой Lua? В качестве самостоятельного системного языка?
Выходит, можно при первом визите пользователя провести все тесты при помощи JS, затем отправить результат на сервер, сохранить его в cookie, и сервер сможет выдавать правильные сгенерированные стили под именно этот браузер, исходя из уровня актуальной поддержки.
Дайте-ка я угадаю — "немного кода" заключалось в простом копипасте этого массива в консоль Python?
P.S. Пардон, пока читал, успели оставить комментарий с такой же догадкой.
Минусы, потому что я где-то ляпнул очевидную глупость, и сам того не заметил? Или метод решения не подходит под условия задачи?
Если отказаться от sizzle, умрет поддержка CSS4-селекторов типа :has(), которой много где нет. Ну и sizzle по возможности и так старается использовать нативные функции для селекторов.
Но это "проблема останова", а не "приостановка работы".
Так много вопросов, так мало ответов ;)
Насчет IoT — насколько вероятна угроза цензуры общения между IoT-устройствами? Если не слишком вероятна, то, возможно, подобные меры просто не стоит в них использовать?
Например, "десктопное" устройство может сначала пытаться работать с прологом, как с настоящим пакетом, и в случае некорректных входящих данных, пытаться декодировать его, как пакет с мусорными блоками. IoT-устройства могут даже не пытаться декодировать мусор и просто считать это некорректной передачей.
Вы не совсем правы. В предложенной мной схеме речь не идет о поиске такого прообраза, после хэширования которого мы получим "осмысленный пакет" (т.е. некую фиксированную битовую последовательность) — вероятность угадать такой прообраз, учитывая, что выхлоп сильной хэш-функции можно полагать случайным, составляет
2**(-N), где N — длина искомого "смысла". 100-битный осмысленный пакет можно искать неимоверно долго, и абсолютно впустую — добывать биткоины при таком количестве свободного времени и ресурсов явно выгоднее :)Предложенную схему не стоит рассматривать как средство сокрытия информации — очевидно же, что если ваш пакет начинается с "Lorem ipsum" (88 бит), то каждый 309485009821345068724781056-й в среднем пакет должен будет "расшировываться" в "Lorem ipsum", и если наблюдаемая частота таких сообщений значительно превышает ожидаемый среднестатистический, то это "бжжж" тут явно неспроста.
Суть же предложенной мной схемы как раз заключается в том, чтобы сделать слежку невозможной именно в глобальных масштабах, основываясь на, скажем, эдаком proof-of-work. Если невозможно заранее, глядя только на мусорные блоки, отличить их от настоящего мусора, то атакующей стороне в любом случае потребуется потратить энное количество ватт (времени, денег) на вычисление хэш-функции от этого мусорного блока.
И если поток сквозных данных превысит возможности атакующей стороны по вычислению хэшей, им придется либо пропускать часть трафика, либо в принципе отказаться от идеи вычислять хэши для произвольных данных. Причем инициатору соединения даже необязательно использовать истинно случайные блоки — можно притворяться чем-то другим, лишь бы все еще было достаточно степеней свободы для подбора хэша с требуемыми свойствами.
Утрируя, мы можем передавать 1 бит данных в 128 битах мусора. Уже даже с такой избыточностью невозможно составить таблицу соответствия мусорных данных истинным данным, значит, DPI-фильтру придется "играть честно", и чем сложнее будет для вычисления хэш-функция (pbkdf2? scrypt? bcrypt?), тем меньшее количество сообщений выйдет декодировать, потратив 1 кВт, и тем быстрее правительству^W атакующей стороне это надоест.
Ну а процент "ложноположительных срабатываний" у этой схемы и так статистически неотличим от шума, куда уж лучше?
Хотя, возможно, мое замечание нерелевантно… но мне тогда жалко удалять написанное.
Как уже упомянул Sklott несколькими комментариями выше, этот протокол очень легко обнаружить по хендшейку и отфильтровать посредством DPI. Несколько лет назад у меня возникла идея, как можно с этим бороться и сделать создание правила для DPI-фильтра невозможным на практике.
Суть идеи заключается в том, чтобы вместо открытых данных пересылать случайные данные, но которые можно по некоторому заранее известному, желательно трудозатратному алгоритму без секретной компоненты, преобразовать обратно в открытые данные.
Таким образом, это не добавит какой-либо секретности в пересылаемые данные, но затруднит их непосредственный анализ без предварительной обработки, которая в масштабах глобального прослушивания повлечет за собой как минимум ложнопозитивные сработки, и как максимум — невозможность справиться с потоком данных с точки зрения требуемых ресурсов.
Для кодирования следует разбить открытые данные на чанки по N бит, затем для каждого чанка нужно брутфорсом подобрать такой случайный блок данных фиксированного размера H, который при декодировании превратится в ожидаемый чанк открытых данных в N бит размером. Пример такой процедуры декодирования — циклически посчитать SHA256 от блока случайных данных 1000 раз, и затем вернуть младшие N бит хэша.
Приведу пример декодирования готовой строки. Допустим, у нас есть следующие бинарные данные:
Мы заранее знаем, что открытый текст делился на блоки по 8 бит каждый, и что мы использовали блоки "шифротекста" по 32 бита.
Первый блок —
4b 82 93 6a.SHA256 от него =
486b84b02736885238a0d8ba871a78262362f1dfe7422f1d50b257ed6c99bcc3.Младшие 8 байт этого хэша в little endian =
0x48, т.е."H"в ASCII.Следующий блок —
b5 0f 39 9b.SHA256 от него =
6546ec1ccea61e68c70671b6a04d9a074c0bf024f92d72d9103e78c3641801eb.Младшие 8 байт этого хэша в little endian =
0x65, т.е."e"в ASCII.Продолжая декодирование таким же образом, получим строку "Hello, world!".
И для демонстрации, я сделал наивную PoC-реализацию описанного выше подхода на Python: https://gist.github.com/toriningen/7c56c262bff38fda40b5cb6a014b87a2