Select different padding modes in OpenSSL commands

Question

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?

Solution 1

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.

Solution 2

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.

Comments

[Ebrahim Ghasemi]

your applet is not returning enough data Which kind of data? you probably forgot to finalize the encryption What does this mean? I posted the source of my applet here : stackoverflow.com/questions/30148089/… May I ask you to help me validate it?

[Maarten Bodewes]

You forgot that doFinal returns the size of the encrypted data. Because of padding, the returned data size may be larger than the amount of input. Deterministic schemes always pad, even if you provide exactly one block of data.

[Maarten Bodewes]

Your results are not OK; you should have identical ciphertext for identical input. ECB doesn't use an IV, it's fully deterministic.

[Ebrahim Ghasemi]

Is my applet program wrong? (except than replacing dataLen setOutgoinAndSend method with the output of doFinal method)

[Ebrahim Ghasemi]

I used this command G:\> openssl des-ecb -in 1.txt -out 2.txt -nosalt -K 1122334455667788 -iv 0 -base64 and convert contents of 2.txt to hex form, to check the correctness of my outputs, am I in a right way?

[Maarten Bodewes]

Looks like it, although obviously 1.txt and 2.txt contain binary data (ciphertext is always binary, and the decrypted text may contain the padding on top of the zero characters).

[Ebrahim Ghasemi]

So it is wrong to put ASCII value of 0x30 (i.e 0) in the 1.txt instead of 30?(currently contents of 1.txt is 00000000) With the -base64 in the end of my command, we have binary in the 2.txt still?

[Maarten Bodewes]

Ah, sorry, no, most of the time you validate using decryption rather than encryption. All zeros is text indeed. Not all encryption schemes are deterministic.

[Ebrahim Ghasemi]

:) What shall I do now Mr Bodewes? Why my results are not OK? Just because of ignoring foFinal output? if so, after correcting it, how can I validate them? I'm sorry for my pestering.

[Maarten Bodewes]

Let us continue this discussion in chat.

[Ebrahim Ghasemi]

Deterministic schemes always pad, even if you provide exactly one block of data : the doFinal() method returns 8 for all 8 byte length data for me. I throw the value that this method returns in the next line of it using isoException.throwIt() and it is 8. Why it doesn't have padding?