Re: New encryption thread
Davi Figueiredo wrote:
>After understanding your algorithm
>(don't ask me how, it's a secret ;),
*snicker*
>I was able to find a password that will work:'alecramiroden'
>Many other passwords will work as well;
hrmmmmm..... take a look:
C:\>ex try alecramiroden
you don't got it
and for verification of the password found at the
bottom of that email message containing crypto.e:
C:\>ex try elvenbelvedere
you got it
#1: your password is not the same length, so it's 99.9%
chance of it not possibly working at all...
#2: it failed to decrypt.... :/
> In crypto.e, you used an algorithm that is a lot better than
> the shrouded one, because it cannot be easily cracked by hand,
thankee! :)
>However, I think a simple change would make it even better:
>simply adding the password bytes (in the sumup function)
>gives a low range of possible seeds for the random number
>generator (using a 20-char password, the maximum seed
>will be 255*20=5100).
yeah, i thought about that, but wasn't real sure if making
the # higher would actually help the strength of the algorithm...
>If you use a function that will be able to return a greater
>range of seeds, the strength of the function will be increased.
>The following function returns a maximum seed of 12418266.
but after seeing the code and after your explanation, i understand
now how it could help the strength... tnx!
{snip code}
what about the following? it's kinda sneaky :>
func sumup(seq data)
int sum
for i = 1 to len(data) do
sum = sum + data[i]
end for
set_rand(sum)
return rand(1000000000) --1 billion
end func
simple, fast, and creates *huge* seeds... :)
whatdaya think? will it work like i think it will?
> Don't worry too much. According to RSA's Cryptography Export Laws
> FAQ, you can export strong encryption if its purpose is 'access
> control'.
kewl! then i'll add the other thoughts I had to magnify the
strength, that won't change the "bit strength rating", and
then, i'll have fairly strong encryption, assuredly exportable,
(even if it does happen to be interpreted as a "high bit
strength rating") and itll be fast... then i'll be done
with worrying/coding these headache inducing algorithms :)
>The only problem would be that, as the source code is
>available, someone would be able to change it to create an
>encryptor/decryptor. But it wouldn't be easy to do that with the
>algorithm you created (I don't know if it would possible at all).
ill take that to mean you think highly of the algorithm :) tnx!
> Well, if you didn't have to worry about export regulations, you
> could just adapt my Blowfish encryption routines
yeah, i would have loved to, but, since blowfish is assuredly
declared 'verboten', i'm gonna stick with the algorithm I made,
not because *I* made it mind you... has nothing to do with that...
>Maybe someday (hopefully soon) I will create a homepage for it
>outside the U.S. and then anybody will be able to download it directly.
ummmm... *ponder*.... ummm.... exporting is defined partially
as the process of transferring a file containing an algorithm
that implements a particular bit strength encryption.
so, unless i am really really way off base, when u goto place
the file at that web site that u create, u will be breaking
the export laws at that moment...
it's a grey area, from what i can tell in my readings, so...
be careful, eh?
> Now, talking about the need for *very* strong encryption in
> EUServer (when it becomes EU_FTP), I agree strong encryption
> is important, but is this sooooo crucial?
well, i just wanna make sure that examination of the algorithm,
since the source is public, will not reveal a method of
crtypanalysis that could be used by someone attempting to
login as 'root', and that their only option is bruteforce...
(either scrolling possibilities or throwing dictionaries...)
and, i'll take measures to prevent bruteforceing, since that
is relatively easy to do, in fact...
first way: similar to the three strikes and u r out, if you
botch a PW entry after 3 tries, we disconnect you. if after
3 disconnects (9 tries) u still aint got it, you won't
get back to be even _able_ to attempt a PW entry... EUServer
has the IP of where u r coming from before it even has sent
(nearly) a single byte of data back to you (ie:greet, getname...)
and as such, and especially since ban() is already in place :),
that ip will not be able to connect again for ohhhh lets say...
72hours? (this way, those with dyn ip that happen to get this
losers old dyn ip can connect...)
second: naturally, all attempts that fail are logged, no matter
what status the log status is at... if we see (or create a log
file 'processor' to see) that a certain sub domain name is
constantly attempting bruteforce/failing, we can alert that
isp...
>I mean, the files containing the passwords are not in a
>public directory,
no, they won't be accessible via remote, even by the sysops...
(im debating allowing root access to them remotely... i'm thinking
-no-... the root user will still have commands that can alter
a users ban/noban states... but i see no reason as yet to even
allow the ftp server the ability, at all, to change to that dir)
> only the owner would be able to crack the passwords...
basically no. but yes.... ummmmm
see, there is a weak point, that i actually mention, because
i'm hoping that by mentioning it, it raises awareness of this
issue with everyone, because the weak point exists on any/all
server software (no matter the type) that has open source.
ergo:99.9 of most muds...
if the source comes precompiled, then this loophole is not easily
exploited...
with open source comes the ability for the 'owner'/'implementor'
to be able to view *everyones* passwords as they type them in.
(or be able to view it by logging it and reading the logfile...)
think about that... all the diku/merc/envy/circle muds (almost
assuredly) that come nowadays can be easily altered to show
a user's password... the encryption is 'useless' if you have
no morals...
same holds for EUServer... an implementor using it without morals
can easily adapt the code to show plaintext passwords...
even if i took it out, its just too easy to put back in...
so i leave it in for certain debugging purposes...
however, if the implementor leaves the default logging status
alone, then, passwords are fully safe. noone can read them
and nothing about it will be mentioned in the logs, and
noone will be able to recover them, that i know of...
not the implementor and not even myself...
_/ _/ _/_/_/ _/ _/ _/ _/ _/_/_/ _/
_/ _/ _/ _/ _/ _/ _/ _/ _/
_/_/_/ _/_/_/ _/ _/ _/_/ _/_/
_/ _/ _/ _/ _/_/_/ _/ _/ _/
_/ _/ _/ _/ _/_/_/ _/ _/ _/_/_/
({<=----------------------------------------=>})
({<=- http://members.xoom.com/Hawkes_Hovel> -=})
({<=----------------------------------------=>})
|
Not Categorized, Please Help
|
|
