On 8/29/06, snacktime <snacktime / gmail.com> wrote:
 > What would be a good envelope to put all that in?  I'm not sure what
> ruby openssl supports, and my experience with this is somewhat
> limited.  In the past I've always used PKCS7.  Performance is also an
> issue, plus I have two types of data to store.  One is short term with
> a life of maybe a week at most, the other would be stored much longer
> for auditing purposes.  Plus the keys have to change every 90 days.
>
>

To decide on the storage container you have to ask how transportable
and how interoperable your encrypts need to be. If they're only going
to be consumed by your own applications or stored in your own
archives, then you can roll your own formats. If not, then you face a
documentation and support challenge whether you use a "standard" like
PKCS7 or not.

As far as performance is concerned, I think you've already taken the
most important step by using asymmetric crypto only for key material
and digests. I also strongly recommend you not use asymmetric keys
longer than 1024 bits, especially given that you will be re-keying
everything every 90 days. 2048-bit keys sound really attractive until
you see them running 10 to 100 times slower in software, or several
times more expensive in crypto-hardware!

Another critical performance factor, perhaps the dominant one if you
have to protect a lot of documents, is the quality of your
symmetric-key material. It's very time consuming on most ordinary
servers to generate high-quality randomness (although there are ways
to speed it up), and you really don't want to use pseudo-randomness.

A final consideration is the usage profile. I've generally found that
what you're proposing to do is most worth doing with documents of
medium-sensitivity that have medium-sized user communities. (A
canonical example I've often used is engineering documents for large
manufacturers, that have to be seen by perhaps 10,000 people.) With
smaller communities, the job is far easier. With highly-sensitive
data, it shouldn't be stored in computers in the first place ;-).