Ок, немного технической информации, что из себя представляет ваше приложение:
Предварительно сгенерированный 35 минутный mp3 файл в обертке из плеера и анимации а-ля осциллограмма.
В самом файле все 35 минут - синус частотой 300Hz, амплитудно модулированный синусом 0.25Hz, левый и правый канал совпадают.
Воистину потрясающе, что тщательно экспериментально подобранные значения оказались столь круглыми числами. Нумерологи в восхищении.
Для желающих посмотреть послушать, что нам предлагают без скачивания приложения из маркета - скрипт генерации аналогичного файла для Audacity (вводить в Tools->Nyquist Prompt, предварительно создав пустой файл нужной длины):
Еще раз повторю вопрос: зачем вы шифруете данные (содержимое файлов) на вашем АШ, а не на компьютере ?
В "АШ" (в дальнейшем - токене) хранится долговременный ключ. Это может быть как закрытый ключ асимметричного алгоритма, так и ключ симметричного, но асимметрия по многим причинам удобнее. Все операции с ним проводятся только внутри токена и этот ключ токен не покидает (и не может быть извлечен) ни при каких обстоятельствах, т.к. его компрометация приводит к возможности расшифровки всех ранее зашифрованных данных.
Но шифровать данные непосредственно долговременным ключом по многим причинам не стоит. Данные шифруются симметричным алгоритмом случайно сгенерированным сессионным ключом, уникальным для каждого шифруемого файла/блока/whatever (который затем шифруется долговременным ключом и добавляется к шифрованным данным).
Компрометация сессионного ключа ведет только к возможности расшифровки данных им же зашифрованных. А к этим данным в незашифрованном виде [недоверенный] компьютер и так имеет доступ и потенциальная компрометация сессионного ключа не влияет ни на что и работу с этим сессионным ключом можно смело вести на компьютере.
Посему задача токена - шифровать* сессионные ключи. Гонять же через него сами данные - пустая трата ресурсов.
(*) а в случае асимметричного долговременного ключа по большому счету - только расшифровывать, для (за)шифрования он необязателен.
Вам не кажется странным, что ничего не поняли вы, а читать вы отправляете меня ? )
Стандартная схема шифрования больших объемов данных асимметричной криптографией - сгенерировать случайный ключ для симметричного алгоритма, зашифровать большой объем данных им, а сам этот ключ зашифровать асимметричным алгоритмом и положить рядом с зашифрованными данными.
И в аппаратные токены убирают именно закрытый ключ от асимметрии и все операции с ним. Ну и rng тоже можно в него же засунуть.
А в чем смысл шифровать данные на аппаратном ключе ?
Чем плох традиционный способ с хранением а АК ключевой пары асимметричного шифра и генерация ключей для симметричного алгоритма на АК.
А уже шифрование данных симметричным алгоритмом - на хост-системе. Это и упрощает как реализацию АК (чем проще, тем сложнее накосячить) и снимает вопросы со скоростью. Ну и готовых решений на рынке масса.
Опасения компрометации симметричного ключа? Так данные, шифруемые этим ключом, и так доступны на хост системе открытым текстом.
И как отличать во время всплеска ботовские 1920*1080@Win10 от примерно половины десктопных пользователей, использующих десятую винду и fullhd монитор ?
если UDP сессия не началась с Handshake Initiate - Handshake Response, то претензий к данной сессии у DPI не будет
А зачем тогда хитрые телодвижения с соксом ? (я при беглом прочтении так и не понял, как именно вы его используете).
Шлите первым пакетом со стороны клиента какой-нибудь мусор, сервер этот пакет проигнорирует, но на брандмауэре сессия создастся и она будет начинаться с этого мусора, а не с wireguard handshake
Лучше кому ?
за произведение двух синусоид
Вы хоть сами поняли, что за бред вы сейчас написали ? )
Несущая, если уж использовать термины из радиосвязи, в вашем сигнале - 300Гц
А 44100 - частота дискретизации. И при данных параметрах сигнала вообще пофиг, какая она. Даже 8000 будет за глаза.
Уже сделал. Вряд ли, конечно, рабочий. Но точь-в-точь как у вас.
https://habr.com/ru/post/653597/#comment_24116167
У меня есть шикарная идея для еще одного приложения с такой же схемой монетизации: программный восход солнца вручную.
Если в течение 24 часов с момента запуска солнце не взошло - вернуть. На заполярные регионы гарантия не распространяется.
Ок, немного технической информации, что из себя представляет ваше приложение:
Предварительно сгенерированный 35 минутный mp3 файл в обертке из плеера и анимации а-ля осциллограмма.
В самом файле все 35 минут - синус частотой 300Hz, амплитудно модулированный синусом 0.25Hz, левый и правый канал совпадают.
Воистину потрясающе, что тщательно экспериментально подобранные значения оказались столь круглыми числами. Нумерологи в восхищении.
Для желающих
посмотретьпослушать, что нам предлагают без скачивания приложения из маркета - скрипт генерации аналогичного файла для Audacity (вводить в Tools->Nyquist Prompt, предварительно создав пустой файл нужной длины):(scale 0.8 (mult (hzosc 300)(hzosc 0.25)))На всякий случай: в гугловском маркете вернуть можно в течении двух часов.
В принципе на ознакомление с этим приложением чуть больше, чем достаточно
Даже собирать ничего не нужно: генерируете требуемый звуковой файл в любом аудиоредакторе и запускаете на проигрывание в любом аудиоплеере.
Собственно приложение автора так и устроено: sound.mp3 на полсотни мегабайт и простенькая обертка плей/пауз.
Понятное дело, что у других дилеров товар бодяженый, но я честно говоря не
вижуслышу принципиальной разницы с этой хайповой ндцать лет назад темой.Вау, аудионаркотики возвращаются! Теперь и снотворное.
Еще раз повторю вопрос: зачем вы шифруете данные (содержимое файлов) на вашем АШ, а не на компьютере ?
В "АШ" (в дальнейшем - токене) хранится долговременный ключ. Это может быть как закрытый ключ асимметричного алгоритма, так и ключ симметричного, но асимметрия по многим причинам удобнее. Все операции с ним проводятся только внутри токена и этот ключ токен не покидает (и не может быть извлечен) ни при каких обстоятельствах, т.к. его компрометация приводит к возможности расшифровки всех ранее зашифрованных данных.
Но шифровать данные непосредственно долговременным ключом по многим причинам не стоит. Данные шифруются симметричным алгоритмом случайно сгенерированным сессионным ключом, уникальным для каждого шифруемого файла/блока/whatever (который затем шифруется долговременным ключом и добавляется к шифрованным данным).
Компрометация сессионного ключа ведет только к возможности расшифровки данных им же зашифрованных. А к этим данным в незашифрованном виде [недоверенный] компьютер и так имеет доступ и потенциальная компрометация сессионного ключа не влияет ни на что и работу с этим сессионным ключом можно смело вести на компьютере.
Посему задача токена - шифровать* сессионные ключи. Гонять же через него сами данные - пустая трата ресурсов.
(*) а в случае асимметричного долговременного ключа по большому счету - только расшифровывать, для (за)шифрования он необязателен.
Вам не кажется странным, что ничего не поняли вы, а читать вы отправляете меня ? )
Стандартная схема шифрования больших объемов данных асимметричной криптографией - сгенерировать случайный ключ для симметричного алгоритма, зашифровать большой объем данных им, а сам этот ключ зашифровать асимметричным алгоритмом и положить рядом с зашифрованными данными.
И в аппаратные токены убирают именно закрытый ключ от асимметрии и все операции с ним. Ну и rng тоже можно в него же засунуть.
А в чем смысл шифровать данные на аппаратном ключе ?
Чем плох традиционный способ с хранением а АК ключевой пары асимметричного шифра и генерация ключей для симметричного алгоритма на АК.
А уже шифрование данных симметричным алгоритмом - на хост-системе. Это и упрощает как реализацию АК (чем проще, тем сложнее накосячить) и снимает вопросы со скоростью. Ну и готовых решений на рынке масса.
Опасения компрометации симметричного ключа? Так данные, шифруемые этим ключом, и так доступны на хост системе открытым текстом.
Del
Ну так а автор-то директологом
Вы говорите как о чем-то плохом
И как отличать во время всплеска ботовские 1920*1080@Win10 от примерно половины десктопных пользователей, использующих десятую винду и fullhd монитор ?
Офигенный признак фрода.
Ну это какие-то дети бота писали, что по User-Agent бот вычисляется.
А зачем тогда хитрые телодвижения с соксом ? (я при беглом прочтении так и не понял, как именно вы его используете).
Шлите первым пакетом со стороны клиента какой-нибудь мусор, сервер этот пакет проигнорирует, но на брандмауэре сессия создастся и она будет начинаться с этого мусора, а не с wireguard handshake
Естественно