On Mon, 16 Jun 2008 15:33:23 +0200 "Cedric BAIL" <[EMAIL PROTECTED]> 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? > 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 > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
