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

[Dan Gudmundsson]

Isn't the zlib problem fixed?
When I read the thread I got the impression that we had fixed the 
problem when we changed the zlib version ( ok so we didn't only switch 
version the release was a little short).

We have made a couple of fixes in that zlib area since R11B-2,
send me a counter example if it still doesn't work in R12B-1 and I will
try to fix it.

/Dan

Lev Walkin wrote:
> 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.
>