Собственный шифратор текста, как?

Вам бы не помешало понять, что бОльшая часть требований у вас в голове. Я же исхожу из того, что Вы написали буквами на форуме. То Вам нужен алгоритм, то он у Вас есть, то он нерабочий. То Вам криптостойкий алгоритм нужен, то короткий. С такими обрывочными требованиями Вам никто ничего путного не посоветует.

но из-за двойного xor я получаю 0000,

Очевидно, это идёт из-за перемножения байт обратное им. a*!a === 0. А там уже смотрите, где Вы оригинальный ключ перемножили на обратный.

То Вам нужен алгоритм, то он у Вас есть, то он нерабочий.

Он работает для символов с кодом в сумме не превышающий 65535, это я уже сколько раз говорил. Учитывая что в этом диапазоне эмодзи, то теоретически его можно использовать. Но я не любитель полумер, если xor не имеет этого недостатка, то мне нужно добиться его работы в любом диапазоне.

a*!a === 0. А там уже смотрите, где Вы оригинальный ключ перемножили на обратный.

Для меня это очевидно как давжды два, тем более, что я говорил о режиме сцепления блоков, если я использую «aaaaa», то xor для них даёт 0000, помогает, что я использую рандом, но я не исключаю ситуации, что с рандомом могу получить тот же 0000 (пока не получал на тестовых строка). Может 0000 должен быть рабочим кодом и мне надо обрабатывать не как строку, а как бинарные данные по указателю, так же я пробовал делать подстановку, например если 0000, то подменяем его на 65000, а при дешифрации 65000 подменяем на 0000, но пока я пробовал в лоб менять, не помогло, а если бы помогло пришлось бы переходить на бинарный режим по указателю.

То Вам криптостойкий алгоритм нужен

Не говорил такого… Замена букв в шифровке не должна расшифровывать файл я не считал это криптостойкостью.

Есть ещё вариант, допустим я шифрую примитивным шифратором с возможностью подменять цифры по позициям, при этом в конец файла я дописываю пару байт 0-255 число типа хеш суммы примитивным способом, складываю все двухбайтные числа и остаток записываю в эти последние байты (или в начало). Если при чтении файла контрольная сумма нарушена, то файл просто не читается и юзер думает что замена цифр просто не работает.

Второе решение в лоб, сделал рандом в диапазоне 32000-32200, всё, нули исчезли, два xor работают.

Я давно в шапке добавил ссылку на мой текущий вариант, там вы можете посмотреть на 5 исходников, последний из которых я только что добавил, который использует xor два раза и рандом 65250-65535 на границе, который не даст двум соседним буквам получить 0000, так как первый xor с числами выше 65250 ни как не сможет быть одинаковый с кодом числа для языков в районе около 1000 для русского языка. Там арабские символы, но я проверил их, они нормально зашифровались и расшифровались, так что наверно теперь уже всё.

«Это элементарно, Ватсон.» ©

Я давно в шапке добавил ссылку на мой текущий вариант

За такие ссылки банить надо, нифига не открывается.

буквы вместо байтов, что могло пойти не так :)

За такие ссылки банить надо, нифига не открывается.

РКН забань, у меня всё открывается. Если ты не в состоянии включить ВПН, причём не навороченный, а один из плагов в магазине браузера и при этом хочешь меня банить, то себя забань за кривые руки. FastProxy у меня.
Я сейчас вообще тремя пользуюсь и некоторые сайты открываю разными комбинациями, точнее комбинациями, при которых мне меньше требуется переключений.

буквы вместо байтов, что могло пойти не так :)

Ну представь, что байты могут быть 0083 0023 и ты будешь шифровать 00 каждый второй раз. А выше тебя чел предлагал хорить по 512. Двоим я вряд ли могу угодить. Да и по сути какая разница по сколько хорить, число бит то в строке не увеличивается и не уменьшается от числа байтов за шаг.

