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.
Related
I need a helping hand in order to understand the following assembly instruction. It seems to me that I am calling a address at someUnknownValue += 20994A?
E8 32F6FFFF - call std::_Init_locks::operator=+20994A
Whatever you're using to obtain the disassembly is trying to be helpful, by giving the target of the call as an offset from some symbol that it knows about -- but given that the offset is so large, it's probably confused.
The actual target of the call can be calculated as follows:
E8 is a call with a relative offset.
In a 32-bit code segment, the offset is specified as a signed 32-bit value.
This value is in little-endian byte order.
The offset is measured from the address of the following instruction.
e.g.
<some address> E8 32 F6 FF FF call <somewhere>
<some address>+5 (next instruction)
The offset is 0xFFFFF632.
Interpreted as a signed 32-bit value, this is -0x9CE.
The call instruction is at <some address> and is 5 bytes long; the next instruction is at <some address> + 5.
So the target address of the call is <some address> + 5 - 0x9CE.
If you are analyzing the PE file with a disassembler, the disassembler might had given you the wrong code. Most malware writer uses insertion of E8 as anti-disassembly technique. You can verify if the codes above E8 are jump instructions where the jump location is after E8.
In terminfo(5):
Variable String
Capname
TCap Code
Description
cursor_up
cuu1
up
up one line
key_up
kcuu1
ku
up-arrow key
I tried with tput and they produce the same output:
$ tput cuu1 | hd -C
00000000 1b 5b 41 |.[A|
00000003
$ tput kcuu1 | hd -C
00000000 1b 5b 41 |.[A|
00000003
In a terminfo description, names beginning with k denote keys, while other names are used for non-key capabilities. For most keys, there is no readily apparent relationship between the keys and an existing escape sequence, but cursor-keys are the exception.
Whether they are the same or not depends upon the terminal description. For TERM=linux, they happen to be the same, however a terminal description could be written for the Linux console where they are not.
The distinction is whether the terminal is initialized into application mode or left in the (default/power-up) normal mode. In application mode, the cursor keys would send EscapeO as a prefix rather than Escape[.
A little over half (54%) of the terminal descriptions in the ncurses terminal database use application mode, meaning that cuu1 is more often than not different from kcuu1.
There's another quirk to be aware of: for other cursor movement, such as cud1, the terminal description may say \n, while the key for cursor-down would not send that character (see iTerm for example).
Further reading:
My cursor keys do not work
cursor_up is the control sequence sent by the host to the terminal to move the cursor up a line.
key_up is the control sequence sent by the terminal to the host when the up arrow key is pressed.
In VT100-based terminals (which includes all sane modern terminal emulators), these sequences are identical. However, some older terminal hardware may have used different sequences in these two roles, so terminfo keeps them separate.
I got such a piece of code:
void SHAPresenter::hashData(QString data)
{
QCryptographicHash* newHash = new QCryptographicHash(QCryptographicHash::Sha3_224);
newHash->addData(data.toUtf8());
QByteArray hashResultByteArray = newHash->result();
setHashedData(QString(hashResultByteArray.toHex()));
delete newHash;
}
According to Qt spec, QCryptographicHash::Sha3_224 should "generate an SHA3-224 hash sum. Introduced in Qt 5.1". I wanted to compare result of that code to something other source to check whether I put data in correct manner. I found site: https://emn178.github.io/online-tools/sha3_224.html
So we have SHA3_224 in both cases. The problem is that the first will generate such a byte string from "test":
3be30a9ff64f34a5861116c5198987ad780165f8366e67aff4760b5e
And the second:
3797bf0afbbfca4a7bbba7602a2b552746876517a7f9b7ce2db0ae7b
Not similar at all. But there is also a site that do "Keccak-224":
https://emn178.github.io/online-tools/keccak_224.html
And here result is:
3be30a9ff64f34a5861116c5198987ad780165f8366e67aff4760b5e
I know that SHA3 is based on Keccak's functions - but what is the issue here? Which of these two implementations follows NIST FIPS 202 in proper manner and how do we know that?
I'm writing a Keccak library for Java at the moment, so I had the toys handy to test an initial suspicion.
First a brief summary. Keccak is a sponge function which can take a number of parameters (bitrate, capacity, domain suffix, and output length). SHA-3 is simply a subset of Keccak where these values have been chosen and standardised by NIST (in FIPS PUB 202).
In the case of SHA3-224, the parameters are as follows:
bitrate: 1152
capacity: 448
domain suffix: "01"
output length: 224 (hence the name SHA3-224)
The important thing to note is that the domain suffix is a bitstring which gets appended after the input message and before the padding. The domain suffix is an optional way to differentiate different applications of the Keccak function (such as SHA3, SHAKE, RawSHAKE, etc). All SHA3 functions use "01" as a domain suffix.
Based on the documentation, I get the impression that Keccak initially had no domain suffix concept, and the known-answer tests provided by the Keccak team require that no domain suffix is used.
So, to your problem. If we take the String "test" and convert it to a byte array using ASCII or UTF-8 encoding (because Keccak works on binary, so text must be converted into bytes or bits first, and it's therefore important to decide on which character encoding to use) then feed it to a true SHA3-224 hash function we'll get the following result (represented in hexadecimal, 16 bytes to a line for easy reading):
37 97 BF 0A FB BF CA 4A 7B BB A7 60 2A 2B 55 27
46 87 65 17 A7 F9 B7 CE 2D B0 AE 7B
SHA3-224 can be summarised as Keccak[1152, 448](M || "01", 224) where the M || "01" means "append 01 after the input message and before multi-rate padding".
However, without a domain suffix we get Keccak[1152, 448](M, 224) where the lonesome M means that no suffix bits are appended, and the multi-rate padding will begin immediately after the input message. If we feed your same input "test" message to this Keccak function which does not use a domain suffix then we get the following result (again in hex):
3B E3 0A 9F F6 4F 34 A5 86 11 16 C5 19 89 87 AD
78 01 65 F8 36 6E 67 AF F4 76 0B 5E
So this result indicates that the function is not SHA3-224.
Which all means that the difference in output you are seeing is explained entirely by the presence or absence of a domain suffix of "01" (which was my immediate suspicion on reading your question). Anything which claims to be SHA3 must use a "01" domain suffix, so be very wary of tools which behave differently. Check the documentation carefully to make sure that they don't require you to specify the desired domain suffix when creating/using the object or function, but anything which claims to be SHA3 really should not make it possible to forget the suffix bits.
This is a bug in Qt and reported here and Fixed in Qt5.9
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.
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