Re: [E-devel] [RFC] EET crypto and signature support.

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

On Tue, Jun 24, 2008 at 02:32:22AM +1000, Carsten Haitzler wrote:
> On Mon, 16 Jun 2008 15:33:23 +0200 "Cedric BAIL" <ced...@fr...> babbled:
> 
> > Hi all,
> > 
> >   I want to add crypto and signature support inside EET. This could
> >   help us provide some secure way to store password for example or
> >   the possibility to add signature to theme.
> > 
> >   The first step before doing this, is the need to agree what kind
> >   of feature we want, what will be the dependency introduced by this
> >   and if they should be optionnal.
> > 
> >   For crypto, we could have two possibilities, or we cypher the
> >   entire EET file or just an Eet_File_Node. Cyphering an entire file
> >   is perhaps not what we want, I don't thing we need to cypher all
> >   image, data and
> 
> agreed. if you want whole-file encryption i am sure there are more
> transparent ways to get it (a vfs layer for examlpe).
> 
> > one day streams. I believe that just cyphering an Eet_File_Node is
> > enough. We have still 31 bits available in the flags field. We could
> > use 8bits of this field to define a key index that will be provide
> > at run time to the right Eet_File. For this we will need the
> > following API :
> > 
> >   EAPI Eet_Key *eet_crypt_key_new(const char *key); EAPI void
> >   eet_crypt_key_free(Eet_Key *key);
> > 
> >   EAPI int eet_crypt_key_define(Eet_File *ef, Eet_Key *key, unsigned
> >   char index); EAPI int eet_crypt_key_set(Eet_File *ef, const char
> >   *name, unsigned char index); EAPI int eet_crypt_key_get(Eet_File
> >   *ef, const char *name);
> > 
> > I think we could also provide :
> > 
> >   EAPI void *eet_crypt_data(Eet_Key *key, void *data, int length);
> >   EAPI void *eet_uncrypt_data(Eet_Key *key, void *data, int length);
> > 
> > and manipulate cyphered eet data.
> > 
> >   Now for signature support, I think we don't need to sign per
> >   Eet_File_Node, but only for the eet file. On this topic I don't
> >   know if we need to have our own way of signing our data (adding
> >   signature a bunch of signature at the end of the eet file or if we
> >   should use any known schem. Perhaps it depend on the crypto
> >   library we decide to use.
> 
> i can't much comment - i'm no expert on this :( it's a subject area i
> have never really paid much attention to.
> 
> >   On this topic, I believe we have two choice, libtomcrypt
> >   (http://libtom.org/?page=features&newsitems=5&whatfile=crypt) and
> >   openssl. My opinion on this subject is certainly biased as I
> >   already use libtomcrypt, but it's a small, simple and easy to port
> >   library. I believe we should make this dependency optional (if eet
> >   is compiled without crypto support all function call requiring it
> >   will just cleanly fail).
> 
> agree with it being optional. agree with them failing if not compiled
> in. i lean to openssl myself - or even gnutls. i know little of
> libmcrypt. as above.  i'm no expert.
> 
> what i will say. the whole key index thing looks odd to me. we are
> going to just deal with tiny bits of encrypted data here, so
> efficiency is not so important. why not simply provide a simplistic
> 
> EAPI void *eet_crypt_read(Eet_File *ef, const char *name, const char
> *key, int *size_ret); EAPI int eet_crypt_write(Eet_File *ef, const
> char *name, const char *key, const void *data, int size, int
> compress);
> 
> ? as such the data is encrypted given a specific passphrase/key and
> stored.  that key is needed for decryption (if not given - we can
> either return NUL or just garbage. up to us). 
>
> the important bits here
> are that without the key - the item cannot (sanely) be decrypted.
> (sure given 192332 years and enough compute power to run that
> long...). so from the key you generate a salt and then encode/decode
> with that. the important bit is making sure that key is not left
> around anywhere. any copies of it in ram are nulled out as soon as
> they are not used anymore etc. etc. - at least as far as eet is
> concerned. null out any useful intermediate data too.
> 
> i dont see why we need to go define limited fixed set of keys per
> file? just provide the key on read/write?

I'm not exactly sure what you are planing to push into and pull out of
this API, but it might be more sensible to provide the key on open. And
then use a scheme like CBC to encode a stream of data until it is done.
Then close. Or in other words; start(); add_data()...; finish();

Having a pool of registered keys might make sense if it is envisaged
that more than one might be used at a time - though not on the same
set of data.

With regards do zeroing RAM, that is a good idea. But its really all a
bit moot if the memory is swappable.

> >   So guys, what's your opinion on this subject ?  -- Cedric BAIL
> > 
> > -------------------------------------------------------------------------
> > Check out the new SourceForge.net Marketplace.  It's the best place
> > to buy or sell services for just about anything Open Source.
> > http://sourceforge.net/services/buy/index.php
> > _______________________________________________ enlightenment-devel
> > mailing list enl...@li...
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > 
> 
> 
> -- ------------- Codito, ergo sum - "I code, therefore I am"
> -------------- The Rasterman (Carsten Haitzler)
> ra...@ra...
> 
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.  It's the best place to
> buy or sell services for just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________ enlightenment-devel
> mailing list enl...@li...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

-- 
Horms