[EMAIL PROTECTED] wrote:
>
> Rather than go out and run my own timings for several of the Dm functions, I'm
> sure someone has already done this. I know times can vary by machine, but
> I'm curious about the order of magnitude of the Dm access.
>
> I'm wondering how expensive it is to actually perform DmOpens, DmWrites, etc.
>
> My problem:
> Some customers have asked that their data be encrypted on the device until our
> app reads the data and decrypts it. Several ideas have been percolating, each
> solution has it's own problems.
>
> The database could be very large, and could contain large records.
>
> 1) decrypt all records in the DB at the users request before accessing begins
> 1 DmOpenDatabase/lots of Dmwrites/1 DmCloseDatabase
> All accesses are just DmQueryRecords at this point
> User can encrypt the DB before closing the app
>
> Access is fast once the user has decrypted the DB. The User would expect a
> slowdown
> at this point. The bad point is that you're decrypting all records, most
> of which the user won't use.
>
> 2) decrypt each record on the fly and when we're through with the record
> encrypt it again
> lots of (1 DmOpenDatabase/1 Dmwrite/1 DmClose
>
> this one sounds really expensive. you'd get two of these for each record
> access.
> once to decrypt it....you use the record for a while..then once again to
> encrypt it.
>
> You could save some time by just, decrypting the records you use...then at
> app close time
> look through the database for non-encrypted records & re-encrypt them at
> close time.
>
> 3) read encrypted record to a temporary space, decrypt it, and use the temp
> variable
> doesn't need to do any DmOpenDatabase, DmWrite, DmCloseDatabase
> but now you're using lots of temp space...i don't think this idea is
> viable.
>
> Anyone have any thoughts??
>
> Thanks
>
> Mike
Mike,
This sort of problem is why I wrote OnlyMe
<http://www.tranzoa.com/onlyme/onlyme.htm>.
I concluded for my own purposes that encryption did not and would not do
the job.
Too slow for strong encyption to be applied to large databases.
Can't "Find" the data.
Too easy for something to go wrong while crypting and totally bungo the
Pilot's databases.
Etc.
So I simply locked the bad guy out of the device. Locking the bad guy
out of the device does not handle bad guys who build hardware to read
the physical memory, but, then, that sort of person can stick a gun in
the owner's face, too. So there is a limit to what we can do.
Also, locking the device does not stop the bad guy from getting at your
HotSync PC's data. But that's another problem...
If you are doing the encryption of your own application's data, though,
you probably don't care about DmWrite's speed. Strong encryption will
take long enough that DmWrite's effects will be comparatively small.
Weak encryption (e.g. XOR) is probably worse than nothing. A bad guy can
simply back the database up to his own PC and look at it. For strong
encryption, do a reasonable-sized block at a time, of course. Since you
are in your own app, you can ensure that there is enough dynamic memory
to buffer a big enough block. Take note of Alan Weiner's response to
your mail-list message. You must decrypt/encrypt the data a "record" at
a time. Don't go in to your app and decrypt the whole thing - then
encrypt upon exit. If you do, then a paper clip and thumb is all the bad
guy needs to read your data. In any case, certainly exit your app before
the "power" goes off! Also, decrypted records *must* be marked since,
despite what we all like to think, Palm Pilots have been known to crash
- even while running programs that we *know* have no bugs. :)
Good luck.
Alex Robinson
[EMAIL PROTECTED]
-eom-