Задача у тебя странная, определись с размером таблицы скора и используй шифр Вернама. В идеале генератор запускать после каждого обновления таблицы, результаты естественно непереносимы

Вообще, вся твоя затея только от совсем юных пионеров, ты вынуждено имеешь ключ (или набор ключей) в своей игре, тут вопрос только в азарте их выковыривания

используй шифр Вернама

Представь у тебя рекорд 50, при сохранении ты пишешь имя «5099», потом берёшь шифрованный файл и смотришь первые два символа, далее ищешь эти символы в позиции 6, так как очевидно после имени разделитель и там те же два символа, тупо заменяешь их на 99 взяв их из позиции 3 и 4 в зашифрованном и вуаля, твой шифр обогрели-обобрали. Некоторые шифры невзламываемые при отсутствии результатов, но если у тебя на руках текст и его зашифрованное представление, то взломать такой шифр дважды два и получить сразу ключ и написать скрипт для автоматического перешифрования.

Дарю дырявую идею.

Во время сохранения новых рекордов генеришь асимметричный ключ - приватный и публичный (шифрования и дешифрования). Публичный ключ сохраняешь. Приватным ключём шифруешь рекорды, и сразу приватный ключ удалаешь. Теперь рекорды можно только прочитать. Осталось придумать: как защитить от подмены публичный ключ.

Может все же теорию почитаешь?

далее ищешь эти символы в позиции 6

Попробуй посолить, говорят помогает.

да нафиг не надо это ему, можно вообще обойтись симметричным шифрованием. Кому оно сдалось таблицу накручивать.

Из совсем тупого, берем по два байта, инвертируем каждый, переставляем местами, добавляем третий байт мусора, проходимся по это шляпе любым симметричным алгоритмом, сидим радуемся

Может все же теорию почитаешь?

Могу ссылку на неё дать.

ну судя по твоим коментам не в коня корм. Предложенный тебе алгоритм предполагает, что ключ будет равен размеру твоей таблицы, теперь думай как ты читал теорию

вопрос гуглу: можно ли получить ключ шифра Вернама, если имеются текст и его шифровка.
ответ гугла: Да, если у вас есть и исходный открытый текст, и его шифровка, то ключ шифра Вернама можно получить мгновенно и абсолютно точно.

что ключ будет равен размеру твоей таблицы,

А ту думаешь рандомный генератор не генерирует на каждый символ новое число? Разница только в том что ты используешь таблицу, а я генерю её во время шифрования.

Тяжело до тебя доходит, если ключ удалось получить, то подобрать алгоритм будет уже просто, патчатся и новый ключ и новое сообщение и вот ты эльф 80 левела об этом спич. Тебе этот алгоритм сунул потому-что он тупой и быстрый и от пионеров поможет

Тяжело до тебя доходит

Тут всего-то 2 страницы почитать, чтобы понять. Тут сконцентрировано обмусолено уже всё. А как твой шифр Вернама работает похоже ты сам не понимаешь, он для тебя что магия.

Если хранить текстовый файл скорр, то да, затея тупая, обычно подобные данные закидывают в блоб и не всегда они имеют одинаковое смещение от сэйва к сэйву

Про соленья.

Пишешь свой тупой xor-алгоритм с псевдорандомом, в котором пароль - это первоначальный seed. Чтобы разные версии шифрованных рекордов сильно различались, в начале шифрованных данных пишешь соль - случайное число, каждый раз новый, не шифруешь. При шифровании/дешифровании xor’ишь свой пароль-seed с этой солью. Теперь каждая новая версия файла полностью отличается от предыдущей, а не только те байты, где измененились данные.

обычно подобные данные закидывают в блоб

Каким образом? Файл находится в папке с доступом от root, как он будет писать в себя от юзера?

Собственный шифратор текста

