On Wed, 29 Jun 2005 17:17:12 -0000, Stadin, Benjamin
<[EMAIL PROTECTED]> wrote:
Do you know keyring for Palm? It's hosted on Sourceorge I think. That
gave me a start on using the AESLib and is maybe what you want to do.
I use the Copera AESLib already and also have implemented a SHA-256
function.
But I want to write the main part of the app in Basic (Appforge) and use
some homemade lib for the timecritical (and securitycritical) stuff.
It's almost never a grid computer or brute force attack, it's common to
use the code functions inside the application for your own needs. It
doesn't help to have a 1024 bit encryption key if the key is stored
somewhere encrypted in the application and you could simply misuse the
applications decrypt function to get the plaintext db password for an
example.
I'm looking from two sides:
device-security: depends mainly on user awareness; no malicious app must
be on the device used
offline-security: if an attacker should be able to get the database, it
should be expensive (in time counts) to decrypt.
The basic problem is usability. Most users probably prefer something like
"Peter123". Most apps simply hash this (some do some weirdo shifting too,
but that does not really help) and advertise with 128 or even 256 bit
secutrity, when the actual key entropy is basically somewere between 25
and 30 bit. So my idea is to provide a random key to the user, which has
to been used (no self chosen passwords) that consists of min. 7 chars out
of 82 (like: "e&nOL!a"). This key will be created true (almost true only)
random and so gives a base entropy of min 44 bit. That's still not enough
to be safe against brute-force attacks, so I will use hashing/permutating
to increase the overall keylength (described here:
http://www.schneier.com/paper-low-entropy.html ). Even on a very slow
Dragonball CPU I should be able to add at least another 8 bit of entropy
(more on ARM devices). Finally with a 7 char password, I should get at
least a key of 52 bit. With a 10 char password and on an ARM device I
should get > 72 bit which is already very safe against brute force attacks.
My goal is not to have any weak points in the database. The user has to
care of the contents on his/her device of course.
the wild. If I was a bad guy I would send you a serious looking
advertisement application that's interesting for your business and
install a changed application which overwrites a original version on
your PC or Palm which you trust in the background.
This application would then simply mimic the first form of the password
manager and when the user enters his password, it will say "Wrong
password, please retype" and on the second try the app will terminate with
some cryptic error. I guess, that's what I would try ;)
All depends on user awareness ...
their newest hacks. Could be a good point to take care of common tricks.
Code obfuscation and a password to encryption key hashing is a good
thing to start with. But the real bad guys have a lot of Wodka and
Martini and too much time ;-)
I don't like obfuscation. Security should be reached even if an attacker
knows everything except the key. And since the key only exists in the
users brain (or as hashed version on the device, which doesn't help the
attacker) there is no way to crack the system, except for changing the
original app and/or installing some apps that catch the entered key.
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
