1. New encryption thread
- Posted by Hawke' <mdeland at GEOCITIES.COM> Dec 12, 1998
- 392 views
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
- Posted by Ad Rienks <Ad_Rienks at COMPUSERVE.COM> Dec 12, 1998
- 374 views
Question: Is encryption really needed? Are you sending top secret military espionage facts, or verry perrsonal inforrmation? 491024418?
3. Re: New encryption thread
- Posted by Hawke' <mdeland at GEOCITIES.COM> Dec 12, 1998
- 361 views
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
- Posted by Ad Rienks <Ad_Rienks at COMPUSERVE.COM> Dec 12, 1998
- 364 views
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
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL> Dec 13, 1998
- 363 views
. >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
- Posted by Hawke' <mdeland at GEOCITIES.COM> Dec 12, 1998
- 366 views
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
- 396 views
- 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
- 367 views
- 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
- 387 views
- 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
- Posted by Davi Figueiredo <davitf at USA.NET> Dec 13, 1998
- 360 views
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
- Posted by Hawke' <mdeland at GEOCITIES.COM> Dec 13, 1998
- 382 views
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
- 378 views
- 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
- 375 views
- 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
- 366 views
- 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
- 367 views
- 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
- 379 views
- 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
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL> Dec 14, 1998
- 374 views
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
- 366 views
- 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
- Posted by Davi Figueiredo <davitf at USA.NET> Dec 14, 1998
- 388 views
>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
- Posted by Ad Rienks <Ad_Rienks at COMPUSERVE.COM> Dec 14, 1998
- 367 views
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
- 523 views
- 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
- Posted by Hawke' <mdeland at GEOCITIES.COM> Dec 14, 1998
- 371 views
> 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
- 368 views
- 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.