1. New encryption thread
thanks to everyone that replied to my first
encryption post.
a lot of things said in those posts and a lot
of information resources that were pointed to
in those posts helped and enabled me to create
the next generation of encryption algorithm(s)
to be used in EUServer.
this latest algorithm i've written, is *far*
more secure than any crypto methods used thus
far in EUServer, and i believe more secure than
the only other encryption algorithm i saw in
the EU archive (from ralf...).
one of the chief points that prompted me to hurt
my wittle head creating a strong, yet easy to
understand, and easy to implement algorithm, was
a statement made that no algorithm is secure unless
the algorithm is viewable, and the viewing of said
algorithm doesn't help you decrypt a ciphered string.
the resultant algorithm below, is very fast, very
easy to understand, and actually quite secure.
granted, each 'calculation' upon the key that
i make is not necessarily original, and even
the sum total of all the calculations may mirror
another algorithm, but i did think of it myself :)
it should also be exportable and allowable in
any country as (in theory) i'm not going past
40bit encryption (theory says i'm using 32bit..)
at any point; and yet, theory also says that you
would need to attempt up to 6.29e47 permutations
of keys to decode it (based upon the server
accepting up to length 20 passwords), maybe more...
so, here are the algorithms and a testing program
to see if you found the proper key for a given cipher.
If the consensus is that this is a good, strong,
relatively hard to crack algorithm, i will incorporate
this into EUServer, but the caveat to that is that,
once again, all versions of code prior to this change
will be 'broken' and all user files will have to be
scrapped again.
the upside is that i doubt i'll need to change the
encryption again, (if it's agreed that this is a
strong enough algorithm) and as such, i won't need
to thrash the user files again. also, i feel it
would be worth trashing them one last? time...
lastly, feel free to use Crypto.e at will, in your own
programs, and I will be adding a link on my web page
to be able to download that include file.
so, can we guess/crack the cipher in try.ex? :)
(for verification purposes, and to see if this
algorithm might produce the same cipher for
more than one key, i include the key that i
used to create the cipher far far below in
this message. if you find another key that
makes try.ex say 'u got it', please, lemme
know...)
_/ _/ _/_/_/ _/ _/ _/ _/ _/_/_/ _/
_/ _/ _/ _/ _/ _/ _/ _/ _/
_/_/_/ _/_/_/ _/ _/ _/_/ _/_/
_/ _/ _/ _/ _/_/_/ _/ _/ _/
_/ _/ _/ _/ _/_/_/ _/ _/ _/_/_/
({<=----------------------------------------=>})
({<=- http://members.xoom.com/Hawkes_Hovel> -=})
({<=----------------------------------------=>})
----------begin try.ex
include Crypto.e
constant
cmdline = command_line(),
cipher = {62,34,74,113,36,33,81,76,20,114,91,52,89,42,
38,91,57,77,56,72,46,109,34,44,116,33,70 }
if length(cmdline) != 3 then
puts(1,"use: ex try <phrase_u_think_the_password_is>\n")
abort(1)
end if
if Decrypt(cipher,cmdline[3]) then
puts(1,"you got it\n")
else puts(1,"you don't got it\n")
end if
----------end try.ex
----------begin Crypto.e
include machine.e
function sumup(sequence data)
integer sum sum = 0
for i = 1 to length(data) do
sum = sum + data[i]
end for
return sum
end function
global function Encrypt(sequence key)
--we add padding to ensure the cracker doesn't know the PW len
--generate a seed
set_rand( sumup(key) )
--add random padding
key = key & key[1..rand( length(key) )]
--xor encrypt the key against a seeded,
--random, version of itself
return xor_bits(key,rand(key))
end function
global function Decrypt(sequence cipher, sequence key)
--useage: given an encrypted 'cipher' text string and a test case
-- 'key' to decrypt by, return t/f if it was/wasn't the right key
object temp
--determine the prior seed
set_rand( sumup(key) )
--attempt to repad back to the original padding
temp = key & key[1..rand( length(key) )]
--obviously, if the resultant padding amount is not the
--same length of the initial padding amount, it's not the
--proper key, but, this next test is also to ensure that
--xor_bits has equal length arguments to operate upon
if length(temp) != length(cipher) then return 0 end if
--reconstruct the randomly seeded, randomly generated cipher
temp = xor_bits( cipher, rand(temp) )
--snarf to the correct length
temp = temp[1..length(key)]
--determine if key is indeed the right key
return compare(temp,key) = 0
end function
----------end Crypto.e
answer is below this line
------------------------------------
far below :)
"elvenbelvedere"
sans the quotes
2. New encryption thread
Question: Is encryption really needed?
Are you sending top secret military espionage facts, or verry perrsonal
inforrmation?
491024418?
3. Re: New encryption thread
Ad Rienks wrote:
> Question: Is encryption really needed?
yes, actually, there needs to be a method of access control
if we are discussing a network server. especially if that
server has more than one level of access control for
various exectuable command activities.
would you want joe blow to have root access to your machine,
if the server was altered to be an ftp/http server?
would you want joe blow to be able to listen in on private
conversations if the server was a chatter?
the implementor is the only one that should have that type
of power to 'snoop' since they need to monitor activities
that are potentially illegal or monitor an individual that
has been reported as being ... ohhhh.. lets say abusive, to
see if that individual is doing what they are accused of.
would you want some smuck at random to have the power
to ban anyone else (like *you*?) at random from said server?
if we stripped out all sysop commands, and implemented the
server as only a chatter, one might have an argument that
passwords/controlled access might not thusly be needed.
i counter that by saying that without those commands, the
'owner' (implementor) of said chatter would be powerless
to stop potentially bad scenes as they occured, and occur
they *will*. some pair of smucks will get online within
this chatter and begin setting up an exchange of kiddie
porn or some other such equally illegal act, and this,
sadly, you can bet on...
my encryption dilemma mostly centers on the issue of
*exportability*.
since this server will be downloaded by members of
this listserv, for example, and those members are
of quite varied points of origin, I, as the coder,
have to make sure that any/all algorithms used to
control access to the server adhere to rather
stringent (but often silly) laws regarding the
exportation of encryption algorithms.
if i did not have to worry about these laws, i would
have simply swiped the DES (or sumfin) algorithm,
slapped it into the server, and been done, long ago.
the problem lies in the fact that there aren't that
many published algorithms that ARE exportable...
at least not that i found and understood them to be...
i found several algorithms, yes, most were over 40bit,
the limit of exportation, and a few others that seemed
to be under 40bits i just didn't quite "get"...
i might have understood them had i spent far more
time studying them then i really had time to spend...
the result is the algorithm that i posted, which,
if anyone cares, the best description of it would be
a modified symmetric-key chained block cipher, loosely
interpreted, and with the provision of actually being
upgradeable to even higher security thru the use of
iterative recursive passes thru the algorithm.
the block sizes in this case are, at one point, 8bit and
at another point, are (in theory) potentially 32bit...
only 8bit you say? well, heh :) you still would have little
choice but brute forcing or throwing a dictionary at the
password prompt...
hopefully, this clears up why i needed encryption, and
for anyone that might need encryption for software they
are writing and was thinking about using this algorithm,
hopefully it cleared up how the algorithm was created and
how it works...
take care,
_/ _/ _/_/_/ _/ _/ _/ _/ _/_/_/ _/
_/ _/ _/ _/ _/ _/ _/ _/ _/
_/_/_/ _/_/_/ _/ _/ _/_/ _/_/
_/ _/ _/ _/ _/_/_/ _/ _/ _/
_/ _/ _/ _/ _/_/_/ _/ _/ _/_/_/
({<=----------------------------------------=>})
({<=- http://members.xoom.com/Hawkes_Hovel> -=})
({<=----------------------------------------=>})
4. Re: New encryption thread
Hawke' wrote:
>would you want joe blow to have root access to your machine,
>if the server was altered to be an ftp/http server?
I certainly would not want any1 to come in unauthorized and use my machine!
Could that be the case when I use EUserver?
I'm sorry if my questions are ignorant and/or bloody stupid, but I have to
admit that this aspect of computer usage has always been a mystery to me,
up till now.
I'll spare you the frustrations I got when trying to surf the internet,
building a web page, downloading etc. I think I need a good tutorial, maybe
'Internet for Dummies', but I doubt if all my questions and problems would
be solved then.
Maybe I should ask Ralf to explain things to me in our own language,
privately.
I have seen that you wrote quite a large readme.txt file, and I'm not
blaming you, certainly not, but could some one please tell me more about
all these acronyms used, such as MUD, DES, cgi, etc, etc.... And what can
be done with it. Then maybe I will be able to decide if I like to have
these possibilities and how to use them.
Thank you for listening,
Ad
5. Re: New encryption thread
.
>Maybe I should ask Ralf to explain things to me in our own language,
>privately.
>I have seen that you wrote quite a large readme.txt file, and I'm not
>blaming you, certainly not, but could some one please tell me more about
>all these acronyms used, such as MUD, DES, cgi, etc, etc.... And what can
>be done with it. Then maybe I will be able to decide if I like to have
>these possibilities and how to use them.
Actually, I have a vague idea what a MUD is (multiplayer dungeon) and I know
what a CGI is, but a DES or half of the other words there, I really dont
have a clue about, sorry Ad. Like I said before I never seen any good text
about networking, and that's where I need to get it from.
Ralf
6. Re: New encryption thread
Ad Rienks wrote:
> Hawke' wrote:
> >would you want joe blow to have root access to your machine,
> >if the server was altered to be an ftp/http server?
> I certainly would not want any1 to come in unauthorized and use my machine!
i'm glad! :)
> Could that be the case when I use EUserver?
well, yes. absolutely. sorta :)
(confusled yet? => )
if you ran EUServer, as it sits right now (1.64), which doesn't
even take into account the latest algorithm that i just posted,
but is using, instead, the algorithm contained in encrypt.shr,
you have little to fear.
firstly: even if there was NO password checking done, there
is no direct access from within the server to the files
upon the machine being used as a server.
the only files that are accessible from the 'server' are the
userfiles and the log files...
so you are safe if you only use EUServer as it sits, right now.
_however_
=========
when/if we get EUServer ported/expanded/upgraded to EU_FTP,
which would be a ready to go FTP server for your windows machine,
(this would allow you to become the next ftp.shareware.com or
something, allowing some/many/any users to send and receive
files placed/located on _your_ harddrive... an example of this
might be ralf and his bot match program. he would convert
EUServer to be an arena for fights, and to make his life easier,
he would set up EU_FTP to allow contestants to place their
bot "scripts/files/includes" upon his harddrive directly,
after being authenticated as a member of EU listserv for example,
and the contestants could then enter the arena and battle it out...
all this without the need for ralf to lift a finger or even
be near his machine...)
you will of course _NEED_ the best encryption that we can get you.
either that, or we rule out the ability of the FTP server owner
having access to his machine from *outside* that machine...
this limitation is not one that many will tolerate...
so you do need to have a 'rootuser' persona in the user
database to allow you, remotely, to change/move/delete files that
aren't in the /pub directory, or perhaps ban a user that is
abusing your ftp server...
let's go back to ralf, he's easy to pick on ;)
let's say we get a disgruntled contestant, a hotshot who knew
for sure he couldn't lose and doesn't take kindly to losing...
if we didn't have security imposed upon the FTP server, at all,
and all access to directories other than /pub was forbidden
by _everyone_, including the owner (as there is NO rootuser
persona in this example), then how would we impose individual
quotas for diskspace upon tom, dick and harry?
we couldn't. so this disgruntled smuck, who is a *loser* :),
decides to ftp into ralf's poor machine about a dozen
copies of the britannia encyclopedia measuring about a gig,
burns his bandwidth, and locks his machine because his
HD is now full and windows ain't got nuffin left for a
swapdrive...
yes, it can happen, and i've seen it happen.
no, in EU_FTP, i will do as much as i possibly can, using
all my knowledge in these matters, as well as knowledge
gleaned from others, to prevent such stoopid sh|t from happening.
furthermore, i have already thought of 2 more things i can
do to the user password encryption system, that won't slow
it down to speak of (speed counts :) and will magnify the
resultant strength of the cipher without changing the
bit strength (and thusly ruling out exporting it to you guys...)
on that note, i'm having trouble determining exactly _how_
the bit strength of an algorithm is quantified...
in one article i read, it said that the bit strength is
the number of bits in a processed cipher block...
well, ;) that means the algorithm is 8bits... heh...
on the other hand, someone mentioned to me it was the
length of the _key_, which in this case is 20char's by
8bits per, yielding 160bit strength...
we discussed that further, and we don't feel that could
be accurate, as the length of the password (key) cannot
possible have bearing on the "official bit strength"...
can it???
> I'm sorry if my questions are ignorant and/or bloody stupid, but I have to
> admit that this aspect of computer usage has always been a mystery to me,
> up till now.
hey, tis why we are _all_ here, because each of us knows
something the others don't. we share that and grow.
let's see, have i asked stoopid questions?
yes.
have i asked stoopid questions that i actually _knew_ the
answer too? (far more 'toopid, dontcha think? :))
uhhhh yeah...
have I made stoopid mistakes (and *blushed* as a result?)???
yeppers...
have I made not so stoopid mistakes, and got nailed to
the wall for it? (thank you _so_ much jiri, ralf... ;-> )
errr ummmm ayup...
did i learn from any of the above?
yeah. we all do.
david's turn =>
how many programming oversights are in win32lib?
who cares... noone, really... likely the same number of
people that would care that your questions appeared to them as
stoopid... this is the same group of people that i would likely
ban AND slay, first :)
we, here, in this listserv, i think more than
just about any other cross section of people interested in
a common hobby that i have been involved with, are very
much a _group_... a team...
> Maybe I should ask Ralf to explain things to me in our own language,
> privately.
you could opt for that choice, surely...
my suggestion to you would be not to, but instead, ask all of us...
sometimes, i have found after asking a question, that one or two
replies to that question from person X and Y don't really... click.
but then, a third reply comes along from Z and it falls into place...
each person on this list can explain the same topic in a different
way, and that is the strength of this list...
> I have seen that you wrote quite a large readme.txt file, and I'm not
> blaming you, certainly not, but could some one please tell me more about
> all these acronyms used, such as MUD, DES, cgi, etc, etc....
wellllllll
*deep breath*
the first two letters in MU*** stand for multi-user.
there are ~half dozen 'types' of MU*** thingies out there.
MUD is considered to be "multi user dungeon" or, alternatively,
"multi user dimension".
another common one is MUSH, which is "multi user shared hallucination"
then we have MOO, MUCK, and bunches more...
the two u likely need only remember is MUD and MUSH.
the generally held differentiation between them is that
MUDs are generally role-playing-game based (RPG) and involve
"becoming" an alter ego persona. generally, these personas
revolve around fables/legends/myths of common lore, replete
with iconic images and characters from greek/roman mythology.
other times, MUDs may revolve around things like Tolkein and such...
continuing in the actual distinction of MUD/MUSH, is that
your persona explores this realm, questing and fighting, and
gains experience for doing so, and this experience is applied
to a ranking system of levels. once a certain level is reached,
your persona is considered heroic or even immortal.
a MUSH, by contrast, is usually stronger in a central, more
specialized and focused theme, and centers more on conversation
with other users, as well as easy expansion of the realm,
by the users, for a user's personal section of the realm to
be more 'in tune' with that image of what the user holds
in his mind as what his persona might be. there is generally
no fighting, questing, or leveling on a MUSH, persay.
some MUSH's are often extremely specialized, and often are
academically based. one MUSH i had heard of was for students
at such/n/such Univ enrolled in a specific class, to discuss
the class/homework/assignments.
DES: its the name of an encryption algorithm commonly used.
others are: blowfish, skipjack, RSA, twofish, elliptic curve,
XOR, yadayadyadayada...
>And what can be done with it. Then maybe I will be able to
>decide if I like to have these possibilities and how to use them.
well, EUServer can be made into an HTML server (your website
is actually housed on your machine, with all the room for
your site being defined by the size of your HD, not some
silly 2meg quota) or an FTP server (see above example)
or a MUD (many of us are working on that one) or a MUSH
(how about a Euphoria MUSH??? kept "on" 24/7 with
someone from the list almost assuredly happening to be
online within it?)...
we can also make a conferencing application from it,
a whiteboard (one person draws an image, and the others
*see* that image drawn in real time), a net telephone server,
multi users games of nearly any type can have EUServer
built in as an "include" persay, and exploit euphoria
and be multiuser ready (with no silly 8 player limits),
and this includes graphical games, not just text.
we could make it an email server as well, dishing up
email to whomever wanted a new email account, and
this could be a free service or a pay service...
you could choose to quota or not quota the email accounts...
(i have a 2meg quota on my email... it's free and works with
my gateway, but... i gotta make sure i check/DL my
email way too often)
i am most sure that i have forgotten something that EUServer
could do/be adapted to...
oh yeah, shared coding... one person types in code, everyone
sees it, realtime, and everyone can then alter that snippet,
until the 'group' agrees that the code 'looks right' and
then someone could execute that code, on their machine,
with the results of the execution (depending...) being
shown to _everyone_ at the same time, in real time...
and lest we forget ralf's bot fights :) a whole new
venue (arena bot fights...) for multi user games...
there is nothing actually, that i've seen, quite like that...
kinda like a MUD, but people are sending in mini brains
to fight with instead of themselves being portrayed as a persona...
> Thank you for listening,
yer velcome :)
_/ _/ _/_/_/ _/ _/ _/ _/ _/_/_/ _/
_/ _/ _/ _/ _/ _/ _/ _/ _/
_/_/_/ _/_/_/ _/ _/ _/_/ _/_/
_/ _/ _/ _/ _/_/_/ _/ _/ _/
_/ _/ _/ _/ _/_/_/ _/ _/ _/_/_/
({<=----------------------------------------=>})
({<=- http://members.xoom.com/Hawkes_Hovel> -=})
({<=----------------------------------------=>})
7. Re: New encryption thread
- Posted by Daniel Berstein <daber at PAIR.COM>
Dec 12, 1998
-
Last edited Dec 13, 1998
>I have seen that you wrote quite a large readme.txt file, and I'm not
>blaming you, certainly not, but could some one please tell me more about
>all these acronyms used, such as MUD, DES, cgi, etc, etc.... And what can
>be done with it. Then maybe I will be able to decide if I like to have
>these possibilities and how to use them.
Hi Ad!
MUD and DES were all ready explained. Let's go with CGI's:
CGI (Common Gateway Interface) is a specification by wich a web server
comunicates with an application. Think of Yahoo. You type your search
criteria and press submit, then you get a bunch of result. What's behind the
scene is one or more CGIs working for you. Once you press the submit
button the webserver (I think Yahoo is using Apache over FreeBSD OS),
executes an application on the server (an .exe or .bat file if it was a
Windows
machine). These application is called a CGI application or script (yes it
can
also be a shell or Perl script). The CGI specification says how the data the
user inputed is passed to the application, and how the application returns
information to send back to the client's browser (the HTML page you get
back with the result of your request). The webserver usually pass the data
thru the standard input and the CGI application thru standard ouput. There's
also WinCGI, that passes data thru an .ini file.
Some CGI links:
www.cgi-resources.com
(I don't remeber others right now)
I plan to make a basic CGI include file for Euphoria after I finish the new
release of VE. Irv has some expirience writing CGI's with Euphoria.
What webserver were you using Irv? I'm testing with Xitami.
BTW I still haven't tested your REMOVEITEM buggy code. I'm busy re-coding
the next release of Visual Euphoria. One bad new: All existing VE code will
be broken. Good news: far more powerful, maintainable (for me), and
flexible... it may even work in conjunction with win32lib!
Regards,
Daniel Berstein
daber at pair.com
8. Re: New encryption thread
- Posted by Ad Rienks <Ad_Rienks at COMPUSERVE.COM>
Dec 12, 1998
-
Last edited Dec 13, 1998
Hawke' wrote:
>so you are safe if you only use EUServer as it sits, right now.
Thanks, for your explanation and for EUServer. But... what *can* I do with
it right now? I started it up using run.bat, the dialing dialog came up, I
had to input my compuserve password (couldn't that be inbuilt?), I got
connected and a mini window popped up, saying something about EUServer. It
also says: Active socket nums: 7. What exactly are sockets and why 7? And
what is this logfile thingie? What should and could I do now? Actually,
when I shut down (manually), I can see that there are 353 bytes send and
529 bytes received. Where from/to? Please, if anyone else besides Hawke'
has some answers, give them to me and probably also to other confused
readers.
TIA,
Ad
9. Re: New encryption thread
- Posted by Ad Rienks <Ad_Rienks at COMPUSERVE.COM>
Dec 12, 1998
-
Last edited Dec 13, 1998
Daniel wrote about the new version of VE:
> Good news: far more powerful, maintainable (for me), and
flexible... it may even work in conjunction with win32lib!
That is really good news! Can't wait to see it!
Regards, and keep up the good work!
BTW, how was your project received at the university?
Ad
10. Re: New encryption thread
I am a little late, haven't had much free time these days.
Anyway, here are some comments:
Hawke' originally wrote (subject 'encryption'):
>as such, I am in need of person's interested in
>attempting to take an encrypted string (sequence of
>char) and determine what the password is, from that string...
After understanding your algorithm (don't ask me how, it's a
secret ;), I was able to find a password that will work:
'alecramiroden' (without the quotes). Many other passwords
will work as well; I didn't want to spend my time trying to
find a known word, just tried to find one that sounded good
(well, at least I can pronounce that one).
In crypto.e, you used an algorithm that is a lot better than
the shrouded one, because it cannot be easily cracked by hand,
so you have to use brute-force. 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). 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. It would be possible
to create an even better routine, but I am too lazy today ;)
-- begin code
function sumup(sequence data)
atom sum,sum_of_sums
sum=1
sum_of_sums=0
data=data&1 -- so data[i+1] won't give an error
for i=1 to length(data)-1 do
sum=sum+data[i]
sum_of_sums=sum_of_sums+sum*(data[i+1]+1)
end for
return sum_of_sums
end function
-- end code
In theory, it is possible that more than one key will produce the
same cipher, but this would be very rare and very hard to find too.
Hawke' wrote:
>my encryption dilemma mostly centers on the issue of
>*exportability*.
>
>since this server will be downloaded by members of
>this listserv, for example, and those members are
>of quite varied points of origin, I, as the coder,
>have to make sure that any/all algorithms used to
>control access to the server adhere to rather
>stringent (but often silly) laws regarding the
>exportation of encryption algorithms.
>
>if i did not have to worry about these laws, i would
>have simply swiped the DES (or sumfin) algorithm,
>slapped it into the server, and been done, long ago.
and also:
>furthermore, i have already thought of 2 more things i can
>do to the user password encryption system, that won't slow
>it down to speak of (speed counts :) and will magnify the
>resultant strength of the cipher without changing the
>bit strength (and thusly ruling out exporting it to you guys...)
Don't worry too much. According to RSA's Cryptography Export Laws
FAQ, you can export strong encryption if its purpose is 'access
control'. 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).
Anyway, as you said, the algorithm is still weak enough.
Well, if you didn't have to worry about export regulations, you
could just adapt my Blowfish encryption routines to do what you
want. I announced these on the listserv some time ago and some
people were interested. People who want them but haven't got
them yet should send me an e-mail and I will send it to them.
I haven't sent the program to the Archives because of... you
guessed it... the stupid export regulations. 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.
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? I mean, the files
containing the passwords are not in a public directory, so
only the owner would be able to crack the passwords... or
not? Well, I know almost nothing about servers/clients and
this kind of thing, so maybe I've just said something stupid.
Regards,
Davi Figueiredo
davitf at usa.net
____________________________________________________________________
Get free e-mail and a permanent address at http://www.amexmail.com/?A=1
11. 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> -=})
({<=----------------------------------------=>})
12. Re: New encryption thread
- Posted by isaac <isaaca at MINDSPRING.COM>
Dec 13, 1998
-
Last edited Dec 14, 1998
As implemented in your crypto.e, the encrypt function is closer to a hash
function, used for password confirmation. If this is how you intend to use
it, why do you need encryption at all? Why not just have a list of
passwords on a file in the computer which the server won't allow to be read
without the appropriate access level? It's just as hard to guess the right
password if it's encrypted on a computer somewhere far away as if it were
in plaintext on a computer far away. What do you suspect the attacker has
access to?
Lets assume he has access to the ciphertext, as we did in your example.
The random seed can easily be narrowed down, mainly through the sumup
function because the order is insignifigant. The ciphertext we were given
was 27 characters long, but we know the last one is padding, so 26. 26*255
gives us a range of 0-6630, or 6631, possibilities, which shouldn't take
too long to try on a computer. (If it takes as long as several hours,
which it wouldn't, this would be unacceptable considering the attacker
would then have all access attributed to this password.) But if I assume
the password is within the range of typeable&viewable ascii characters,
32-124, the range is cut to 832-3224, or just 2392 possibilities.
For each seed we test, we must determine the possible lengths of the
unpadded key. This can be found with:
function getlen(atom cipherlen,atom seed)
-- returns all possible key lengths for a given cipher length and seed
-- if none are returned, the seed can be eliminated
sequence keylen keylen={}
for x=floor(cipherlen/2) to cipherlen-1 do
set_rand(seed)
if rand(x)=cipherlen-x then
if x*255>=seed then -- a filter derived from sumup
keylen=keylen&x
end if
end if
end for
return keylen
end function
When this function is applied to each seed in our range, some seeds have
several possible lengths, thus increasing our range of possibilities, but
others have none; a ciphertext of 27 characters, as in your example, yields
1632 possible keylength-seed combinations, and it took my 486/33(yes, 33)
only 8.57 seconds. A longer ciphertext wouldn't help either; in fact a
length of 100 yields only 1198 combinations.
The strongest portion of your algorithm is the dynamicaly ranged random
number generation, which gives an attacker problems even after the seed is
discovered because the range of the rand funtion isn't known until after
it's been used, but each number in the ciphertext does provide a minimum
value for the corresponding character in the key.
We can now sift through the combinations, checking the first character
against the ciphertext and the padding(which repeats) like so:
--untested
function check_first_char(atom keylen, atom seed, sequence ciphertext)
sequence chars chars={}
for x=ciphertext[1] to 124 do
set_rand(seed) if rand(1) then end if
if rand(x)=ciphertext[1] then
for y=2 to keylen do
if rand(1) then end if
end for
if rand(x)=ciphertext[keylen+1] then
chars=chars&x
end if
end if
end for
return chars
end function
This will return a list of possible first characters, giving us a list of
seed-keylength-firstchar combinations. We can proceed in a similar manner
through the remainder of the characters.
Though it could use a bit more work, here's a new version of sumup which
should increase the overall strength immensly:
function sumup(sequence data)
atom sum sum=0
for i = 1 to length(data) do
sum = remainder (sum + data[i]*power(4,i-1),power(2,31))
end for
return sum
end function
PS From what I understand, any encryption technology is subject to
examination by the authorities if it has the ability to transfer data in an
encrypted state, but if the algorythm can only be used to verify a user (as
in your implementation) and the data sent to that user isn't encrypted, or
is encrypted by another (legal)algorythm, the verification algorythm may be
as strong as you like. Furthermore, there is no specific limit to the bit
strength of an algorythm for data transfer. If the government finds an
algorythm too strong, you must obtain a liscence to use it. If you invent
your own fairly weak algorythm, you can distribute it as you wish, but at
your own risk; if the government (I forget which agency) sees you and
decides it's too strong, you can be held liable. So, if in doubt, you
should have it inspected before dispersing it internationally.
All of the above is the way it works as I understand it; it is not
nessesarily the truth.
I hope I've been helpful.(though I may have only given you more work to do)
13. Re: New encryption thread
- Posted by isaac <isaaca at MINDSPRING.COM>
Dec 13, 1998
-
Last edited Dec 14, 1998
Oops, that's what I get for not checking the mail before posting.
Improving sumup will help a lot. But you can narrow it down a bit, as I've
shown, before resorting to brute force.
isaac
14. Re: New encryption thread
- Posted by Davi Figueiredo <davitf at USA.NET>
Dec 13, 1998
-
Last edited Dec 14, 1998
Hawke' wrote:
>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
Sorry if I didn't make myself clear, I was talking about the first
algorithm you posted, the shrouded one...
>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?
I suppose not. There are still only 5100 different seeds, because each
of the 5100 possible values sent to set_rand will give always the same
number. To increase the strength, you need to increase the number of
different possibilities.
>>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?
Don't worry, I live in Brazil :)
About the need for passwords: What I was saying is that, even if the
passwords were stored without any encryption (or with a very weak one),
the hacker wouldn't have access to them anyway. But I agree, if it
won't slow down the system (or almost not) and if it isn't doing any
harm, then just leave it in. As they say, better safe than sorry...
Regards,
Davi Figueiredo
davitf at usa.net
____________________________________________________________________
Get free e-mail and a permanent address at http://www.amexmail.com/?A=1
15. Re: New encryption thread
- Posted by Hawke' <mdeland at GEOCITIES.COM>
Dec 13, 1998
-
Last edited Dec 14, 1998
Ad Rienks wrote:
> Thanks, for your explanation and for EUServer.
yer velcome :)
>But... what *can* I do with it right now?
frankly, not very much... heh...
there are 2 reasons for that.
1>it's designed to be a _generic_ server with minimal 'stuff' that
you would need to rip out because u didn't need it for the application
you were creating with it...
2>i (and others) have not had a chance to create anything else with it,
like EUMud or EUftp or EUhtml... etc...
what u can do, at this point, is minimialistic 'chatting'...
you can have friends/enemies/whomever telnet into a server you
are hosting and have group (a huge numbered group) sessions discussing
this/that/the other. in effect, it's a mini MUSH...
>I started it up using run.bat, the dialing dialog came up, I
>had to input my compuserve password (couldn't that be inbuilt?),
that has nothing to do with EUServer, that is a setting in your
win95 DUA/DUN settings. EUServer does NOT require connection
to the internet IF you have the proper bindings in the network tab.
most people don't, unless they happen to also be connected to
a local lan, and i'm working on determining if certain settings
that will not affect a user's ISP settings can be *ahem* twiddled,
and provide a 'proper' set of bindings (that really should have
been there, had the isp tech's been _fully_ helpful in setting
up internet access... most only worry about setting the few
settings needed to gain internet access and don't worry about
how those settings can make other aspects of networking askew...)
also, besides users having trouble getting it to work without
being connected to the internet, i have received/noticed many
emails/posts about users having trouble wishing to run the server
on their machine and attempting to connect to 'localhost' or what not...
i'm in the middle of working on the solution to that, or more to the
point, writing the text to _explain_ how to fix that...
(it only takes a couple mouse clicks, but it's an uhholy chore
trying to type out the step by step to explain how to fix the
localhost issue)
>It also says: Active socket nums: 7. What exactly are sockets
itsa safe bet that you really don't wanna know the real, full,
complete, answer to that question :) (j/k)
EUServer listens for people to connect to it on a specific port.
these connections involve the use of the telnet protocol.
every computer has the capability to have ports, and ports are
a 'location' where data is exchanged. (in and out).
network ports are ideologically no different than a serial port
or a parallel (printer) port, they all simply let data pass in
and out of the computer.
most machines configured for networking have hundreds, if not
thousands, of 'network' ports that allow data from outside
the computer in and out.
one of these ports is numbered 110 which is the port responsible
for POP3 email, and often it's companion is 25 for SMTP (sending mail).
another port is 21, for FTP...
a standard win95 machine has ohhh bout 200 ports or so that are
potentially (read that *rarely*) used but ready to go... these
ports are defined in \windows\services (no extension) and i
would strongly suggest not altering that file unless u know
what u are doing, but, a look with 'quickview' won't hurt you,
and u can see all of the ports that win95 can handle already.
if u noted that EUServer uses port 9000 (it's why u have to type
the 9000 after the IP number when u telnet), and u wonder
why i choose that number, well, i happened to notice that
in services, it was 'free', as a default.
i figure if someone IS using 9000 for something else, that they
must know about it, because they had to set it up themselves,
and would be knowledgeable enough to know that they needed to
change EUServer's default port to something else that was free.
so now, we have EUServer listening for people to connect to it,
on a specific port.
"what does this have to do with sockets?"
well, on the premise that we want to have more than one user,
we have to have a method to be able to exchange data with
any _specific_ user that has connected to that port.
think of it this way, have you ever had more than one file
downloading at once? have you ever seen a web page loading more
than one 'thing' on that page at once? (like a couple buttons,
and a couple images, all at the same time?)
you only have one port for ftp, and you only have one port (80)
for HTTP, so how are all these different 'things' arriving
at your machine, at the same time, on this one port, getting
reassembled to their correct locations?
sockets.
each port has the ability to have multiple, individual streams
of data exchange from one person/computer to another person/computer.
a socket is a unique, individual, data exchange sub pathway/stream.
if joe, bob and mary are all connected to the EUServer, then
joe, bob and mary each own their own piece of port 9000, their
own individual socket. if joe wants to send a secret "i love you"
gushy mush message to mary, well, he would'nt want bob necessarily
to know about it. so EUServer takes that i love you message
from joe's socket, privately and individually, and sends it
back out to mary's socket, privately and individually.
the last way to think about what a socket is, might be the
EUServer equivalent of a phone number.
every person (household) has a unique phone number, ergo:socket.
EUServer is the phone company. (we'll show them Bells!)
this means that when you type who, and you see that unique ID
number on the left hand side of the listing, its like looking
in a phone book for mary's phone number.
but EUServer is more powerfull than most phone companies,
because most phones do not allow you to "call mary"...
you can only "call 555-1212"...
EUServer gives you the choice of:
tell mary i love your
and if mary's socket number happens to be... ohhhh 32, then you
can also:
tell 32 i love you
and the same thing will happen, and that will be that in less than
a second or so, mary will have displayed upon her screen, in
either case, the following message:
joe tells you:i love you
now, you are an expert in sockets :)
>and why 7?
now, there is a fully loaded shotgun being held by a drunk... :)
the first number you see in the active socket number list displayed
upon the EUServer "window", is the socket number of the server itself.
it's the "default" socket that a new person will connect to when
they initially type "telnet {address/ip} 9000"...
it's like the ringer of the telephone... when someone first dials
your phone number, before you answer it, it rings...
when someone _first_ (that very first tiny fraction of a second)
connects to EUServer, they connect to "belvedere" (pet name of EUServ),
and belvedere makes the 'phone ring'...
then, belvedere assigns them their _own_ unique socket number
from the remaining socket numbers that are available, after
determining that the person connecting is not a 'crank caller',
persay...
it verifies that the person connecting is using the telnet protocol
(an agreed upon "foreign language" like US English is considered
the "universal Earth Language"),
and if they are, they get a socket all to themselves, and if not....
well, unless i'm mistaken, belvedere will grab them like a chew-toy,
shake his head to/fro *really* fast, gnaw upon them a while,
and, since he's usually a rather sharing/friendly pup, will likely
pass them off to Blackdog, our resident sad hound, for Blackdog
to gnaw on and play chew toy with for a while... :>
(hint greg! --wot _would_ actually happen, eh? i'm expecting that
WSockAccept would likely spew chunks if say, someone attempted
to connect to belvedere using like WSFTP on that port... huh?)
now, why o why o why that the first numbered socket that happens
to be given to us when belvedere boots, is _never_ like 0 or 1...
(and it seems to be a different number for each machine btw... on
mine its often 8 or 9, i think greg said his was ... 7 or 8...)
well, that is a question that, with time and much much reading,
i or greg or someone else, might be able to answer *specifically*...
however, i kinda doubt any of us really wants to know, as it'll likely
be completely UNintutive, thoroughly idiotic, and utterly preposterous.
ie: SOP Windoz :)
>And what is this logfile thingie?
the log file is created to review certain important information
about user(s) activities while entering/within/exiting the server.
it's there to help with things like kicking 'bad' people off the
server, and having a record of their name and their originating
IP address if you need to alert some sort of authority, and
log files are often considered admissible in many courts of law.
it's there also to help with debugging the server, both if you
yourself modified the server to have more capabilities and for
ME if you found an as yet undiscovered bug, that wasn't revealed
to me in my alpha testing (and as such, makes you, an official
beta tester every time u so desire and let belvedere out to play) :)
>What should and could I do now?
see above :)
tell your friends, have a big 'talk' party...
read the readthis.txt, *please*...
maybe after that, start the server, login, and type 'help'
to see the list of help topics, and then, read each entry
(like "help tell" or "help channel" or "help chat")
>Actually, when I shut down (manually), I can see that there are
>353 bytes send and 529 bytes received. Where from/to?
there is no simple answer for that, as it could be something
that is loaded (like an email "checker" fetching the count of the
emails waiting for you), or it could just be simple "handshaking"
between your machine and compuserve (which is actually,
basically, nothing really more than a super complex EUserver...
it sends/receives data to/from your machine on a port...).
if you do not telnet into the server, the server does not
send/receive any data upon the port it is monitoring...
furthermore, if the log status is set to it's default, and you
minimize that server window, (or with what ever tool u might
have, add it to the tray) the load on your machine for keeping it
running, with no users (only yourself telnetted in),
is **very** **very!** tiny...
by comparison, having Eudora or Netscape email programs, minimized,
(set to fetch email every 3 minutes and in between that fetching),
and doing 'nothing' with them... just having them 'completely idle'...
they use something like 300 to 3000 TIMES as much of your system...
(or atleast all systems i have been able to test this with, which
is a rather fair amount)...
so, leaving EUServ running, with no users, waiting for people to
enter (which, you would know about if you were logged in as a
sysop or higher level user, and had the "<SERVER>" channel turned on)
is extremely minor...
another way, that takes even less load, because you don't have
to have a telnet client running, is NOT minimizing the server window,
shrinking the width of it a little (its 'extra' wide so that more
active socket numbers will fit better), and tucking it away in
a corner of your screen while watching for -=<{EUserver}>=- to
disappear in that server window...
then, the load on your system is just... nearly unmeasurable
on machines i tried that were pentium class, and just *tiny*
on "highend" 486's...
>Please, if anyone else besides Hawke' has some answers, give them
>to me and probably also to other confused readers.
ouch! =>
are my explanations 'bad'? plz, if they are, i'd actually, really,
like to know...
hopefully, something in this email will help someone :)
take care,
_/ _/ _/_/_/ _/ _/ _/ _/ _/_/_/ _/
_/ _/ _/ _/ _/ _/ _/ _/ _/
_/_/_/ _/_/_/ _/ _/ _/_/ _/_/
_/ _/ _/ _/ _/_/_/ _/ _/ _/
_/ _/ _/ _/ _/_/_/ _/ _/ _/_/_/
({<=----------------------------------------=>})
({<=- http://members.xoom.com/Hawkes_Hovel> -=})
({<=----------------------------------------=>})
16. Re: New encryption thread
- Posted by Hawke' <mdeland at GEOCITIES.COM>
Dec 13, 1998
-
Last edited Dec 14, 1998
isaac wrote:
>If this is how you intend to use it, why do you need encryption at all?
>What do you suspect the attacker has access to?
Davi wrote:
>About the need for passwords: What I was saying is that, even if the
>passwords were stored without any encryption (or with a very weak one),
>the hacker wouldn't have access to them anyway.
let's suppose, and this is *completely* probable...
let's think linux/unix for a moment...
let's pretend that besides being an FTP server machine, that
this machine is doing *other* things...
like, allowing users access to a shell account...
why? okay, let's go further...
I'm helping someone make a MUD, but, i'm sysop level, NOT the owner
of the machine.
I can access any directory of the mud software, as i would need tobe
able to do, to perhaps alter code or areas (buggy areas mebbe?)
so the owner of the machine, like root in linux, would give me
a username and password for the shell account.
so, now we have people that might (depending on how smart the end
'owner' actually is) be able to view a userfile... do i need
to go on or can you see what problems we might have if someone
is 'serving' BOTH a ftp server and a MUD (and mebbe other things)...
the owner will have a need, potentially, to allow other people
into his machine, via a shell perhaps, (NT?) and be safe in
the knowledge that once he sets the serverlog status to
LOG_NORMAL, that he can *walk away* from his machine and
*noone* else can see/view any passwords in any manner.
"but, all they have to do is change the code, the
server_log_status variable and reboot the machine"
try ... again =>
i've done this once or twice before, and i learned the very very hard
way that you make the reboot/shutdown commands IMP LEVEL ONLY,
and the log changing commands IMP LEVEL ONLY...
then you run the process as *ROOT*, and noone, but root, can
"kill -9" that puppy (or whatever command it might be in NT...)
or reboot it...
the only loophole, and i haven't quite determined how i am
going to fix it, and it's why EUServ and a few other things
are 'on hold' sorta, is... this aspect:
"well all they have to do then is edit their userfile
and up their trust level number"
yeah, i know.... once i get the encryption at a fair/high
level, at least where i want it that is... what i think
i'm gonna do is in sysops.seq, i'll hold the names AND
the trust levels (as a double check, and if it don't match,
*bam* that user file is deleted, logged, and your butt is mine)
and i'll encrypt THAT file also... the problem is where
to store the plaintext key for that file.... so the server
itself can decrypt it...
alternatively, i can have a 'master list' of passwords
and sysops all in one file, that is simply not accessible
to anyone but root (in a dir that no one can cd to...)
the bad side to that is that it then becomes the responsibility
of the 'owner' to ensure that his machine is set up properly,
and all the permissions are right and ... wellllll....
i mean, i'm close to having all these 'loopholes' worked out,
in a nice tidy fashion, to where the owner can truly
walk away, with little worry that EUServ/MUD/FTP/etc
won't be crackable, and that means that even if his machine
isn't set up perfectly, it's one less thing a cracker can play with...
isacc wrote:
> Lets assume he has access to the ciphertext, as we did in your example.
> The random seed can easily be narrowed down, mainly through the sumup
> function because the order is insignifigant. The ciphertext we were given
> was 27 characters long, but we know the last one is padding, so 26.
> 26*255 gives us a range of 0-6630, or 6631, possibilities,
ummmmmmmmmmmmmmmmmmmmmmmmmm no.
it would be 255 TO THE POWER OF 26...
255^26...
and actually, since the max length of a password is 20 characters,
it's really 255^20...
if you have 2 character, A and B, and 3 positions (length 3 key),
your possible passwords are:
AAA
AAB
ABA
ABB
BAA
BAB
BBB
that is 2^3, ie: 2 characters with length 3...
if u have 100 characters (ie:32-132, or approx telnet ascii) and
a length 20 key it's 100^20 which is 1e40 possibilities for a
password...
>which shouldn't take too long to try on a computer.
but 1e40, would take... a very very long time... assuming the cracker
got a hold of the cipher text...
>But if I assume the password is within the range of
>typeable&viewable ascii characters, 32-124,
ummmmm u assume kinda wrong there, as the ALT/NUMPAD entry method
will work over telnet...
u can actually have 32-255 for any position in the key
(as of the version that I haven't released yet, cuz
SockTool.InvalidPass()
was cut/pasted from InvalidName and i inadvertenly left a check against
BADNAMECHARS in there... oopsie :))
which then means we have a potential number of passwords of:
224^20 = 1.01e47
(a slightly different number than another post i made, and i
believe this number is more correct...
the other number was calculated using a permutation formula...)
and that is a lot of dratted passwords...
this doesn't count the frustration of not knowing the actual length...
which, as below, naturally, can be determined, with more processor
power...
> function getlen(atom cipherlen,atom seed)
snip
> end function
> The strongest portion of your algorithm is the dynamicaly ranged random
> number generation, but each number in the ciphertext does provide a minimum
> value for the corresponding character in the key.
hrmmmmm that is quite true... since i'm rand(key[i])'ing, we would
indeed
know that at each cipher[i] that the number there had to be AT LEAST
that
big... this is bad... i'll think on it.. :)
(one of the increases i thought of would be using successive
encryption...
applying a value to a value next to it... would this .... ponder...
would that prevent this issue?)
> We can now sift through the combinations, checking the first character
> against the ciphertext and the padding(which repeats) like so:
> function check_first_char(atom keylen, atom seed, sequence ciphertext)
> end function
> This will return a list of possible first characters, giving us a list of
> seed-keylength-firstchar combinations. We can proceed in a similar manner
> through the remainder of the characters.
i.... mostly follow you :) but i think i see where u r headed, and
when applied to 1e47 different possibilities... i dunno...
seems like a big monster machine might be needed...
> Though it could use a bit more work, here's a new version of sumup which
> should increase the overall strength immensly:
> function sumup(sequence data)
> atom sum sum=0
> for i = 1 to length(data) do
> sum = remainder (sum + data[i]*power(4,i-1),power(2,31))
> end for
> return sum
> end function
yeah, i like that... thanks! good stuff...
(makes your head kinda hurt trying to determine how many potential
seed values it generates... :)
> PS From what I understand, any encryption technology is subject to
> examination by the authorities if it has the ability to transfer data in an
> encrypted state, but if the algorythm can only be used to verify a user (as
> in your implementation) and the data sent to that user isn't encrypted, or
> is encrypted by another (legal)algorythm, the verification algorythm may be
> as strong as you like.
oh yeah! first decent news on this issue, clearly defined, that i've
had since i began this headache :)
>Furthermore, there is no specific limit to the bit
>strength of an algorythm for data transfer.
errrrr... ummmm.... now im confused... this seems...
contradictory to the above, as phrased???
>So, if in doubt, you should have it inspected before
>dispersing it internationally.
welllll i suppose i'll have to...
up till now, i believe it's been agreed that v1.64 using encrypt.shr
was no threat to speak of...
but... 1.65 with crypto.e and these mod's from all of the kind
people that replied to this might be huh?? :O
> All of the above is the way it works as I understand it; it is not
> nessesarily the truth.
understood...
> I hope I've been helpful.(though I may have only given you more work to do)
you have... on both counts :)
Davi wrote:
>Sorry if I didn't make myself clear, I was talking about the first
>algorithm you posted, the shrouded one...
oops! ok! yeah, pretty much anything goes for that one huh?
>>whatdaya think? will it work like i think it will?
>I suppose not. There are still only 5100 different seeds, because each of
>the 5100 possible values sent to set_rand will give always the same number.
:/ yer right...
*scurries back to his hovel, plugging in isaac's sumup()*
>>be careful, eh?
>Don't worry, I live in Brazil :)
hrm, does that mean u will have to wait for me to get gov't
approval before u can play with belvedere? :(
could be years ;)
thanks, one and all,
_/ _/ _/_/_/ _/ _/ _/ _/ _/_/_/ _/
_/ _/ _/ _/ _/ _/ _/ _/ _/
_/_/_/ _/_/_/ _/ _/ _/_/ _/_/
_/ _/ _/ _/ _/_/_/ _/ _/ _/
_/ _/ _/ _/ _/_/_/ _/ _/ _/_/_/
({<=----------------------------------------=>})
({<=- http://members.xoom.com/Hawkes_Hovel> -=})
({<=----------------------------------------=>})
17. Re: New encryption thread
From all the info here, I'll make an irritating hard-to-crack algorithm and
offer it through my *dutch* site. This way we can avoid the US' chilidisch
and paranoi export laws, etc.
Ralf
18. Re: New encryption thread
- Posted by Hawke' <mdeland at GEOCITIES.COM>
Dec 13, 1998
-
Last edited Dec 14, 1998
Ralf Nieuwenhuijsen wrote:
>From all the info here, I'll make an irritating hard-to-crack algorithm and
> offer it through my *dutch* site. This way we can avoid the US' chilidisch
> and paranoi export laws, etc.
> Ralf
let's see, if I obtain a proprietary, custom written algorithm
for encryption from outside the US, that was created outside
the US, and is *heavily* notated as being proprietary, custom
written and created outside the US, I'm home free :)
*MOSH*
thanks muchly ralf, you will assuredly get nuzzled by belvedere
for this one ;)
--
_/ _/ _/_/_/ _/ _/ _/ _/ _/_/_/ _/
_/ _/ _/ _/ _/ _/ _/ _/ _/
_/_/_/ _/_/_/ _/ _/ _/_/ _/_/
_/ _/ _/ _/ _/_/_/ _/ _/ _/
_/ _/ _/ _/ _/_/_/ _/ _/ _/_/_/
({<=----------------------------------------=>})
({<=- http://members.xoom.com/Hawkes_Hovel> -=})
({<=----------------------------------------=>})
19. Re: New encryption thread
>let's pretend that besides being an FTP server machine, that
>this machine is doing *other* things...
>like, allowing users access to a shell account...
>why? okay, let's go further...
>I'm helping someone make a MUD, but, i'm sysop level, NOT the owner
>of the machine.
>I can access any directory of the mud software, as i would need tobe
>able to do, to perhaps alter code or areas (buggy areas mebbe?)
>so the owner of the machine, like root in linux, would give me
>a username and password for the shell account.
>
>so, now we have people that might (depending on how smart the end
>'owner' actually is) be able to view a userfile... do i need
>to go on or can you see what problems we might have if someone
>is 'serving' BOTH a ftp server and a MUD (and mebbe other things)...
<rest of explanation snipped>
I understand now, thanks!
>> The strongest portion of your algorithm is the dynamicaly ranged random
>> number generation, but each number in the ciphertext does provide a minimum
>> value for the corresponding character in the key.
>hrmmmmm that is quite true... since i'm rand(key[i])'ing, we would
>indeed
>know that at each cipher[i] that the number there had to be AT LEAST
>that
>big... this is bad... i'll think on it.. :)
This is not true everytime. For example, suppose the plaintext character is
64 (01000000) and the random value based on it is 59 (00111011). Since you
are XORing the values and not subtracting one from another, you will have
value 123 (01111011), that is bigger than the original char.
>(one of the increases i thought of would be using successive
>encryption...
> applying a value to a value next to it... would this .... ponder...
> would that prevent this issue?)
Even if the above is not the reason, this may improve the security anyway.
At least, I suppose it will not weaken it. This should be rather easy to
implement, so I think it's a nice idea.
>> Though it could use a bit more work, here's a new version of sumup which
>> should increase the overall strength immensly:
>> function sumup(sequence data)
>> atom sum sum=0
>> for i = 1 to length(data) do
>> sum = remainder (sum + data[i]*power(4,i-1),power(2,31))
>> end for
>> return sum
>> end function
>yeah, i like that... thanks! good stuff...
>(makes your head kinda hurt trying to determine how many potential
>seed values it generates... :)
It will in theory occupy all the bytes if you use a 13-char
or longer password. The only drawback I see with this is that the
characters in the 17th position and above that will not have any
influence in the seed generated. A solution would be to change
sum = remainder (sum + data[i]*power(4,i-1),power(2,31))
to
sum = remainder (sum + data[i]*power(4,i-1),power(2,31)-1)
You only lose one possible seed (not much loss in strength), and
the problem is solved.
>>>be careful, eh?
>>Don't worry, I live in Brazil :)
>hrm, does that mean u will have to wait for me to get gov't
>approval before u can play with belvedere? :(
>could be years ;)
Well, if the government doesn't think it is too strong (and
it probably isn't, as you're using a 32-bit key), I will be
able to use it. Anyway, if the government decides to bother
you, you can implement a weaker algorithm and distribute
it with the package, and distribute the stronger one
separately, only for U.S. citizens... (but then I won't
be able to see it... oh well)
Talking about using EUServer, I've tried it without success. I
mean, it runs ok, but I can't access it using the telnet program
that came with Win95. I think the problem is with the client,
I've never been able to access any telnet server. I always get a
'Connection failed!' error... does anyone know what can be
happening?
Ralf wrote:
>From all the info here, I'll make an irritating hard-to-crack algorithm and
>offer it through my *dutch* site. This way we can avoid the US' chilidisch
>and paranoi export laws, etc.
Let me just warn you, from what I have read on this subject, it is very
difficult to create a really strong encryption algorithm. Maybe someone
could try implementing one of the well-known and probably very safe hash
functions, like MD5 (maybe, when I have no other project to work on, I will
try it, but I'm not sure yet).
Regards,
Davi Figueiredo
davitf at usa.net
____________________________________________________________________
Get free e-mail and a permanent address at http://www.amexmail.com/?A=1
20. Re: New encryption thread
Hawke' wrote:
>>Please, if anyone else besides Hawke' has some answers, give them
>>to me and probably also to other confused readers.
>ouch! =>
>are my explanations 'bad'? plz, if they are, i'd actually, really,
>like to know...
No, your explanations are very thorough. But you yourself said that other
people, saying the same things in a somewhat different way, could suddenly
shine a whole new light on things. I was referring to your own words, in a
way. But maybe the wording was chosen badly by a non-native English
speaker. Sorry for that.
But, as you said too, I should first RTFM. Maybe that will make me
understand more about the DUNYAbidness.
I feel like I'm sitting in a car for the first time learning how to steer
and propel it, and someone tries too teach me how to fine-tune the engine.
Again, that's not your fault; you assume you are talking to people that
already know how to correctly drive a car and also know some of its
internal workings.
It's more my fault; I put my stick too high, and I invested too little time
in getting a hold of the basics. So, maybe in a week or two you will hear
from me again, or maybe never again.
Thanks for all,
Ad
21. Re: New encryption thread
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Dec 14, 1998
-
Last edited Dec 15, 1998
>Ralf wrote:
>>From all the info here, I'll make an irritating hard-to-crack algorithm
and
>>offer it through my *dutch* site. This way we can avoid the US' chilidisch
>>and paranoi export laws, etc.
>Let me just warn you, from what I have read on this subject, it is very
>difficult to create a really strong encryption algorithm. Maybe someone
>could try implementing one of the well-known and probably very safe hash
>functions, like MD5 (maybe, when I have no other project to work on, I will
>try it, but I'm not sure yet).
Actually, what I need (which is not an encryption algorithm) is a routine
when I give it one 32-bit integer value (and another one representing a part
of the key), it returns an different, yet unique 32-bit integer value. I
mean, it should never return the same values for different inputs (though it
may sometimes return the same values for different keys: also 32-bit integer
values). This is the hard part. This algorithm, however its not an
encryption algorithm at all, its a prohobility (or something: dont mind my
spelling please) algorithm.
This is not an encryption algorithm at all. However, add 10 lines (which I
or any other non-american can do) and we're home free. I'll add a hash
function, that uses that value to divide in an doubled hash-table. (first
time it alters the value of each combination of 4 bytes, the second time I
hash the positions: maybe a different proh..??..ty algoritm here ?) During
the hashing it scrolls through the key-string and uses a different set of
4-bytes each time as the key-integer passed together with the data-integer
to the pro/ algorithm.
Anyways, the pro..tyh algorithms are meat for the math magicians on the
list..
Just post them to the list, or mail them to me. I'll turn it into an
encryption routine. (a simple encode & decode routine).. So again:
function probil (integer key, integer data)
.. some processing here..
.. return a result unique to the data, though not to the key.
.. So, different data-integers with the same key should never ever
return the same value
return my_integer
end function
Any magicians ready to tackle this ?
Ralf
22. Re: New encryption thread
> function probil (integer key, integer data)
> .. some processing here..
> .. return a result unique to the data, though not to the key.
> .. So, different data-integers with the same key should never ever
> return the same value
> return my_integer
> end function
my first thoughts, a rough draft if you will, based upon my
understanding
of what you desire, which, at this point, is not a very strong
understanding as (and, this is *not* anyone's "fault") i'm
having a wee bit of trouble with your phraseology, a cultural,
grammatical, translation difficulty...
i _think_ i know what u want...
for any given X and Y, return Z such that:
for any X, Z may or may not be the same;
however;
for any X *and* Y, Z may never be the same.
with that, my first draft is rather fast to process, easy to
implement, and I believe satisfies the desire.
the caveat and the problem I am having is not knowing
just how large Y might be. If Y is approaching 2^31,
or -2^31, then applying a numerical transformation to
it can become problematic, and may trigger EU to
return an *atom*...
I can get around this with extra processing time, and
since this is likly to be *inside* a loop, I would
like to -avoid- that, like a plague.
A simple algorithm (that may overflow) might be:
func prob(int key, int data)
set_rand(key)
return rand(data) + rand(data)
end func
very fast, clean, neat, and I do not believe that for
any given X & Y, that Z could *ever* be the same.
if you limit data to ~2^15 or less, you have your algorithm.
if we add a check inside the func to prevent overflow, it
will slow this down, and that slowdown may propagate.
const max = power(2,15)
func prob(int key, int data)
set_rand(key)
if (data > max) then
data = floor(data/rand(4))
return rand(data) + rand(data)
end if
if (data < -max) then
data = floor(data/rand(4))
return rand(data) + rand(data)
end if
return rand(data) + rand(data)
end func
this is "more complex" *looking*, but, is short-circuited to
help defeat speed penalties.
the ole' get out while the getting is good...
the largest problem with this algorithm is the use of set_rand,
as, if you have already set the seed, *before*
calling the func prob(), then I destroy that seed,
and since (I WISH!) there is no function that retrieves
the current seed, {no seed = get_rand() command...}
I cannae store the state prior to calling set_rand()...
the next largest problem with the algorithm, is that
it won't work in reverse... ;)
so, we can solve almost all the above with the extremely simple,
(sans the single issue of set_rand) algorithm:
func prob(int k, int d)
set_rand(k)
return xor_bits( rand(d), rand(d) )
end func
this, unless i'm very sadly mistaken, which, so far, in dealing
with topics of crypto, i've been very mistaken, often :)
(hi Ad! see? we aren't so far apart...
trust me, we all go thru growing pains while learning
new 'topics', and I for one, do hope that your final line:
>So, maybe in a week or two you will hear
>from me again, or maybe never again.
comes to pass as the *first* option...
someone once said: Never stop questioning.
)
will *never* produce the same return for different values of d,
(unless d is very small... like 1 or 2... but give it ranges
from ohhhh 100..2^31 and -100..-2^31, and u got no worries)
but would return the same value if k and d were sent to it twice...
and, it will always process in the same amount of ticks...
</endRoughDraft>
thoughts?
_/ _/ _/_/_/ _/ _/ _/ _/ _/_/_/ _/
_/ _/ _/ _/ _/ _/ _/ _/ _/
_/_/_/ _/_/_/ _/ _/ _/_/ _/_/
_/ _/ _/ _/ _/_/_/ _/ _/ _/
_/ _/ _/ _/ _/_/_/ _/ _/ _/_/_/
({<=----------------------------------------=>})
({<=- http://members.xoom.com/Hawkes_Hovel> -=})
({<=----------------------------------------=>})
23. Re: New encryption thread
- Posted by isaac <isaaca at MINDSPRING.COM>
Dec 14, 1998
-
Last edited Dec 15, 1998
>isacc wrote:
>> Lets assume he has access to the ciphertext, as we did in your example.
>> The random seed can easily be narrowed down, mainly through the sumup
>> function because the order is insignifigant. The ciphertext we were given
>> was 27 characters long, but we know the last one is padding, so 26.
>> 26*255 gives us a range of 0-6630, or 6631, possibilities,
>ummmmmmmmmmmmmmmmmmmmmmmmmm no.
>it would be 255 TO THE POWER OF 26...
>255^26...
>and actually, since the max length of a password is 20 characters,
>it's really 255^20...
>
>if you have 2 character, A and B, and 3 positions (length 3 key),
>your possible passwords are:
>AAA
>AAB
>ABA
>ABB
>BAA
>BAB
>BBB
>that is 2^3, ie: 2 characters with length 3...
>if u have 100 characters (ie:32-132, or approx telnet ascii) and
>a length 20 key it's 100^20 which is 1e40 possibilities for a
>password...
You're describing the number of possible keywords, but many of them will
produce the same seed through you're old sumup(). Try this with the
original sumup:
function sumup(sequence data)
integer sum sum = 0
for i = 1 to length(data) do
sum = sum + data[i]
end for
return sum
end function
? sumup("elvenbelvedere")
? sumup("uflbenlewceeer")
? sumup("AAAAAAAAAAAAAAAAAAAAAA2")
Try to find a length 26 or less sequence of numbers between 0 and 255 which
add up to less than 26*255 :)
Good luck; I'm actually working on an algorythm of my own (retreivable
data, not hash) which I may post for public critique.
