1. less than random
I'd meant to make a point earlier about the rand() function not being
truly random, (it's a PRNG-- pseudo-random number generator) so a serious
attacker who knew what he was doing (who understood this sort of thing far
more than I) could perform a bit of statistical analysis on it and
prioritize his attack; he only needs to search until he finds the right key
so even if he has a billions of possible keys, if he can rank them by
likelihood, he might find the answer in far fewer attempts. But with such
a short chunk of random numbers (you're encrypting a 20 char keyword, not a
100k confidential text file) he'd probobly not have much to analyze.
Besides, this sort of attack is a bit more sophisticated than might be
expected against someone just using the built-in encryption of EUserver.
If I were sending information so valuable as to be worth that much time and
effort, I'd probobly be using RSA,DES,Blowfish, etc.
But the rand() function is quite a bit less random than I'd previously
supposed. Try this:
--the the numbers in the column on the left are "random" numbers
--generated by the numbers on the right
include machine.e
include get.e
atom seed seed=0
puts(1,"hit any key to run/pause a series of \"random\" numbers\n")
puts(1,"hit 'q' while paused to quit\n\n")
puts(1," rand seed")
procedure run()
while get_key()=-1 do
set_rand(seed) --line below: any power of 2 will work, but it
printf(1,"%6d %6d\n",{rand(power(2,16)-2),seed})
seed=seed+1 --helps to tweak it with a small add/subtract
end while
end procedure
while wait_key()!='q' do
run()
end while
I suspect rand() finds the remainder produced by dividing some huge
number
based on the seed by the argument to rand(), adding 1 afterwards to get the
proper range, and at some point the number was shifted left at least thirty
bits, multiplying the number by 2^shift, an operation which is nearly
canceled out by the aforementioned division if the argument to rand() is
very close to a power of 2, all of which are factors of 2^shift.
If you slowly increase or decrease the subtracted number in the printf()
line the difference between the rand() numbers will increase until they
seem random (the difference in the huge number in the background becomes
many times the size of the divisor,the range fed to rand(), so it loops
around and lands in some inconspicuous spot within that target range)
So what is that algorithm, Rob? (am I close?)
isaac
2. Re: less than random
Isaac writes:
> So what is that algorithm, Rob? (am I close?)
The algorithm is fairly complicated.
I picked it up several years ago from a published paper,
plus I've tweaked it, set some parameters etc.
I know that in most cases it's better (more random)
than the random number generators that you get with
most C compilers, including WATCOM, and typical
UNIX C compilers.
Now that some people are building encryption algorithms
that use it, I should probably not reveal the actual algorithm.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
3. Re: less than random
Here is a 'simple' example of a pseudo random generator. Test it!
--------------------------------------------------------------------
global atom IX
constant IA = 16807.0, -- IA and IP define the RAMDOM
I15 = 32768.0, -- number generator.
I16 = 65536.0, -- I15 and I16 are only to install
IP = 2147483647.0, -- an long integer division.
DK = 1.0 / IP
--
function random()
-- ******
-- Random Number Generator.
--
-- IX must be: 0 < IX < IP-1 as seed!
-- **********************************
-- Each call will return a float number > 0.0 and < 1.0
-- Also a new IX > 0 and < IP will be 'returned' as global.
--
atom IXH, IXA, LFTL, IFH, K
IXH = floor(IX / I16)
IXA = (IX - IXH * I16) * IA
LFTL = floor(IXA / I16)
IFH = IXH * IA + LFTL
K = floor(IFH / I15)
IX = (((IXA - LFTL * I16) - IP) + (IFH - K * I15) * I16) + K
if IX < 0.0 then IX = IX + IP end if
return IX * DK
--
end function
--
-- MAIN rnd_text
-- ********
atom a
IX = 2000000000 -- seed
for i = 1 to 40 do -- make 40 integer and float pseudo randoms...
a = random()
printf(1,"%2d:%12d%18.14f\n",{i,IX,a})
end for
4. Re: less than random
Robert Craig wrote:
> The algorithm is fairly complicated.
> I picked it up several years ago from a published paper,
> plus I've tweaked it, set some parameters etc.
> I know that in most cases it's better (more random)
> than the random number generators that you get with
> most C compilers, including WATCOM, and typical
> UNIX C compilers.
kewl!
> Now that some people are building encryption algorithms
> that use it, I should probably not reveal the actual algorithm.
on that note Rob (and those discussing crypto* with me),
I came across this link, and it's from a site that is the home
of the man that made Blowfish (and his latest incarnation, Twofish,
a most gnarly affair), and I think that it may just have a home
in EU... or as a library for sure. It's free, no royalties,
and knowing the algorithm for this PRNG helps you... none.
IMHO, worth taking a quick look-see...
http://www.counterpane.com/yarrow.html
a rather {insert_choice_of_words_here} name.... =>
_/ _/ _/_/_/ _/ _/ _/ _/ _/_/_/ _/
_/ _/ _/ _/ _/ _/ _/ _/ _/
_/_/_/ _/_/_/ _/ _/ _/_/ _/_/
_/ _/ _/ _/ _/_/_/ _/ _/ _/
_/ _/ _/ _/ _/_/_/ _/ _/ _/_/_/
({<=----------------------------------------=>})
({<=- http://members.xoom.com/Hawkes_Hovel> -=})
({<=----------------------------------------=>})
5. Re: less than random
>Now that some people are building encryption algorithms
>that use it, I should probably not reveal the actual algorithm.
Wrong way Rob. An encryption algorithm shouldn't rely on that fact.
With more information available, better algorithms can be
developed.
Regards,
Daniel Berstein
daber at pair.com
6. Re: less than random
Daniel Berstein wrote:
> >Now that some people are building encryption algorithms
> >that use it, I should probably not reveal the actual algorithm.
>
> Wrong way Rob. An encryption algorithm shouldn't rely on that fact.
> With more information available, better algorithms can be
> developed.
I agree... if someone takes a good look at the algorithm, and figures
out how to unencrypt something, all the better, as it will push the
development of better algorithms, which will eventually be broken, so a
new one is written, and so on. It's the same principle as how
competition between companies will push new innovations and advances,
rather than one company just leaving things as they are.
Greg
--
Greg Phillips
i.shoot at rednecks.com
http://euphoria.server101.com
--
Useless fact of the day:
Orcas (killer whales) kill sharks by torpedoing up into the shark's
stomach from
underneath, causing the shark to explode.
