Storing OpenPGP Keys and Encrypted Data in a Database

Question

I've been playing around with OpenPGPjs (the Javascript port of OpenPGP) in my spare time to learn something new. To test it out, I am working on a simple web app to store and retrieve the key-pair and encrypted data from a database.

Since OpenPGPjs has an option to produce "armored" keys (binary keys outputted as text), I'd like to save it as such in the database. But while generating the key-pairs, I noticed that they are not of fixed-length (as I had wrongly assumed). The variable length of the keys has me confused on what limits to choose for the size of the field in the database.

Can somebody clarify the following doubts on OpenPGP:

-> What is the maximum size that an OpenPGP 'armored' key can have?
-> Can the size of the encrypted data calculated based on the size of the data encrypted?
-> What is the general, recommend practice (if any) to store such keys in the database.

P.S: I have read and understand the pitfalls of using Javascript for encryption, so you can skip that warning. :)

Note: Based on the comments, I have edited the question to hopefully remove any ambiguity on what I want to know.

Answer 1

Prediction of length of both the (public/private, doesn't matter) key and encrypted data are not possible. If you want to store them in the database, do so as a BLOB or TEXT (not VARCHAR, you do not need any indexes and would end in rather sparse data layout). You might want to give up some normalization and store the key ID (or fingerprint) separately as a VARCHAR if you will have to query it.

ASCII armored data is easier to handle, while binary data is much more compact.

---

For encrypted data, it is easy to see that encrypted length heavily depends on the input, but also which encryption and compression algorithms are chosen -- OpenPGP allows a lot of them. As compression should not (considerably) increase storage, and symmetric encryption should at least be linear in size if not equal, and meta data is more or less of fixed size, you can easily determine some upper limit for your special set of algorithms. For storing in database this will probably be irrelevant as length is too large for reasonable inline storage anyway.

For key packages, it depends what you want to store: In addition to the public primary key, usually several public subkeys will be stored (which are actually used for encryption). A public key also contains user IDs, maybe an image, possibly some configuration, revocation certificates and incoming signatures. Public keys can generally grow rather large, do not trust in a maximum size. Same for private keys, which usually have the public key bundled. Size can theoretically be arbitrary large (at least I'm not aware of any limits in the specifying RFC).

Answer 2

The key length is what you choose - probably 4096 bits if you go with the current recommendations. Base64 encode it and save it as a varchar.

The length of the encrypted data is completely variable. IIWM I would base64 encode this and write it to disk. Save the resultant filename in your table instead of the actual data.