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

Разбей задачу на два шага. Первый шаг — генератор потока байт, которые выглядят случайными. Второй шаг — побайтный xor данных с потоком из первого шага. Дешифровка будет аналогичной.

Без понимания как в игрушке хранятся данные и как разделяются игроки подсказать невозможно. Но вот так тыкая пальцем в небо, например вот такие параметры сейчас я использую c хорошим балансом безопасность/скорость:

export const DEFAULT_KDF = Object.freeze({
  name: 'argon2id',
  version: 19,
  memoryCost: 128 * 1024,
  timeCost: 4,
  parallelization: 1,
  outputLength: KEY_LENGTH
})

export const DEFAULT_SCRYPT_KDF = Object.freeze({
  name: 'scrypt',
  cost: 131072,
  blockSize: 8,
  parallelization: 1,
  maxmem: 256 * 1024 * 1024
})

export function encryptJson (key, serverId, value) {
  const nonce = randomBytes(NONCE_LENGTH)
  const cipher = createCipheriv('aes-256-gcm', key, nonce)
  cipher.setAAD(aad(serverId))

  const plaintext = Buffer.from(JSON.stringify(value), 'utf8')
  const ciphertext = Buffer.concat([cipher.update(plaintext), cipher.final()])

  return {
    algorithm: 'aes-256-gcm',
    nonce: nonce.toString('base64url'),
    ciphertext: ciphertext.toString('base64url'),
    tag: cipher.getAuthTag().toString('base64url')
  }
}