#include <stdio.h>
int main() {
    FILE *r = fopen("/dev/random", "r");
    int c;
    while ((c = getchar()) != EOF) 
        putchar(c ^ fgetc(r));
    int a = 0; 
    fread(&a, 2, 1, r); 
    while (a--) 
        putchar(fgetc(r));
}

Выше уже правильно сказали, даже с идеальным шифром ключ всё равно вшит в игру, расковырять относительно несложно, повторю, даже с идеальным шифром. Тогда вопрос: зачем так сильно потеть совершенствовать свой наколенный шифр?

И тоже правильно сказали, нужно ли вообще шифровать, если в игре эти рекорды открытым текстом показаны? Может лучше подписать? Но здесь опять же, ключ внутри игры, 100% защиты никогда не сделать.

Ссылка забанена РКН кстати. ТС, твоя задача элементарна, даже постквантовое шифрование из связки ML-KEM-512 + ChaCha20 + Poly1305 + blake2s внутри вместо sha-256 может вполне себе работать на мк с 80 кб RAM и меньше чем с 1 мегабайтом памяти на флеш-карте. Что там у тебя в 2 раза выросло, я ХЗ. Дегенераты видимо жирные бэкдоры писали. И да, если правда на МК пишешь, то выкидывай AES, он тяжёлый. ChaCha20 быстрее и легче, особенно если нет аппаратной поддержки у AES на твоём МК.

Собственный шифратор текста, как?

Найми студента-медика.

1. Один из пострадавших что-ли?
2. Бань навсегда, чтобы мне не пришлось выкладывать пароль.

челу…челов

И этот чел что-то имеет против интернет-сокрашение, ЕВПЧЯ. За чистоту языка борется, сея регвыры тут и там. А бревна у себя в глазу не замечает.

Я ничего не понял. От кого пострадавший? За что банить? Зачем писать от анонимуса, когда можно от себя?

челу…челов

челом

бьет! 😁

вопрос гуглу: можно ли получить ключ шифра Вернама, если имеются текст и его шифровка. ответ гугла: Да, если у вас есть и исходный открытый текст, и его шифровка, то ключ шифра Вернама можно получить мгновенно и абсолютно точно.

ЭПИЧНО! Даже гугл троллит тебя твоей же тупостью :-D Чтобы шифр назывался «невзламываемым шифром Вернама» его ключ должен соответствовать 2 обязательным требованиям (остальное - опционально). 1 - Он должен быть с размером ключа, длина которого должна совпадать с длиной сообщения. 2 - Ну ?! Что за второе обязательное требование? :)

А иначе это не «невзламываемым шифром Вернама» а просто XOR-илка (тупая). Думай :)

Анон то оказывается тоже глупенький и не знает, что шифр вернама это и есть тупая XOR-илка, которую просто правильно используют (ключ истинно, что бы это не значило, случайный, равен по длине шифруемому сообщению, не используется повторно и не хранится после использования у того кто шифровал, оставаясь только у того кто должен расшифровывать, после расшифровки уничтожается). Всё. Больше в шифре Вернама ничего нет.

Но это не отменяет того что ТС конечно не соображает как работает XOR. Достаточно посмотреть на его таблицу истинности, чтоб всё стало понятно если что. И аналогично можно заменить XOR на ряд других операций, например XNOR из простых и очевидных соображений (однозначная обратимость через себя и равномерное случайное распределение результатов).

Если игра будет исполняться на вашем сервере, а игроки подключаться к нему, рекорды можно не шифровать.

Твой пример довольно неплохо иллюстрирует когнитивные перекосы в ИБ. Когда у некоторых проходной двор и пофигизм там, где его не должно быть, а у иных - излишняя, безосновательная паранойа. Хотя, возможен и третий варик - руки чешутся что-то закодерить, а что именно - не важно. Есть известная русская поговорка на этот третий случай…

Если игра будет сейвить реплей в виде кнопок вместе с рекордом, то он сам себя подтвердит и не придётся шифровать ;] Даже видосы с прохождением снимать не придётся.