|
Forum List • Thread List • Refresh • New Topic • Search • Previous • Next  1  |
 1. Crypt::DES DLL to funcdef#10017 Posted by: mestrini 2007-01-28 00:03:48 Last edited by: mestrini 2007-02-03 07:33:06 (Total edited 1 time) |
Any of you guys knows enough of C to take some source files, compile them in a DLL and find a way to get a REXX script to access them? I'll explain...
I found some DES (encryption algorithm) sources by Eric Young and i really (enphasis in really) need to use the algo to decrypt some binary files.
I'll leave them attached here just in case any of you can do this for me.
TIA |
2. #10046 |
@mestrini
I got CBC mode working properly. I've also changed the definition of the input and output strings for the cbc function from "8u[1024]" to "char[]" and also allow you to define the blocksize to be used - see the demo scripts of cbc encryption and decryption. The "char[]" definition is MUCH faster than "8u[]".
Pete |
3. #10062 |
It's a very long time since I meddled with DES code but the key that you pass to des_key_sched is mangled around into a structure called the key schedule - it makes the subsequent calls to the encryption function go a lot faster since it really only has to do this once for any one key and therefore saves a lot of time if you are then calling the encryption function many times to encipher many blocks of data. So, you must call des_key_sched once to get the key schedule for your key and then you pass the key schedule to the encipher function from then on.
You can ignore set_des_check_key if you don't want the program to do a parity check and weak-key test when you call des_key_sched. In the specs for DES, the key is defined to be 8-bytes long but only seven bits of each byte are actually used as the true key which is therefore 56 bits long. The remaining bit in each byte (the low order bit) is defined to be a parity bit such that the number of one bits in each byte is odd. A strict implementation of DES would require that the key be checked and rejected if it does not have odd parity.
After DES was defined, a small number of keys (about 8) were shown to be cryptographically weak and use of these keys should be avoided.
The tests for parity errors and "weakness" are in the des_key_sched function but it does not do the tests if the variable des_check_key is zero, which it is by default. You'll notice in the test script that several of the keys do not have odd parity (the one that's all zero for example) but the script runs OK because des_check_key is zero.
I added the function set_des_check_key so that you could set or clear des_check_key so that you have control over whether to check a key.
If you call set_des_check_key with a non-zero value then the keys will be checked by des_check_key and if there's a problem it will return an error without creating the key schedule so that you can't use the key to encipher/decipher data.
Pete |
4. #10073 Posted by: mestrini 2007-02-01 09:24:24 Last edited by: mestrini 2007-02-01 09:25:55 (Total edited 1 time) |
Hi,
i've managed to make it work with my script (no errors nor crashes) although the results aren't what i wanted (no 'PASSED')
maybe i'm failing since i'm starting with a dword sum of a 64k binary file which i'm not sure it is correct. Can you verify it for me? The file is attached and the sum is for 0xfff8 bytes (skip the last 4 bytes). My sum is 3D7F2CD2
tx |
5. #10080 |
I get a checksum of FF06C19C.
I don't understand what you are doing with your script though.
Pete |
6. #10085 |
I finnaly decided to install the Crypt::DES module and now i'm able to check my values against the ones from the original perl script. So far the checksum value (using Jeff's routine - improved from mine :D ) is correct; i know i said it was a dword sum but i forgot to say to use little endian order...sorry
I also looked at the perl module and looks like it uses CBC mode instead of ECB, so my next step it to try to use it on my script.
cheers
PS:
As far as installing the perl module try this site: http://theoryx5.uwinnipeg.ca/ppms/
which has online installation via ppm3 or you can download the zip archives and install manually (as i did) |
7. #10095 |
Found it. The definition of the input and output block arguments in the encryption function should also have been changed from str to char[8] because they aren't null-terminated strings either. Good catch Mestrini.
This definition fixes the problem and then your "bad" script also works.
err = FUNCDEF("des_cbc_encrypt",",char[8],char[8] dual,32u,32u[32],8u[8],32",dll,,,"c")
I'll have to go through those definitions again sometime this weekend and make sure there aren't any other problems like that lurking around.
Pete |
8. #10096 |
That's not the real problem. It fixes that specific instance but won't solve the general problem.
The CBC function definition you should be using is the one in the cbc_test scripts:
cbc_blocksize = 1024*128
err = FUNCDEF("des_cbc_encrypt",",char["||cbc_blocksize||"],char["||cbc_blocksize||"] dual,32u,32u[32],8u[8],32",dll,,,"c")
I think you must have used the definition in the mit_dll_test script - I only included that to allow a simple verification that the dll was working. I had to use "str" in that one because the original C test code used a C string for its test. But, in general, when you're encrypting large amounts of data (such as the BMP file in the demo scripts) you have to use the definition shown above. To do a CBC encryption you should use the cbc_test.rex script as a template for your script - and if you need to do CBC decryption make sure you follow the way it is done in cbc_test_dec.rex. In both cases you have to feed a block of data that is CBC_blocksize bytes long in to the function and get the same number of bytes back and loop around doing that until there's no more data.
I should have made it clearer in the docs that mit_dll_test is only a test script and I should have made sure that each of the other scripts had the same version of funcdefs in them. The funcdefs in ecb_test are not the same as those in the cbc demo scripts. I'll modify them over the weekend and upload a newer version.
Pete |
9. #10097 |
Forgot to mention:
In the specific case of your "bad" script use the definition in my previous message but use:
cbc_blocksize = 8
and it will pass the test. You have to choose a block size which suits the particular data you will be using. The very large blocksize I was using was to encrypt/decrypt the logo.bmp file which is 300kb.
Pete |
10. #10098 |
hmmm, i guess one can call it 'lazyness' (or maybe three hours sleep) but i didn't bother to check the other test/tutor scripts inside the zip and assumed they all had same FUNCDEFs
Anyway, i managed to encrypt/decrypt successfully :D but only because i've worked with 8byte strings so far. Once i need to decrypt the whole 64K i believe i must use that improved FUNCDEF.
tx pete |
11. #10100 |
It'll probably be easiest to do 64k all in one go. You might be able to use cbc_test by changing CBC_blocksize to 64*1024 and then just change the input and output filenames. That should work.
Pete |
12. #10101 |
Actually you'll probably use cbc_test_dec since you'll be decrypting.
Pete |
13. #10102 |
I modified cbc_test_dec.rex to read the .fls file you posted earlier, decrypt it with one of the keys you had in the tests you posted and write it as a .dec file (I just picked the extension name at random - doesn't mean anything).
Apart from changing the input and output filenames, all that was required was to change CBC_blocksize to 64*1024 and remove the small block of code which reads a BMP header and writes it out unmodified - you don't want to do that.
Pete |
14. #10107 |
tx for the help pete but i had already done that 1024*64 although it didn't work completely.
The problem is that the file wasn't encrypted all with same key (there are 100 options) and to get some particular info the key must be changed.
As for the bigger blocksize that didn't work when encrypting a 32 bytes string. I had to do a loop to SUBSTR() 8 bytes each loopw=1
DO WHILE w<LENGTH(ARG(1))
[ des code here]
w=w+8
END BTW, have you considered making a documentation for the DES dll and ask Jeff to make it official? Maybe start a series of encryption/security dll conversions? ;)
cheers |
15. #10108 |
If you are encrypting/decrypting 8 bytes at a time and using an iv of zero for each one, then CBC is exactly the same as ECB mode.
If Jeff wants to add the DES dll to the Reginald site I can tidy it up. But I'm afraid I'm not in a position to support it on a longterm basis nor to develop any other encryption stuff - I happened to have had experience with DES from a long time ago and you just happened to ask for a DES dll at the right time :-)
Pete |
16. Re: #10109 |
If you are encrypting/decrypting 8 bytes at a time and using an iv of zero for each one, then CBC is exactly the same as ECB mode.
Not exactly since the zeroed IV is only for first 8bytes; after that it uses:
If Jeff wants to add the DES dll to the Reginald site I can tidy it up. But I'm afraid I'm not in a position to support it on a longterm basis nor to develop any other encryption stuff - I happened to have had experience with DES from a long time ago and you just happened to ask for a DES dll at the right time :-)
Pete
Hoho, lucky for me then. I thought you were dll experienced and not DES experience.
Anyway it's a pity you can't develop other encryption algos. I just hope you happen to have experience in anything i may come to need at some point, hehe
tx once again |
| Forum List • Thread List • Refresh • New Topic • Search • Previous • Next 1 |
搜索
论坛
Home
回顶部
g.yi.org Hits:0
