[erlang-questions] long term stability of zlib/crypto
Wed Feb 20 15:39:10 CET 2008
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.
Lev Walkin wrote:
> Joe Armstrong wrote:
>> 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
>> 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.
More information about the erlang-questions