2

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.

Sam
  • 1,358
  • 4
  • 16
  • 30
  • Down vote could have been for crossposting. The site to go is either here or the database SE, but definitely not crypto/security: Your question is about database design, not encryption. – Jens Erat Nov 17 '13 at 19:13
  • @JensErat: It's not exactly database design - I knew what I want to do in the database and how to do it. But I needed clarification on the crypto parts - the keys and encrypted data. – Sam Nov 17 '13 at 20:17
  • The question is definitely not about crypto, but about storing something into a database. I agree that "Design" does not completely fit, I used the better tag schema. Shouldn't have used "design" in the comment. – Jens Erat Nov 17 '13 at 20:19
  • @JensErat: I agree my initial question wasn't very clear. But as I have since clarified, my confusion was more on what is the size and data type of the keys and the encrypted data. Apart from that, as it also deals with key management I do feel it is more crypto related (hence my initial query asked about general 'best practises'). – Sam Nov 17 '13 at 20:28
  • Can someone point me to the rules on cross-posting if any, because I was under the impression there was nothing wrong with that? I am not looking for any argument - if a rule has been formulated as such, then please go ahead and delete the duplicate post in IS, and if necessary move this to the 'right' place. Thanks. – Sam Nov 17 '13 at 20:36
  • This answer on meta gives a rather well advice when unsure where to post: http://meta.stackexchange.com/a/64069/171647. Anyway, this question as written is about storing something in a database, although some side questions are let open (what are you trying to do? what do you want to store -- public/private keys?). Crypto.SE is about the algorithms themselves -- you will most probably never get in touch with any of them when _using_ OpenPGP. Security.SE is about how to protect from thread and vulnerabilities, not about specific implementation problems. – Jens Erat Nov 17 '13 at 20:49
  • Thanks. I'll stick with SO and the mods can decide where to move the posts (if necessary). Though I have seen similar questions as this on both IS and C, I guess my poor phrasing is the root of this confusion. – Sam Nov 17 '13 at 21:02
  • I added some bits on size estimation in my answer. – Jens Erat Nov 17 '13 at 21:31

2 Answers2

2

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).

Jens Erat
  • 37,523
  • 16
  • 80
  • 96
1

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.

ethrbunny
  • 10,379
  • 9
  • 69
  • 131