Re: [E-devel] [RFC] EET crypto and signature support.
On Tue, Jun 24, 2008 at 7:27 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Tue, 24 Jun 2008 00:48:04 -0400 Simon Horman [EMAIL PROTECTED] babbled: 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(); as eet files can store multiple (independent) data segments - addressed by key strings (like a tar.gz with multilple files in it) it makes the most sense for the key to be provided along with reading/writing a specific data segment - no? 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. makes sense if we consider the whole file encrypted, but as such why limit it to a set of keys you have to set up in advance (other than performance)? :) The idea of setting up the key in advance give us the possibility to set them outside of the direct user of the eet file. We can cypher an edje collection and without any modification to edje library use it. Same goes with any user of eet, no need to change it. Only the apps that want to use this feature will need a change (and of course they will need it as they need a way to provide the key). -- 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
Re: [E-devel] [RFC] EET crypto and signature support.
On Tue, Jun 24, 2008 at 03:27:30PM +1000, Carsten Haitzler wrote: On Tue, 24 Jun 2008 00:48:04 -0400 Simon Horman [EMAIL PROTECTED] babbled: 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(); as eet files can store multiple (independent) data segments - addressed by key strings (like a tar.gz with multilple files in it) it makes the most sense for the key to be provided along with reading/writing a specific data segment - no? If you just want to encrypt/unencrypt things at the granularity of what is accessed using read/write, then yes, what you suggested makes good sense. The API that I was getting at would work well in situations where an encrypted chunk of data would be built up using muiltiple writes(), presumably because its either very large or isn't all available in one hit for some reason. That doesn't seem to be the case here. 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. makes sense if we consider the whole file encrypted, but as such why limit it to a set of keys you have to set up in advance (other than performance)? :) Cedric made a subsequent post on this. With regards do zeroing RAM, that is a good idea. But its really all a bit moot if the memory is swappable. sure - though as such it would massively reduce the likelihood of inadvertent passkey trails in core dumps etc. swap we can't do anything about - but if you copy the key, use it and derivative data really fast them nuke everything chances of it being found later by mistake are lower. it's definitely not a solution, but a risk mitigation at any rate. if you have access to the memory space of a process to be able to do this it's normally game over anyway, but there is not much we can do there beyond mlock()... and then we're in root-only land. Agreed. Though it may be worth using mlock() if the euid happens to be 0. -- Horms - 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
Re: [E-devel] [RFC] EET crypto and signature support.
On Thu, Jun 26, 2008 at 02:22:00PM +0200, Cedric BAIL wrote: On Tue, Jun 24, 2008 at 7:27 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Tue, 24 Jun 2008 00:48:04 -0400 Simon Horman [EMAIL PROTECTED] babbled: 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(); as eet files can store multiple (independent) data segments - addressed by key strings (like a tar.gz with multilple files in it) it makes the most sense for the key to be provided along with reading/writing a specific data segment - no? 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. makes sense if we consider the whole file encrypted, but as such why limit it to a set of keys you have to set up in advance (other than performance)? :) The idea of setting up the key in advance give us the possibility to set them outside of the direct user of the eet file. We can cypher an edje collection and without any modification to edje library use it. Same goes with any user of eet, no need to change it. Only the apps that want to use this feature will need a change (and of course they will need it as they need a way to provide the key). Another issue may be if keys need to be unlocked using a passphrase or other wise initialised in an interactive or expensive way. If that were the case it would make sense to initialise each key once per session rather than each time a read() or write() was performed. Cedric, with regards to your initial question of using an existing scheme or creating a new one. I would suggest the former as getting such scheme right can be tricky, so its usually better to use established methods. -- Horms - 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
Re: [E-devel] [RFC] EET crypto and signature support.
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=featuresnewsitems=5whatfile=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
Re: [E-devel] [RFC] EET crypto and signature support.
On Tue, Jun 24, 2008 at 02:32:22AM +1000, Carsten Haitzler wrote: 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=featuresnewsitems=5whatfile=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
Re: [E-devel] [RFC] EET crypto and signature support.
On Tue, 24 Jun 2008 00:48:04 -0400 Simon Horman [EMAIL PROTECTED] babbled: 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(); as eet files can store multiple (independent) data segments - addressed by key strings (like a tar.gz with multilple files in it) it makes the most sense for the key to be provided along with reading/writing a specific data segment - no? 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. makes sense if we consider the whole file encrypted, but as such why limit it to a set of keys you have to set up in advance (other than performance)? :) With regards do zeroing RAM, that is a good idea. But its really all a bit moot if the memory is swappable. sure - though as such it would massively reduce the likelihood of inadvertent passkey trails in core dumps etc. swap we can't do anything about - but if you copy the key, use it and derivative data really fast them nuke everything chances of it being found later by mistake are lower. it's definitely not a solution, but a risk mitigation at any rate. if you have access to the memory space of a process to be able to do this it's normally game over anyway, but there is not much we can do there beyond mlock()... and then we're in root-only land. 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 -- Horms - 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
Re: [E-devel] [RFC] EET crypto and signature support.
Am Montag 16 Juni 2008 15:33:23 schrieb Cedric BAIL: 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. That's an amazing idea. I have a couple of professional fonts which I'd love to include in my .eet's, alas I don't have permission to redistribute them. I guess this work would allow me to do that -- would it? -- :M: - 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
Re: [E-devel] [RFC] EET crypto and signature support.
On Wed, 18 Jun 2008 01:21:28 +0200 Michael 'Mickey' Lauer [EMAIL PROTECTED] babbled: Am Montag 16 Juni 2008 15:33:23 schrieb Cedric BAIL: 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. That's an amazing idea. I have a couple of professional fonts which I'd love to include in my .eet's, alas I don't have permission to redistribute them. I guess this work would allow me to do that -- would it? hmmm no. just because you encrypted them, doesn't mean you are allowed to redistribute them. irrespective of how they are transformed - you re-distributed them... and they are useless to distribute without a way of de-crypting them into a useful format. :) -- - 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
Re: [E-devel] [RFC] EET crypto and signature support.
On Monday, 16 June 2008, at 15:33:23 (+0200), Cedric BAIL wrote: On this topic, I believe we have two choice, libtomcrypt (http://libtom.org/?page=featuresnewsitems=5whatfile=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). So guys, what's your opinion on this subject ? You forgot beecrypt, which would also be a worthy option. But since openssl is part of the core OS of pretty much every distro, it would be the clear choice IMHO. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- What does not destroy me, makes me stronger. -- Nietzsche, The Twilight of the Idols (1888) - 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
Re: [E-devel] [RFC] EET crypto and signature support.
Michael Jennings wrote: On Monday, 16 June 2008, at 15:33:23 (+0200), Cedric BAIL wrote: On this topic, I believe we have two choice, libtomcrypt (http://libtom.org/?page=featuresnewsitems=5whatfile=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). So guys, what's your opinion on this subject ? You forgot beecrypt, which would also be a worthy option. But since openssl is part of the core OS of pretty much every distro, it would be the clear choice IMHO. Not to mention the fact that Ecore already has OpenSSL as a optional dependency. Would be strange to use multiple crypto libs. dan - 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
