Re: [OT] What kind of data is is returned by 'new' ?
Re: [OT] What kind of data is is returned by 'new' ?
- Subject: Re: [OT] What kind of data is is returned by 'new' ?
- From: Dirk Stegemann <email@hidden>
- Date: Wed, 13 Jul 2005 05:54:10 +0300
Hi,
Am 10.07.2005 um 14:29 schrieb Chris Page:
If someone can use a debugger to break on your call to random(),
all bets are off. They can examine your code, intercept calls,
modify memory, and inject code.
Actually, I'm quiet sure "they" already did so and will do it again.
And if they can do that, they've either got your privileges or
root, and you have worse problems than them trying to modify your
running program.
I never used a debugger myself to break on another program's system
API calls, so I might be mistaken, but I image analysing any
application is a relatively simple task for someone familiar to using
a sophisticated debugger.
Unless you're a crypto expert, I strongly advise you to use random
(). Also, read up on using srandomdev() to seed random(). Anything
else is almost certainly less secure. Most people aren't experts on
"randomness", and many things that most people consider "random"
aren't, or aren't sufficiently so.
Though I'm not a crypto "expert", I know how to hide an application's
important functionality using encryption mechanisms. Those mechanisms
do not rely on being fed by any random seeds, but will certainly grow
stronger the better these seeds are. An adversary having enough
insight to understand how to use this knowledge will most probably
search for the exact place where the random data is generated to
manipulate it; a system API call that simply returns a (high-quality)
random integer value should be found more easily than reading
arbitrary data from memory previously allocated by standard means
like malloc().
At least this is the way I understand it.
I am not a crypto expert, but I know enough to know better than to
try to use unproven and risky means to acquire entropy.
I agree, but I think this is about priorisation of random seed
quality vs. ease of manipulation of those seeds.
Of course, as soon as the adversaries' standard debug tools inherit
checkboxes to "break on random calls" and "wipe allocated memory",
this discussion might become obsolete anyway... ;-)
Best regards,
Dirk Stegemann
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden