gnugu wrote: > Say you have a database with 100 notes. You use a password as a base > for encryption key. You decide to change your password.
How frequently do you anticipate people using your application (looking up data, modifying data)? Once a minute? Once an hour? Once a day? Once a week? Then, how frequently do you anticipate people changing their master password? Once a minute? Once an hour? Once a day? Once a week? Once a lifetime? > Now I have to spawn a thread that will open a > transaction and decrypt and re-encrypt records one by one. > Somehow I don't like that. Given a choice between optimizing for something that is done frequently, or something that is done infrequently, I'd err on the frequently side. It feels like your approach is to make the user's normal work painful (by having to decrypt the entire database just to use it and having to re-encrypt the entire database for any little modification), to optimize a case that, I suspect, is not all that common. But, hey, I don't know your app, so I might be incorrectly assuming your expected usage patterns and flow. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy _Beginning Android_ from Apress Now Available! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
