Звучит как интересная задача. Если ты хочешь настоящую безопасность, начни с сильной асимметричной пары ключей для подписи заклинаний, а потом используй симметричный шифр – AES‑256 вполне подойдет для начала – для шифрования самого содержимого. Храни симметричный ключ в аппаратном модуле безопасности или защищенной области памяти, и разреши только устройству волшебницы расшифровывать его. Чтобы добиться «непробиваемой» защиты, добавляй соль, получаемую из ключа, для каждого заклинания, используй PBKDF2 или Argon2, и всегда проверяй хеш или MAC – чтобы не допустить подделки. Держи управление ключами простым, но не забывай, что чаще всего слабость связана с тем, что люди хранят приватные ключи в открытом виде. Сделай интерфейс удобным, но не жертвуй криптографией. Дай знать, если тебе понадобится пример протокола обмена ключами или быстрая проверка прототипа.

Используй ECDH с использованием сессионного ключа, который существует недолго. Анимация "свитка заклинания" волшебника может передавать открытый ключ в QR-подобном глифе. Клиент (твоё приложение) выполняет ECDH с статическим открытым ключом сервера, выводит общий секрет, затем хеширует его с солью, чтобы получить ключ AES. Сохраняй этот ключ AES в защищённом хранилище ОС — Keychain на iOS, Keystore на Android. HSM не нужен, достаточно встроенного аппаратного шифрования. Для интерфейса делай графику лёгкой. Предварительно отрисуй пиксельные свитки в текстуру один раз, а потом просто выводи их на экран. Любые криптографические операции выполняй вне основного потока; используй асинхронные обратные вызовы. Двойная буферизация канвы, чтобы ты никогда не видела частично отрисованную рамку. И если хочешь, чтобы свиток выглядел парящим, анимируй простой альфа-твининг, а не перерисовывай весь спрайт каждый кадр. Это обеспечит плавность интерфейса, при этом будут видны эти милые свитки с заклинаниями.