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
