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

Разбей задачу на два шага. Первый шаг — генератор потока байт, которые выглядят случайными. Второй шаг — побайтный 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 кб шифровальщик добавил, похоже игра не стоит свечь. Ну хоть поигрался с логикой.

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

А зачем?

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