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
