I am trying to decrypt programmatically encrypted file using OpenSSL. OpenSSL was used to encrypt the file and I know both the function and the key that was used:
//This declaration is just figurative
const char keybuf = "12345678";
// Prepare the key for use with DES_cfb64_encrypt
DES_cblock key2;
DES_key_schedule schedule;
// keybuf is the string key used as password
memcpy(key2, keybuf, 8);
DES_set_odd_parity(&key2);
DES_set_key_checked(&key2, &schedule);
int n = 0;
DES_cfb64_encrypt( ..., ..., length, &schedule, &key2, &n, DES_ENCRYPT );
First I converted the file to binary from base64 (which is how it's packed):
cat data.b64 | base64 --decode > data.cr
Now when I run command line on encrypted data (assuming des-cfb is algorighm I need):
openssl enc -d -des-cfb -in data.cr -out data.decr -k 12345678
this is what I get:
bad magic number
So what I'm doing wrong here? Maybe I converted the file wrongly from base64?
Which openssl command is equivalent to DES_cfb64_encrypt function?
None
The CFB mode is a parametrized mode and the 64 in DES_cfb64_encrypt sets the size of the shift register or segment to 64 bit. The commandline interface only supports 3 segment sizes for CFB mode which are 1 bit, 8 bit and size of the cipher block size (64 bit for DES). Those three parametrized modes are incompatible between each other and they cannot be used to decrypt ciphertexts that were encrypted with CFB-64.
Related
I am reading data from a TCP port in TCL using a socket. The messages do not end with any newline, but they do container a header containing the number of bytes of data.
I have the following code to read two byte of data from the socket (16bit little endian) and convert that into an integer I can then use in a loop to read the rest of the data:
binary scan [read $Socket 2] s* length
In this case $Socket is my socket and it has been configured to use binary encoding.
This works well except where either the upper or lower byte is 0x0D. It appears TCL reads 0x0D and 0x0A both as '\n', which then defaults to 0x0A, so the code does work correctly. For example 13 is read as 10. How do I stop this from happening?
The socket should be placed into binary mode if you're moving binary data across it.
chan configure $Socket -translation binary
# Use [fconfigure] instead of [chan configure] in older Tcl versions
This disables all the automatic processing that Tcl usually does — your description says you're having a problem with end-of-line conversion — and makes it so that read will just deliver a string of the bytes (formally a string of characters between U+000000 and U+0000FF, and internally using an efficient in-memory encoding scheme).
For files, you can include b in the control mode when opening to get this done for you. For sockets, you need to do this yourself.
In addition to configuring binary encoding, you also need to set the translation to 'lf'. As this is a frequently occurring situation, there is a shorthand for making these two settings:
fconfigure $Socket -translation binary
i need to encrypt an input of 16 bytes with a plain key of 16 bytes with 2 method of encryption CBC and ECB.
i have 2 files with :
1.txt : CB18D7B3101924314051647990A9C4E1
2.txt : 0000000000000000F05FBEFD564A164D
i need after encrypt the second key with the first key , to have a 3.txt file with result
like :
3.txt : D057E1DB9458102CFD06AFCA5504E598
thanks to help me with a program or command to do that.
It seems that the question is how to encrypt the data 2 with the key 1 to obtain the encrypted data 3. Further it looks like the encryption method is CAST, see:CAST.
Where:
1: CB18D7B3101924314051647990A9C4E1
2: 0000000000000000F05FBEFD564A164D
3: D057E1DB9458102CFD06AFCA5504E598
The methods ECB and CBC can not both be used at the same time. See Block cipher mode of operation.
I wrote a Java Card applet to do DES encryption/Decryption. The source code of my applet (If you want to use it, consider that Mr Bodewes found some bugs in this source code (those are mentioned in the comments under his answer. So fix it and then use) have the following functions:
DES_ECB_ISO9797_M1
DES_ECB_ISO9797_M2
DES_ECB_NOPAD
DES_ECB_PKCS5
I did a comparison between output of my program and output of an online tool, and finally I find them different. So I want to check correctness of my program's output using OpenSSL.
These are results for encrypting 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 with key = 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88 :
::> SendToApplet.exe -key 1122334455667788 -data 3030303030303030
Command::
Data: 3030303030303030
Key : 1122334455667788
Results::
DES_ECB_ISO9797_M1:
8E 43 CF B8 91 02 01 38 .C.....8
DES_ECB_ISO9797_M2:
A6 DE 1C D9 1B A9 EE D0 ........
DES_ECB_NOPAD:
0B FC BF EE 82 F4 8B 19 .......
DES_ECB_PKCS5:
AA 6E 4D 79 E5 0C B1 51 .nMy...Q
The question is how I can check to see if these results are OK?
This is list of OpenSSL tool commands and arguments:
OpenSSL> ?
openssl:Error: '?' is an invalid command.
Standard commands
asn1parse ca ciphers crl crl2pkcs7
dgst dh dhparam dsa dsaparam
ec ecparam enc engine errstr
gendh gendsa genrsa nseq ocsp
passwd pkcs12 pkcs7 pkcs8 prime
rand req rsa rsautl s_client
s_server s_time sess_id smime speed
spkac verify version x509
Message Digest commands (see the `dgst' command for more details)
md2 md4 md5 rmd160 sha
sha1
Cipher commands (see the `enc' command for more details)
aes-128-cbc aes-128-ecb aes-192-cbc aes-192-ecb aes-256-cbc
aes-256-ecb base64 bf bf-cbc bf-cfb
bf-ecb bf-ofb cast cast-cbc cast5-cbc
cast5-cfb cast5-ecb cast5-ofb des des-cbc
des-cfb des-ecb des-ede des-ede-cbc des-ede-cfb
des-ede-ofb des-ede3 des-ede3-cbc des-ede3-cfb des-ede3-ofb
des-ofb des3 desx idea idea-cbc
idea-cfb idea-ecb idea-ofb rc2 rc2-40-cbc
rc2-64-cbc rc2-cbc rc2-cfb rc2-ecb rc2-ofb
rc4 rc4-40
Unfortunately I can see anything related to the Padding modes (i.e ISO9797_M1, ISO9797_M2, NOPAD and PKCS5). How I can specify them in my command?
Padding happens before encryption with the block cipher. That means you can always check by decrypting the ciphertext and validating the padding by hand. Using openssl you can simply use -nopad and -K <key in hex> and then validate the output (converting the binary to human readable format first).
Currently we cannot validate because your applet is not returning enough data; you probably forgot to finalize the encryption.
Based on openssl doc:
All the block ciphers normally use PKCS#5 padding also known as standard block padding
This is the only supported padding scheme.
The way around it is to use -nopad option and "manually" pad your input message, following the padding schemes you mentioned.
I am looking at this page on how to validate HMAC implementation on a platform: http://csrc.nist.gov/groups/STM/cavp/
Test Vectors:
HMAC Test Vectors - These files provide an electronic version of the test vectors
that can be used to informally verify the correctness of an HMAC algorithm
implementation using the HMACVS. However, use of these vectors does not
take the place of validation obtained through the Cryptographic Algorithm
Validation Program (CAVP).
So I open up the file and view the test values:
http://pastebin.com/phJ4C0Fx
it is thousands of lines long but this is the start.
I focus on the first values:
[L=20]
Count = 0
Klen = 10
Tlen = 10
Key = 82f3b69a1bff4de15c33
Msg = fcd6d98bef45ed6850806e96f255fa0c8114b72873abe8f43c10bea7c1df706f10458e6d4e1c9201f057b8492fa10fe4b541d0fc9d41ef839acff1bc76e3fdfebf2235b5bd0347a9a6303e83152f9f8db941b1b94a8a1ce5c273b55dc94d99a171377969234134e7dad1ab4c8e46d18df4dc016764cf95a11ac4b491a2646be1
Mac = 1ba0e66cf72efc349207
My understanding is that with a key and value that openssl would get the mac, however I am not getting the same mac as that above?
echo -n "<Msg here>" | openssl sha1 -hmac "82f3b69a1bff4de15c33"
(stdin)= 981c64f70b07634e01b3800447e6431dddb42530
Any ideas on what I am doing wrong? i am also just guessing sha1, other values don't match either, I don't know how to take from the file what way I should be doing this. The various lengths, and the count. How do I use this information?
I'm trying to decrypt a XOR encrypted file, after running the key length test using xortool I got this key: "fallen"..
# python xortool.py -c 00 /cygdrive/c/Users/Me/Desktop/ch3.bmp
The most probable key lengths:
1: 10.6%
3: 11.6%
6: 18.5%
9: 8.8%
12: 13.8%
15: 6.6%
18: 10.4%
24: 8.1%
30: 6.4%
36: 5.2%
Key-length can be 3*n
1 possible key(s) of length 6:
fallen
Whatever is there a way to decipher the file (a bmp file) and get the original one, using tools like openssl or gpg?? Do they have a XOR operation?
Neither OpenSSL nor GPG have such XOR functionality that I'm aware of, however writing a program to do it yourself should be trivial.
Given that you know that the file is a .bmp, you should be able to use this fact to decrypt the file quite easily, especially given that .bmp files have a well defined structure. For example, the first two bytes when decrypted should be 0x42, 0x4D (that's ASCII BM), and the following 4 bytes are the (big-endian) size of the entire file in bytes, so you should be able to get at least 6 bytes of the key immediately.
Since you already have xortool, just use xortool-xor from the xortool distribution:
python xortool/xortool-xor -s fallen /cygdrive/c/Users/Me/Desktop/ch3.bmp > decoded.bmp
Also note that xortool itself saves the decoded output in the xortool_out folder, so after using xortool to find the key, you could just do:
mv xortool_out/0_fallen decoded.bmp