createCipheriv(‘aes-256-gcm’

Как я понял это тот же алгоритм от которого я ушёл, а base64url всего лишь устраняет бинарные данные.

Самый простой способ - просто увеличить длину ключа. Если она заведомо больше сообщения, то повторяемости не будет. Можно попробовать со сдвигами поиграть, если сообщения же больше ключа, но тут такое… Хотя можно, если есть желание байты по экономить. (Например, сдвинуть ключ на один символ)

исполняемый файл увеличился в 2 раза.

Под микроконтроллер пишешь? Преждевременная оптимизация?

Первый шаг — генератор потока байт

Попробовал рандом(1-127) с «Random Seed» и Xor. Ну теперь повторений понятно что нет. Осталось все эти варианты проверить по скорости.

В следующей версии языка поменяют (дефолтный) алгоритм рандома - прощай старые рекорды.

Под микроконтроллер пишешь?

У меня мания точного алгоритма и минимального размера, в то время как многие пишут проги по 400Мб не задумываясь вообще ни о чём. Если быть точным, игра была 181 кб, в вдруг стала 490 кб. Ради чего я там всё оптимизировал, чтобы какой то модуль мои усилия в ноль спустил.

В следующей версии языка поменяют (дефолтный) алгоритм рандома - прощай старые рекорды.

Только при условии обновления игры.

У меня мания точного алгоритма

Успехов в погружение в криптографию, а не вот это вот все со встроенными рандомами неизвестного происхождения.

Скорость и надежность алгоритма не имеет никакой корреляции с размером. Поэтому во-первых нужно выбрать алгоритм и параметры/примитивы соответствующие современным нормам и хорошим практикам по безопасности. Во-вторых нужен обязательно бенчмарк, которые покажет тебе реальную производительность в твоем приложение, потому-что скорее всего проблема не в шифровании как таковом, а в том как ты хранишь и работаешь с данными. Например стоит понимать что сохраняется/записывается в память/кэш, а что на диск хотя бы.

Успехов в погружение в криптографию

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

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

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

Альтернативно можно поискать старые алгоритмы, они попроще должны быть. Какие-нибудь коллизии вас волновать не должны, я полагаю.

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

Зачем шифровать рекорды? Рекордами надо гордиться и всячески их выставлять напоказ. Пиши рекорды открытым текстом, но добавляй «подпись» - проверочную контрольную сумму.

Зачем шифровать рекорды? Рекордами надо гордиться и всячески их выставлять напоказ.

Нажимаешь кнопку «рекорды» и смотришь, но не можешь их редактировать.

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

Добавил в игрушку шифрование рекордов на движке AES

абсолютно бесполезное занятие..

мимо проходящий школьник, даже без знания бейсика, запустит «трейнер» (их в игро областях тьма) и пофиксит файл рекордов ДО ШИФРОВАНИЯ И ЗАПИСИ.

то есть проблема не в AES vs самопальный алгоритм. В конце концов файл рекордов можно держать плайн-текстом и просто подписывать.

Самый простой вариант для шифрования:

1. Пишешь любой детерминированный генератор псевдо-случайных чисел. Надо, чтобы он брал на вход какое-то число (зерно) и выдавал байты один за другим. Если в проекте есть криптографические хеши, можешь просто внутри генератора держать последний хеш, а при вызове хешировать сам себя и возвращать последний байт получившегося хеша, получится неплохо на самом деле. Тот же SHA-256 реализуется в несколько десятков строк. Но в принципе можешь просто взять RC4, там вообще всё максимально просто.

2. Далее на свои шифруемые данные применяешь xor с выводом этого генератора, вот и всё. Зерно как-то должно задаваться, это что-то вроде ключа шифрования.

Сразу скажу, что никакой реальной безопасности такое шифрование не добавит, это больше от любопытных глаз защита. Для реальной безопасности нужно применять серьёзные алгоритмы. Причём применять с умом, можно и с ними обделаться жидко.

И ещё добавлю. Если в старые времена сломать даже максимально кривой алгоритм шифрования требовало нехилых знаний, то в 2026 году с помощью LLM с этим справится любой увлечённый школьник. Это так, чтобы было понимание модели угроз.

У него будет захардкоденный ключ. Поэтому смысла в сложных алгоритмах нет. Модель угрозы - человек открыл файл в блокноте и исправил его.

всё ещё позволяет при большом желании редактировать файл.

А от кого ты шифруешься? Чтоб игрок не мог себе рекордов накрутить? А кокой смысл ему этим заниматься?

Да я уже не раз погружался

Щас тебя закидают до полного погружения: и про самопальные алгоритмы, и про криптостойкость, и про шифрование не защищает от изменения, и про симметрию и асимметрию, и при их алгоритмическию сложность, про сертификаты, про идентификацию, аутентификацию, авторизацию, …

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

Добавил в игрушку шифрование рекордов на движке AES, исполняемый файл увеличился в 2 раза.

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

300кб на реализацию AES это явный перебор. Самая тяжёлая часть алгоритма - это таблицы быстрого перемешивания байтов, они занимают целых 8кб (но если надо сэкономить память, то вместо таблиц можно использовать алгоритм, считающий перемешивание вручную каждый раз - он будет занимать наверно 200 байт). Остальной код (без таблиц) меньше 4кб выходит.

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

300кб на реализацию AES это явный перебор.

Там добавлены функции работы с ini-файлом. Если винда имеет шифратор как API, то естественно у меня исполняемый 214кб, но я подозреваю, что в Linux модуль встраивается в исполняемый. Гугл пишет 5-50кб для С++, добавил упоминание «линукс», пишет от 2–5 КБ до 5+ МБ (при статической линковки).

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

Для логичного поведения, я во многих игра видел, что рекорды шифруются, точнее ни разу не видел рекорды открытыми для правки в редакторе.

Добавил в игрушку шифрование рекордов

А зачем?

Там добавлены функции работы с ini-файлом.

Так а при чём тут шифровальщик?

рекорды шифруются, точнее ни разу не видел рекорды открытыми для правки в редакторе

Редактор это текстовый редактор? Большинство игр хранят свои данные не в текстовом виде, и редактировать их надо hex-редактором. И у большинства там ничего не зашифровано. Если хочешь чтобы конкретное число в файле не получилось найти двоичным поиском по нему (artmoney и подобное так делают) - можно его например умножить на коэфициент, например если у тебя 32-битные целые числа, то можно умножать их на 3571784627 для «зашифровывания» и на 2446920571 для «расшифровывания».

Если в 32-битной арифметике посчитать x*3571784627*2446920571 то ответ будет тоже x.

Так а при чём тут шифровальщик?

Проверил 32 кб шифровальщик добавил, похоже игра не стоит свечь. Ну хоть поигрался с логикой.

Добавил в игрушку шифрование рекордов

А зачем?

Ну как же, его игра мегапопулярна и даже есть сайт с рейтингами.

С GCM, который выше рекомендуют, повторяемости и так не будет. Она только в ECB.

Да это буквально первое, что пришло мне в голову, из разряда «на коленке». Длинный ключ будет явно короче хитрого алгоритма. Ограничь таблицу 10-100 записями, выдели ключ достаточной длины и вуаля. Кодится 1,5 минуты.

Это уже потом я подумал, что можно взять готовый алгоритм попроще: sha или ещё чего проще есть - смотреть надо. Последнего вполне должно хватить для защиты от школьников.

взять готовый алгоритм попроще: sha или

Это же хеш, он не шифрует.

Но в принципе можешь просто взять RC4

Спросил у гугла, ломается ли строка если в центре зашифрованной строки испортить пару символов, ответ: при расшифровке сломаются только изменённые символы по позиции, те же пару символов. Грубо говоря, если открыть файл рекордов и сделать тестовую замену по позиции, например в строке «AZJIO|35|08082026» заменить 7-й и 8-й символ на что-то иное, например там символ с кодом 0567, пробуем увеличить на 2 и получаем 0569, смотрим что получилось при чтении рекордов, например строка стала «AZJIO|55|08082026», вуаля, файл рекордов взламывается вообще без необходимости расшифровки.

Ну да, перепутал. Я в названия не погружался, ответил так. Но суть в том, что есть более ранние алгоритмы, которые должны быть проще. У них есть некоторые проблемы по безопасности, но в твоём случае они не критичны.

Открыл тут страницу с болваном. Видимо я имел в виду RSA. Из того, что ушло в прошлое: RC4, DES и 3DES, CBC для AES.

Должны быть и готовые реализации, и их описание.

Из того, что ушло в прошлое: RC4, DES и 3DES, CBC для AES

Ну там худший ECB, а CBC вытесняется режимом GCM из-за отсутствия задействования всех ядер и уязвим без внешней проверки целостности. То есть по факту не совсем уж пропащий. У AES-GCM нет режима сцепления блоков и он как я понял просто проверяет целостность по хеш-сумме и не расшифровывает, если нарушен хеш. Если автор AES-GCM отключит проверку хеша, то без сцепляемости блоков его будет легче взломать.

Там - это везде?

CBC вытесняется режимом GCM из-за отсутствия задействования всех ядер и уязвим без внешней проверки целостности.

Какое это отношение имеет к требованию компактности алгоритма? Мы говорим о маленькой табличке с рекордами.

Вы не сможете сделать алгоритм шифрования с современными требования к криптостойкости. Максимум - переписать существующий, выкинув лишнее, если оно там есть. А потому надо снижать требования.

Добавьте подпись и успокойтесь.

Мы говорим о маленькой табличке с рекордами.

Ну в этом случае, как раз больше причин, чтобы использовать CBC, так как не собираемся использовать 12 ядер и не собираемся дописывать хеш.

Добавьте подпись и успокойтесь.

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

Хранить рядом запороленный хеш файла? Ну так работы то добавиться.

1. контрольная сумма. Она же подпись.
2. Всё с чистого листа. Какие-то требования у Вас совсем противоречивые. Сломал? Сочувствуем. Начинай с начала.

Через xor шифруй по 512 байт.

Сломал? Сочувствуем.

Какой ты добрый с клиентами. И это при том что для подписи нужны уже два движка, хеша и шифрования. А я изначально говорил про увеличении размера. При чём мой алгоритм сейчас пару килобайт, не 32 и вполне имеет право на жизнь.

И это при том что для подписи нужны уже два движка,

Ну вот зачем?! Зачем нужна криптостойкая подпись?! Говорили же что раз, контрольная сумма. В случае несовпадения сообщение «таблица рекордов испорчена и будет обнулена»

мой алгоритм сейчас пару килобайт, не 32

Многовато для тупого xor. Генерировать ПСЧ вместо использования жёсткого ключа несложно, это много не съест. Наоборот, сэкономит место которое занимал длинный ключ. Посчитать сумму это вообще несколько десятков байт. Если хочешь чтобы правки обнаруживались, но не портили результат безвозвратно, то нужна избыточность данных (например тупо сохраняй таблицу два раза подряд). Как вариант сохраняй сумму поблочно (отдельная сумма для каждой записи).

Для логичного поведения, я во многих игра видел, что рекорды шифруются, точнее ни разу не видел рекорды открытыми для правки в редакторе.

Другими словами – «все побежали, и я побежал» (c) Василий Алибабаевич

А логически я тоже не понимаю, зачем кому-то править свой файл рекордов. Себя-то не обманешь…

Я бы лучше усилия не на шифрование, а на играбельность направил. Дело хозяйское, конечно…

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

например тупо сохраняй таблицу два раза подряд

Не, ну сломать можно обе таблицы. Надо три! Правда, и третью можно сломать… Ты понял, короче.

отдельная сумма для каждой записи

Тоже вариант.

А логически я тоже не понимаю, зачем кому-то править свой файл рекордов. Себя-то не обманешь…

Почему себя? Скинул я к пример список рекордов другому челу и они откроются игрой и может увидеть. А разве нет челов накручивающих себе рейтинг?

И когда я слышу, что надо зашифровать текст, но так, чтобы ничего не сломалось, когда кто-то будет шифр ломать, у меня мозг чуть-чуть клинит.

Чел ломающий шифр никогда не удалить исходник. Чел переписывающий текст в рекордах не будет думать об исходном, исправит, сохранит, закроет. Всё, сломал. И что тут может клинить? Шифр RC4 редактируется и ничего не сломается. Вот прям уже скучно разговаривать, пережёвывая одну и ту же инфу.

Многовато для тупого xor.

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