Re: final php versions of fwPack and fwUnpack
On Wednesday, March 3, 2004, at 07:18 PM, Richard Gaskin wrote: For example, we hear about 128-bit encryption, but I couldn't find a primer dumbed-down enough to explain what that means in lay terms. I need to see what controls there are for the "MDX" algorithm's passwords length before I can determine the bit level. Doesn't enforcing password length get into the public key/private key setup? Not an issue with the "MDX" algorithm. It looks like you can have as long of a password as you want with this. That just adds to the strength the longer it is. Is there a way to provide stronger encryption with the simplicity of a single password? Yes. I just added CBC and 16 random initialization vectors to the "MDX" algorithm. Your description on cypher block chaining was excellent -- thank you. Thank you for the excellent post. I learned more reading your one-pager than in an hour of prowling the 'Net. -- Richard Gaskin Here is more from the beach and I'll send the example as an attachment on to you: -- all in all, this "MDX" algorithm is very interesting. -- encrypt local cbcVecText put md5digest(pPassword) into tKeyString put len(tKeyString) into tKeyStringLen -- new for CBC -- adds 16 random chars to pad the front of pData put"a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z,1,2,3,4,5,6,7,8, 9,0" into xBx put "" into zink repeat with i = 1 to 16 put random(36) into dipc put item dipc of xBx after zink end repeat put zink & pData into pData new for CBC -- Apply it with Xor to the data one byte at a time: put 0 into i put empty into tCryptoText --- new --- put "a" into cbcVecText --- new --- repeat for each char k in pData add 1 to i if i > tKeyStringLen then put 1 into i put char i of tKeyString into tKeyChar --- new --- put numtochar( chartonum(k) bitxor chartonum(tKeyChar)) into bCrypt put numtochar( chartonum(cbcVecText) bitxor chartonum(bCrypt)) after tCryptoText put bCrypt into cbcVecText --- new --- end repeat -- decrypt local cbcVecText put md5digest(pPassword) into tKeyString put len(tKeyString) into tKeyStringLen -- -- Apply it with Xor to the data one byte at a time: put 0 into i put empty into tClearText --- new --- put "a" into cbcVecText --- new --- repeat for each char k in pData add 1 to i if i > tKeyStringLen then put 1 into i put char i of tKeyString into tKeyChar --- new --- put numtochar( chartonum(cbcVecText) bitxor chartonum(k)) into bCrypt put bCrypt into cbcVecText put numtochar( chartonum(cbcVecText) bitxor chartonum(tKeyChar)) after tClearText --- new --- end repeat put tClearText into pData --- new --- -- delete char 1 to 16 of pData at some point --- new --- Hope you like this, Mark ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: final php versions of fwPack and fwUnpack
On Tuesday, March 2, 2004, at 09:07 AM, Richard Gaskin wrote: As I mentioned in the article, I'm pretty ignorant on encryption, esp. compared to seasoned cryptohobbyists like Mark Brownell. So here's a question I can't answer about my own code: If one were to try to characterize the relative strength of the "MDX" algorithm used in fwPack/fwUnpack, what phrase would be appropriate? This is just too juicy to pass up. How about "Don't forget to drink your chocolate flavored Ovaltene." For example, we hear about 128-bit encryption, but I couldn't find a primer dumbed-down enough to explain what that means in lay terms. I need to see what controls there are for the "MDX" algorithm's passwords length before I can determine the bit level. In other words I just started looking at it. Blowfish uses more than 500 iterations of changes on two 32 bit blocks at a time sending them left and right through each other. Blowfish is a 64 bit block-cypher. One very important recommendation while using powerful block-cyphers is in not doing so in a way that all you end up getting is a fixed code book kind of result. This fixed code book type is referred to as EBC, Electronic Code Book. One way to avoid creating a fixed code book is to use the first 32 bit word to XOR the next 32 bit word then use the second 32 bit XORed word to XOR the third 32 bit word. This alone would still be a weaker form of encryption. What can really change things is to either pass eight unrelated secret characters to XOR the first eight characters or to pad the text to be encrypted with eight randomly generated characters first. When decoding takes place the additional characters can be removed before viewing the text. This is known as CBC, Cypher Block Chaining. If you add eight randomly chosen characters & CBC to your MDX, then it will be much harder to crack your 32 bit (I guess) encryption level. I need to look at it closer. It looks like you are XORing one char at a time. This would make it an 8 bit block cypher. Here is how Blowfish increases encryption levels. If a user uses 32 bit level then four characters are used over and aver to encrypt with. Other levels are 64 bit uses 8 charaters, and 128 bit uses 16 characters. All example keys for Blowfish are 56 characters long. Example 32 bit 56 char key: abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd Example 64 bit 56 char key: abcdefghabcdefghabcdefghabcdefghabcdefghabcdefghabcdefgh Example 128 bit 56 char key: abcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefgh Also, how easy would it be to crack MDX? -- Richard Gaskin If a programer had the MDX algorithm then a brute force attack would take about one minute to one hour. The 54 bit encryption level was cracked by a brute force attack using several computers in a long weekend. The trick is to just try every possible access key, eventually you get the one that works. If your access key is only four characters then there are only 256*256*256*256 (4,294,967,296) possible keys. If your algorithm restricts characters to the first 128 ascii characters then there are only 128*128*128*128 (68,435,456) possible keys. (This is assuming a four char key that I saw on the list as an example.) So one way to stop the practicality of brute force attacks is to deliberately put a one second delay on processing the algorithm. If your application or CGI has a password input point then this one second delay will make a brute force attack difficult. 100,000,000 brute force attempts with a one second delay would take more than three to four years on a single computer. It would take 1000 computers hitting your CGI continuously to get past half of the possibilities in a single day or two. I doubt if that is even possible. more later... i'm out RVing Mark ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: final php versions of fwPack and fwUnpack
> Many, many thanks to shaosean and Brian Yennie for providing php > versions of fwPack and fwUnpack. I cleaned them up a bit, added some > error handling, and tested the final code. error handling?! you make mistakes?!! ;-) ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: final php versions of fwPack and fwUnpack
Frank Leahy wrote: Many, many thanks to shaosean and Brian Yennie for providing php versions of fwPack and fwUnpack. I cleaned them up a bit, added some error handling, and tested the final code. I've put the final code up on my server at http://photoalbum.backtalk.com/code_snippets/fwPack_fwUnpack.php.txt Richard, maybe you'd like to add this code to your fwPack/fwUnpack stack? Wow - it's a red-letter day for Franks: I just had a post from a fella named Frank in my support forum who made a tutorial for my WebMerge product. I have to admit being surprised by the interest fwPack/fwUnpack has gotten. As a simple "secret decoder ring" I wrote it for a specific need and it's been gratifying that others have found it useful as well. As I mentioned in the article, I'm pretty ignorant on encryption, esp. compared to seasoned cryptohobbyists like Mark Brownell. So here's a question I can't answer about my own code: If one were to try to characterize the relative strength of the "MDX" algorithm used in fwPack/fwUnpack, what phrase would be appropriate? For example, we hear about 128-bit encryption, but I couldn't find a primer dumbed-down enough to explain what that means in lay terms. Also, how easy would it be to crack MDX? -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: final php versions of fwPack and fwUnpack
Many thanks to you too, Frank ! Your ".php" issue is stored there for future use. Best Regards, Pierre Le 2 mars 04, à 16:40, Frank Leahy a écrit : Many, many thanks to shaosean and Brian Yennie for providing php versions of fwPack and fwUnpack. I cleaned them up a bit, added some error handling, and tested the final code. I've put the final code up on my server at http://photoalbum.backtalk.com/code_snippets/fwPack_fwUnpack.php.txt Richard, maybe you'd like to add this code to your fwPack/fwUnpack stack? Thanks, -- Frank Weblog: http://cornwall.backtalk.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution -- Bien cordialement, Pierre Sahores 100, rue de Paris F - 77140 Nemours [EMAIL PROTECTED] GSM: +33 6 03 95 77 70 Pro: +33 1 41 60 52 68 Dom:+33 1 64 45 05 33 Fax: +33 1 64 45 05 33 Inspection académique de Seine-Saint-Denis Applications et SGBD ACID SQL (WEB et PGI) Penser et produire "delta de productivité" ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
final php versions of fwPack and fwUnpack
Many, many thanks to shaosean and Brian Yennie for providing php versions of fwPack and fwUnpack. I cleaned them up a bit, added some error handling, and tested the final code. I've put the final code up on my server at http://photoalbum.backtalk.com/code_snippets/fwPack_fwUnpack.php.txt Richard, maybe you'd like to add this code to your fwPack/fwUnpack stack? Thanks, -- Frank Weblog: http://cornwall.backtalk.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
