I added my own cipher as an engine to OpenSSL. My cipher supports different key sizes and block sizes, one of them is 512 bit block size. Does OpenSSL support ciphers with that key size and block size ?
When I set my cipher's block size to 64, this is what i get when i encrypt or decrypt:
The error is in evp_enc.c line 216
OpenSSL internal error, assertion failed: ctx->cipher->block_size == 1 || ctx->cipher->block_size == 8 || ctx->cipher->block_size == 16
Does this mean that only these block sizes are supported in OpenSSL ?
Thanks.
Related
If I open a serial port:
% set serial_com6 [open com6 r+]
file1a21465b4a0
and set set its outSize and inSize through
% fconfigure $serial_com6 -sysbuffer {512 512}
so far things seem ok:
% fconfigure $serial_com6 -sysbuffer
512 512
except I can put about 4096 bytes without overflowing:
% for {set i 0} {$i < 4096} {incr i} {put $serial_com6 { }}
% fconfigure $serial_com6 -queue
0 4096
This doesn't make scene. I would appreciate if you could help me know how I can query / set the maximum input / output buffer size of a serial port.
P.S.1. I forgot to say my OS is Windows 10 and I'm using Tcl 8.5 inside Scilab / ScosLab
P.S.2. i might just have found the solution. from here:
%fconfigure $serial_com6 -buffersize
4096
gives me the max buffer size and i can also set it like:
% fconfigure $serial_com6 -buffersize 512
% fconfigure $serial_com6 -buffersize
512
So apparently Windows doesn't use the sysbuffer or they are pointing to two different things which I do not understand.
While Tcl can request that settings change on a serial port, it is actually up to the OS to change them: it's free to constrain values as it sees fit (or throw errors). You'll need to see the Windows documentation for what that value actually can be set to (it's not one of the portable settings).
The -buffersize option controls the size of Tcl's own output buffer in the generic layer of the channel system, and not anything at the OS level; when in -buffering full mode, it tries to accumulate (at least) that many bytes before writing them out. You probably don't want to use full buffering for a serial port, given how slow it is. You might want to use a non-blocking serial port (-blocking 0) and run an event loop: then Tcl will stream your output out to the serial port as fast as it can behind the scenes (or you can use a writable fileevent to take more control).
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.
What is the "CRC value" in the info block of MSP430FR5959 (address 01A02h)?
All specs just say "CRC value" and "per unit". But what is the actual data being checksummed? Device ID? Firmware? Something else?
This User's Guide (SLAU367M) has some clues in section 1.14. Table 6-62 in the datasheet says that the CRC length value is 6, which is the same as the Info length value. And the User's Guide section 1.14.1 explains that Info Length value of 6 means 2^6 = 64 32-bit words or 256 bytes. So I suspect the CRC length is also 256 bytes. And I interpret section 1.14.2 to say that Info length (and presumably CRC length) start from address 0x1A08. So my guess is that the CRC value is calculated over the 256 bytes starting at address 0x1A08.
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 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.