|
|
| Tool name : |
RC4Encryption 0.1 |
| |
| Description : |
RC4Encryption is a tool to encrypt and decrypt files with the RC4 algorithm. The tool itself is not really hot stuff. OpenSSL supports RC4 since years and also many other algorithms. But you can use this code without any dependency of an additional library and you have working functions of stream cipher encryption.
|
| |
| Tested on : |
Windows XP |
| |
| Feedback : |
In case you encounter any problems with the tool, you have suggestions to improve it, or you tested it with a Windows version i’ve not yet tested please drop me an email. |
| |
| Downloads : |
Binary | Source |
| |
| Screen shots : |
|
tags: Crypto, Encryption, RC4, Sources, Tools
you code seems broken …
This may sound a bit arrogant (sorry for it in advance). But what happens if you take 2 Files A,B with lenght(A) > length(B) and I know the plaintext of A and the ciphertexts of A and B … then I think its possible the recover the plaintext of B as follows:
plainB[i] = B[i] xor A[i] xor plainA[i]
maybe I am completly misstaken … I will implement it tomorrow (dont have a windows box at hand).
-Zeri
@zeri: This is a well known attack on symmetric stream ciphers like RC4. Look up “stream cipher”, and “known plaintext attack.
PS. It’s a bit disingenuos to say that people can “use this code without any dependency of an additional library”. RC4 is extremely simple (it is literally only a few lines of code), and is available in “stand alone” form in every conceivable language, all over the web!
@tc: the problem is, that normaly you deploy initialisationvectors in order to prevent that kind of attak. In case of rc4 you could simply concat some random bytes with the key and place these n-bytes in front of the ciphertext …. as long as you dont use the same iv twice with the same key there is no way to recover the key from simply knowing the plaintext of one of the files.
-Zeri
PS: thank you for the information, but I was allready aware of the meaning of known plaintext attacks ^^ thats why I wrote a comment in the first time.
of course I dint mean to recover the key but a “defacto key” (keystream)
-Zeri
@Zeri: I’m not sure what you’re trying to say now.
You originally said (and I quote):
“you[r] code seems broken … [if] I know the plaintext of A and the ciphertexts of A and B … then I think its possible the recover the plaintext of B”
That comment clearly showed, that you did not understand stream ciphers. What you said, is true of MANY, if not ALL, stream ciphers. His code is not “broken” in any way, shape or form.
can someone show the example of source code of user and Kernel level API unhooking function?