Хранение ключей OpenPGP и зашифрованных данных в базе данных

Question

Я играл с OpenPGPjs ( Javascript-порт OpenPGP) в свободное время узнавать что-то новое.Чтобы проверить это, я работаю над простым веб-приложением для хранения и извлечения пары ключей и зашифрованных данных из базы данных.

Поскольку OpenPGPjs имеет возможность создавать «бронированные» ключи (двоичные ключи, выводимые в виде текста), я бы хотел сохранить их как таковые в базе данных.Но при создании пар ключей я заметил, что они не имеют фиксированной длины (как я ошибочно предполагал).Переменная длина ключей сбивает меня с толку, какие ограничения выбрать для размера поля в базе данных.

Может ли кто-нибудь прояснить следующие сомнения по поводу OpenPGP:

-> Каков максимальный размер «бронированного» ключа OpenPGP?
-> Можно ли рассчитать размер зашифрованных данных на основе размера зашифрованных данных?
-> В общем, порекомендуйте практику (если есть) хранить такие ключи в базе данных.

P.S:Я прочитал и понял подводные камни использования Javascript для шифрования, поэтому вы можете пропустить это предупреждение.:)

Примечание:Основываясь на комментариях, я отредактировал вопрос, чтобы, надеюсь, устранить любую двусмысленность в том, что я хочу знать.

Answer 1

Прогнозирование длины ключа (открытого/частного, не имеет значения) и зашифрованных данных невозможно.Если вы хотите сохранить их в базе данных, сделайте это как BLOB или TEXT (нет VARCHAR, вам не нужны никакие индексы, и это приведет к довольно разреженному расположению данных).Возможно, вы захотите отказаться от некоторой нормализации и сохранить идентификатор ключа (или отпечаток пальца) отдельно как VARCHAR если вам придется запросить его.

Бронированные данные ASCII легче обрабатывать, а двоичные данные гораздо компактнее.

---

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

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

Answer 2

Длина ключа — это то, что вы выбираете — возможно, 4096 бит, если следовать текущим рекомендациям.Base64 закодирует его и сохранит как varchar.

Длина зашифрованных данных полностью варьируется.IIWM Я бы закодировал это в base64 и записал на диск.Сохраните полученное имя файла в таблице вместо фактических данных.