[erlang-questions] long term stability of zlib/crypto

[Lev Walkin]

Joe Armstrong wrote:
> Hello,
> 
> I'm thinking on making an S3 thingy to complement my home backup system.
> 
> I was thinking of a) compressing the data (to reduce my S3 bills)
> b) encrypting the data (privacy) -
> 
> Now the problem - I need stable zip/unzip crypt/decrypt
> pairs. I don't want to backup the data only to find that
> it is unreadable by my great-great-great-great-.....-great grandaughter
> in a million years time (or even by me in five years time)
> 
> "pure erlang" would be OK (but inefficient) - but I'm probably in the market
> for a small and simple pure-c library with encryption and compression.
> 
> Any recommendations for such a C library (actually pure Erlang might
> not be so bad,
> The compress/encrypt cycle is very rare) - has anybody thought about
> how to ensure that crypto/comprerssion libraries are long-term stable.
> 
> The recent mails in this group saying that  the zlib compression
> failed the round trip
> 
> http://www.trapexit.org/forum/viewtopic.php?p=38378&sid=bc56571842ce1810e7923f09f0040d77
> 
> sent some alarm bells ringing ...

Joe, it seems that the roundtrip problem with zlib is a pure erlang
problem; the world around us uses zlib quite extensively, without any
hitches (except for IE6's https/gzip implementation). The bigger problem
is encryption. You'd probably like a strong encryption to withstand
a million year of crypto attacks to your collection of nudity. This
means, today, that you'd better stick with AES-256 as a block cipher,
with some asymmetric key schema on top of it. Perhaps, RSA-4096 would
be sufficient. Furthermore, if you need the file container to have
more or less standard file format so the future generations could read
it you would need something like PKCS#12 wrapper around the
key/cert pair, and so on and so forth.

In short, it is not going to be a small and simple C library. The only
way to do it small and simple would be to invent an ad hoc format
for this specific problem, and this most certainly is not going
to end up a secure one.

I'd advocate for the better OpenSSL binding. Much of necessary
functionality is available through the OpenSSL API.

-- 
Lev Walkin
vlm@REDACTED