hi @all :bg
I have ask to file encryption/decryption.
I would like bind into my program a file encryption/decryption
which am there better sha-256 or md5?
or is there which better?
greets
ragdog
Those are hash algorithms actually, used for integrity checks, and others things, and you shouldn't be able to decrypt them :) As far as security goes sha256 is a powerhouse, I actually do have it implemented in MASM, have to ask the author permission to upload it. Also Md5 isn't thought to be as secure as it use to be http://slashdot.org/articles/04/08/17/0030243.shtml. For encryption though I recommend Rc4 or AES. Both are blazing fast, and highly secure. I've used Rc4 a lot for per byte encryption, rc6 is out aswell which was the AES canidate, but it uses 16 byte blocks which kind of annoys me. Heres a rc4 implementation written by "iCeBurg". I did get his permission to post it.
.data?
rc4keytable db 256 dup (?)
.code
Rc4_setkey proc Pass:DWORD, LenPass:DWORD
pushad
mov eax, 0FFFEFDFCh
mov ecx, 256/4
Init_rc4keytable:
mov dword ptr [rc4keytable+4*ecx-4], eax
sub eax, 04040404h
dec ecx
jnz Init_rc4keytable
xor eax, eax
mov edi, Pass
Key_return:
xor ebx, ebx
mov esi ,LenPass
jmp New_key
Key_loop:
inc bl
dec esi
jz Key_return
New_key:
mov dl, byte ptr [rc4keytable+ecx]
add al, byte ptr [edi+ebx]
add al, dl
mov dh, byte ptr [rc4keytable+eax]
mov byte ptr [rc4keytable+ecx], dh
mov byte ptr [rc4keytable+eax], dl
inc cl
jnz Key_loop
popad
ret
Rc4_setkey endp
Rc4_crypt proc iData:DWORD, LenData:DWORD
pushad
mov edi, LenData
mov esi, iData
test edi, edi
jz Rc4_enc_exit
xor eax, eax
xor edx, edx
xor ecx, ecx
xor ebx, ebx
Rc4_enc_loop:
inc bl
mov dl, byte ptr [rc4keytable+ebx]
add al, dl
mov cl, byte ptr [rc4keytable+eax]
mov byte ptr [rc4keytable+ebx], cl
mov byte ptr [rc4keytable+eax], dl
add cl, dl
mov cl, byte ptr [rc4keytable+ecx]
xor byte ptr [esi], cl
inc esi
dec edi
jnz Rc4_enc_loop
xor eax, eax
mov edi, offset rc4keytable
mov ecx, 256/4
cld
rep stosd
Rc4_enc_exit:
popad
ret
Rc4_crypt endp
;example
comment !
invoke lstrlen,addr password
invoke Rc4_setkey,addr password,eax
invoke lstrlen,addr data
invoke Rc4_crypt,Addr data,eax
!
Great thing about this is like I said its per byte encryption, and writes the encrypted data back into its source instead of an external buffer. So for text strings be sure to add /SECTION:.text,RWX to your linker section.
thanks for the information :U
do I know also my file again decypt with this rc4 algo?
have you a aes-256 algo
Yes to decrypt run through again just like you encrypted with same key, I do have aes aswell but I have to get permission from the author.
ok i make a test thanks :U
have you more crypto algos or can me send links
to E^cube
help with this algo i can not decrypt my text with same password
:'(
ragdog
my source is posted
[attachment deleted by admin]
I found xTea in asm last night. Have not have time yet to add code to it to see it run. Should be easy to do so. Hope it help.
Btw: what do you guys think about xTea. I got an understanding that Tea is weak but xTea is very strong. Is this a fact? What do it take to crack it and how many days or years would it take? What is the recommended key size to make it IMPOSSIBLE to crack?
[attachment deleted by admin]
tea was / is? brutable, i remember safedisc used it on their protection (still do actually)
bruteforcing it can take a while but 128 bit key took at worst a few hours to break...
so xtea might suffer from the same weakness....
thanks all :U
well someone can help me with a good encrypt and decrypt algo?
or can me post examples
greets in forward
ragdog
ragdog,
The attached project is a reasonably secure method using a progressive encryptor that employs a key that can be up to 256 bytes (2048 bits) wide. I use it whenever I need to transfer sensitive data over the Internet. Nothing is uncrackable, but this will keep most people out.
Paul
[attachment deleted by admin]
Paul,
Nice demo and works well. I could be tempted to "borrow" this one if its OK with you. I need a pair of algos that will seriously mess up a body of text so nothing can be recognised with it to then pass it through a one pass pad and this looks fast, lean and powerful enough.
Hutch,
As always, you are welcome to anything I own. Enjoy.
Paul
ragdog put a
invoke lstrlen,addr pass
invoke Rc4_setkey ,addr pass, eax
before every Rc4_crypt call
Cube,
I have tested RC4 after making the change you recommended. It is not a very good encryptor and I would not recommend that anyone use it. I used 'This is a test' as input and only the first half was encrypted. 'a test' remains unencrypted. I am attaching the project I used for testing.
Paul
[attachment deleted by admin]
PBrennick i'm going to have to disagree, Rc4 is actually one of the most secure algs in the world, and it's extremely fast
invoke lstrlen,hInput
invoke lstrlen, addr szPassWord
invoke Rc4_setkey, addr szPassWord, eax
invoke Rc4_crypt,hInput,eax
do you see how you messed up here? Simple mistake but you're providing an improper data length for Rc4_crypt
invoke lstrlen, addr szPassWord
invoke Rc4_setkey, addr szPassWord, eax
invoke lstrlen,hInput
invoke Rc4_crypt,hInput,eax
Yeah that didn't fix it, well I don't have time to debug his code but heres 3 examples showing rc4 is a very good encryptor, I show 2 file en/decryption examples and a string example.
[attachment deleted by admin]
I am not going to dignify your flaming me for a program I did not write with a response. You should consider how you talk to people.
Paul
Well if there was ever an easy way to settle this discussion, here it is. Here you have source for the Advanced Encryption Standard (AKA Rijndael) in MASM syntax. This algorithm is virtually the undisputed champion of encryption. Unfortunately it doesn't come with any documentation, but after looking at the source myself, it doesn't look too horrible. The credits to the author are inside the attachment (his handle is witeg), but if anyone creates a nice example using this source, I'm sure we would all appreciate a look-see.
Hope this helps, Ehtyar.
[attachment deleted by admin]
Well I read your PM PBrennick and I must say I don't appreciate it, I understand your status in the community, but I still think you were way out of line. I didn't "flame" you, the Rc4 implementation isn't broken in any way, it works very well, and if you can't get it to work I apologize but I provided 3 examples. Ehtyar Rijndael is indeed a nice encryption algorithm, Rc6 was a candiate for AES aswell, but Rijndael had a few areas where it excelled over Rc6. Why I enjoy Rc4 so much though is for a couple of reasons
1)Implementation is very small
2)It's very fast
3)Very flexible
Rc4 is a fantastic stream cipher, AES and others only read in specific sized data blocks, whether it be 16 bytes at a time or whatever the case. Also some require key lengths of specific sizes, which again I don't like. And even some also require external buffers to put the encrypted/decrypted data in, Rc4 doesn't require any of that, key and data lengths can be any size and no external buffer is needed. I think that's why Rc4 is used in SSL, wep and many other protocols.
E^cube, you yourself recommended Rijndael in your original post. I suppose the cipher of choice depends on the use. Since we are still in the dark about what ragdog wishes to use this cipher on, we can't make a sound suggestion. I posted the Rijndael source mostly to end the debate about rc4, as Rijndael is in fact THE most secure algorithm available in current times. Hopefully it will help someone.
Ehtyar.
[edit]
E^cube, you might also consider reading this article (http://en.wikipedia.org/wiki/RC4#Security). Of particular note is this line:
Quote from: Wikipedia
RC4 falls short of the standards set by cryptographers for a secure cipher in several ways, and thus is not recommended for use in new applications.
[/edit]
You mean to tell me after all of these years I and many other follower of asm have been searching the world for those encryption algs in ASM posted here and now someone REMOVED them.
I get 404 - Attachment Not Found. What is the problem?
It took me forever to find Tea in ASM digging through tons of leads and doc...
Where are these files...
PS: Pbrennick, E^cube didn't even crack on you not even a litte bit... How nice can this be. I would have been raving mad behind your comment and would not been afraid to let you know it .
Not having time to go into details about a disagreement is respect. We all got a lot of respect for you, so don't go overboard like so many other have done and still doing. We all got problem and you don't need any more either, so take it easy Pbrennick and slip E^cube and apology and be done with it .
btw: If these file were removed because you got pis-off ... than you really got a fight on your hands .. :)
Guys,
Lets not turn this into an argument, there is too much useful stuff being mentioned for it to be wasted.
I can't seem to reattach AES. Seems to be a bug in the board..filesize() failed apparently, why it is being called before a file upload is anyone's guess. Anyway, in the meantime i have it on my shell here (http://repetitious.digitalshell.net/~Ehtyar/download.php?AES_Rijndael.zip).
Hope it helps you guys, Ehtyar.
ic2,
Relax, no one is removing files. As for 'me' removing files because I might be pissed off (which I am not), I do not have the ability to do that as I am not a Global Moderator. I would never do that anyway.
Let's just continue the crypto discussions. Rjindael is in line to be the encryptor of the future, a change after 24 years was bound to happen, anyhow. WinZip now uses this algo in their software. I read that an encrypted file using AES was broken, but it took 22 hours using an unbelievable amount of computers making this an incredibly secure standard. IMO, of course. I respect the opinions of others.
Paul
ic2,
Paul is right, only Global Moderators are allowed to remove files breaking the forum rules. Paul is trying to help you so there is no need for you to attack anyone.
In case anyone missed it, I posted an explanation that I messed up a directory permission and set it too strict for read or write so file downloads were disabled.
Hello Vortex,
I would never bit the hand that feed my brain if i unless i was force to. :(
If a Moderator use the word flame, that mean that someone broke the rules and could leave a mark on that member including some hurt and angry feeling all because of an mis-understanding. If you read my comment between the lines you see it all about telling BOTH parties to take it easy and make up soon as possible .. . Not to jump in to start another fight.QuoteIf these file were removed because you got pis-off ... than you really got a fight on your hands .. :)
THAT's was A JOKE... did you notice the smile.
I know the rules. I actually thought the forum got hacked but did not want to mention it because i did not want to jinks it bake up. I guest we all got to stop being so sensitive. Let's move on...
What do you guys think about blowfish as a 2nd or 3rd encryption on top of the best encryption ...
http://en.wikipedia.org/wiki/Blowfish_(cipher)
See Attachment:
QuoteBest public cryptanalysis:
Four rounds of Blowfish are susceptible to a second-order differential attack (Rijmen, 1997); for a class of weak keys, 14 rounds of Blowfish can be distinguished from a pseudorandom permutation (Vaudenay, 1996).
QuoteIn cryptography, Blowfish is a keyed, symmetric block cipher, designed in 1993 by Bruce Schneier and included in a large number of cipher suites and encryption products. While no effective cryptanalysis of Blowfish has been found to date, more attention is now given to block ciphers with a larger block size, such as AES or Twofish.....
[attachment deleted by admin]
ic2,
As far as Blowfish goes; it is my opinion that it does a nice and reliable job. The thing I like about Blowfish is that it is a Block Cypher. Block Cyphers, in my opinion, always lead the crowd.
Paul
Hi all :)
In order to keep Paul happy (jokes) here are the only other stream ciphers i could find asm source for.
Here is some info for each:
WG - Presented as a 22-cycle stream cypher to ECRYPT (European Network of Excellence for Cryptology) but was found vulnerable at 22 cycles, and is now recommended to be used at 88 cycles. There appears to be no cryptanalysis whatsoever on an 88 cycle WG implementation as the prior weakness invalidates this entry from ECRYPT.
VMCP - Designed specifically as a replacement for RC4, this algorithm was first presented to FSE (Fast Software Encryption Conference) in 2004, and cryptanalysis of the algorithm determined it was vulnerable to the same distinguishing attacks as RC4, though this type of attack does not directly compromise the encrypted data. It is therefore considered secure, as this is the only known attack effective against this algorithm.
PC1 - A cipher that produces identical output to that of RC4, and employs the same encrypt-again-to-get-plaintext operation as RC4. It is therefore just as weak/secure as RC4 and is simply implemented slightly different. I have not found any reasoning for the re-design of RC4 into this cipher.
NOTE: This information is based on about 30 minutes of reseach this morning, therefore i could conceivably be wrong about any of this.
Hope this helps, Ehtyar.
[attachment deleted by admin]
Its not that I need it much these days but I have a formula if you really and truly MUST pass encrypted data that is highly secure to someone else. The couple of algos in the masm32 library are designed to be run with unique large keys and they produce what is usually called a one pass or one shot pad. The action is not in the algos which are trivial but in the quality of the random pad that is used in conjunction with the data.
Historically these have been the most secure but least easy to use but there is a simple enough trick to solve its one known problem of the occasional bit of plain text showing through, pass the data through another encryption algorithm that seriously messes up the byte order so there is no chance of any plain text showing through then run the data through a high quality random pad and you will produce encrypted data that will break a supercomputer.
I am in debt to JIBZ for some useful analysis on pad reuse, the more times a pad is used, the weaker it gets and someone with enough knowhow and computer grunt can break a repeatedly used pad. There is a solution to the need for very good quality unique pads, create a massive random pad triggered from external real world and write it to a CD. Send it to the data recipient by a physically secured method and for each message send between the two parties, use a different offset in the massive pad to ensure that each pad is unique and you should be able to keep them guesing until the year 3000. :bg
I have this bias against conventional encryption methods that use variable length keys in that they are all vulnerable to massive computer grunt testing randomly generated input keys. This week its a 128 bit key, next week it will be a 192 bit key, next year it will be a 1024 bit key etc .... but any encryption method that depends on key complexity it a target for dedicated computer cracking when enough computer grunt is put in place.
Unique pad technology does not sufer this problem.
I've done the huge dataset of random data before, but you can also downloaded several books instead of using random data. There is a book project to scan in books. I don't have the link in front of me. But there is a website with a large number of scanned in books you can download. Does anyone know what I am referring to and have a link available? I'll have to re-dig it up.
Mark, i believe you are referring to The Gutenberg Project (http://www.gutenberg.org/), though last i checked they have a very limited variety of technical books.
Also, you can check out Agner Fog's page on pseudo-random number generation here (http://www.agner.org/random/).
Hope this helps, Ehtyar.
Quote from: Ehtyar on December 26, 2006, 04:31:01 AM
Mark, i believe you are referring to The Gutenberg Project (http://www.gutenberg.org/), though last i checked they have a very limited variety of technical books.
Ehtyar.
Thanks Ehtyar! :) I was having a brain fart last night when I was trying to remember the name. It doesn't matter if the books are technical. I downloaded a large number of books at random, and removed all the spaces to make it better as a key.
Oooooooooooooh, i see what you mean :) Very clever :U
Ehtyar.
The thing to remember here is that a pad IS a key, albeit a very large one.
Lotus Notes has made good use of this method of sending keys (pads) for years.
Paul
What would be the recommended minimum and maximum key size for a 500k file to reach the security level that hutch is speaking of?
And which algos in the m32Lib should I use. I think these are the three: roldata.asm, rordata.asm and xordata.asm. Are there more?
ic2,
The source length or longer with the pad being encryption standard random data.
standard random data meaning any kind of plain text with no spaces as Mark_Larson indicated and at any size as long as it the size of the source or larger. I think I get it now.
Thanks hutch
I don't thoink you got the idea exactly. Encryption standard random data is somewhat more complex than pseudo random data from random generators. It almost exclusively has an external real world source, radioactive decay, sub-sonic radio noise from the universe etc ..... You can write software where you create the seed random pad with a mouse where you drag it around a pad in an uneven manner but the random data must be truly unpredictable in its source otherwise it is trivial to duplicate it.
The idea that Mark has is OK but its short of being powerful enough for serious encryption of data that must be secured. By using plain text, the vast majority of it is lower case so you reduce the deviation range from 256 to 26 which drastically reduces the complexity of the pad.
I have heard of people using TIF files to do this. Scan your favorite picture and you have a block of data!
Paul
Why not use the Microsoft Cryptography functions?
http://msdn2.microsoft.com/en-us/library/aa380252.aspx
http://msdn2.microsoft.com/en-us/library/aa379942.aspx
Quote from: PBrennick on December 27, 2006, 02:57:58 PM
I have heard of people using TIF files to do this. Scan your favorite picture and you have a block of data!
Paul
It sounds like it should be a neat idea, but most pictures may have large uniform areas of flattish background colour where the repeating colour data will be very regular indeed, certainly worse than Mark's text method. I just opened one of my own TIF image files and there are many areas that don't look at all random to me and a large repeating section of mostly zeroes close to the end that I presume is some sort of padding.
I think for a TIF to be seriously usable in this way it would have to be of a very complex subject with much high-contrast (both colour and shade) fine detail all over, close to the pixel level. This doesn't sound like most "favourite" photos, sadly.
IanB
Ian,
Yes, that is correct, but remember that the algorythm will not return a string of constant values in the same manner. For example, I created a file with 256 zeroes in it and encrypted it using my program with my private key and this is what I get...
æqS!ÖœÍ%JJ"‡åŸ?ªÎnèJTÚKÚ`×+ÑÁ«öPñ£Ä¸ 2@ç?§=L¬ .?¼åÝ»ºLƒ•:™Ý^³gx"0à¥^tÌ‡Ò 0_ÄUî–Ê çžl˲G?_ÌEX°XÒ¾&AŒN\±5¯¤IdDÙVôaý»êGÞ¸PA
ĪV ü Í™¬ijp'?VŒESÖet2&9úcê¦i£¸...koëM T®F†s{:Œsæ}Mvwvt¦"ˆl´7Þ+(‰€·ôxÁÇv1
%8>] s@–2:É$aH?Cy"šö¤è±/9? g¸^çÄ<GDyÙè
So appearances can be deceiving.
Michael,
That is a GREAT link. I did not know that advapi.lib contained that stuff and it is even in the windows API help file. I searched, and found, CryptEncrypt and CryptDecrypt. I need to play in this area some more!
Thanx,
Paul
Just a small thought... The objection to Mark's massive text pad was the limited range of the data, therefore the easy way to remedy this is to "spread" the range to cover a whole set of byte values. Since the most common range of text characters in books will be the lower-case ASCII chars, which occupy 1/8 of the ASCII range, and as noted there will be ranges simply not covered at all, such as 0-33 and 127-255, just multiply the pad value by 8 to fit to the full byte range (ADD/ADD/ADD ignoring overflows), then add a variable offset to fill in the seven char gaps between the new values, say the number of pad characters since the last "e". That should give a fairly full coverage of byte values. I leave it to others to decide whether that is sufficiently random for the purpose.
IanB
Before you will use any block cipher for file encryption i would suggest you reading this wiki article (http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation).
If you will choose RC4 follow this link (http://www.wisdom.weizmann.ac.il/~itsik/RC4/rc4.html).. just to be warned :wink
-
According to the first question : SHA256 is much better choise than MD5.
PS.
QuoteHeres a rc4 implementation written by "iCeBurg"
This RC4/aRC4 implementation was written by me, not iCeBurg. You can find it on my site.
Just to add to the rather interesting discussion on random number hee 's a little something i found ages ago in phrack...
http://phrack.org/archives/59/p59-0x18 thought it might be of interest depending on how involved you wanna get