I am using eccrypto library in javascript for encryption using the ECIES algorithm (curve- secp256k1). The cipher generated by encryption in JS code could not be decrypted in Kotlin.
Here is the Javascript code.
var eccrypto = require("eccrypto");
eccrypto.encrypt(publicKeyA, Buffer.from("Sic Mundus Creatus Est")).then(function(encrypted) {
val ciphertext = encrypted.ciphertext
//the hex encoded ciphertext is then sent to the server
}
Here is the decryption code for kotlin
val cipherBytes = DatatypeConverter.parseHexBinary(ciphertext)
val cipher: Cipher = Cipher.getInstance("ECIES", "BC")
cipher.init(Cipher.DECRYPT_MODE, privateKeyA)
print( cipher.doFinal(cipherBytes) )
With this code for decryption, I get an Bad Block Exception.
However, if I just do encryption and decryption using Java, there is no problem. Also, encryption and decryption both in Javascript also work fine.
Is there anything I am missing?
I found the solution (or say figured out the actual issue). Hope it helps future devs:
The mismatch in encryption/decryption between javascript and java implementation is because those implementations are using different parameters of the hash algorithm and AES encryption.
ECIES implementation in Java using BouncyCastle has a crappy implementation. It uses AES with 128 bits, does not use a secure hash algorithm, no robust check for MAC, and has very little test cases.
As a workaround, I now use a custom written ECIES implementation for Java which uses SHA-512 for the hash, AES encryption (using 256 bits key and AES/CBC/PKCS7Padding mode). This new implementation is what eccrypto javascript library engine uses under the hood. Now, they work fine!
Your comment 'Encrypting the same message using the same public key in both environment gives different cipher messages' does not prove a difference between values. I encrypted 10 times the same message '123' with my public key and got 10 times a different encrypted value.
This is due to a random element in the (internal) encryption function:
ciphertext: 0444a9e31cf1f8f7cabcf2a6562622ce2ee1c38bcdf9938fa48401b34fbeae7ea70c9ad1bd16343a3632ef9011ba6081a7df47ed2ca9904bf0f97febdd18f1b5da9315f744a68c87deee353b481cfbe90a49462403550e3a
ciphertext: 04e1970f415cccb62dc61de534bd61ce9627e9b0e857f6270c20b202f3e62a789979d7c9ca893d85f65f00f5462a29cb986764e34fefb8f5c5ce8f0e9700ddf777b616539ec4e860bad4cac04f8cd3b29c61513cb68a1c9b
ciphertext: 04b07bfbfa53e17446ac8ebaf6af53056274ff4e104bfe26da6176aab390d521429971c151f31a1af4b0240703d4b75a81136b22695798b1ad1cf272e842f5e60ba931972e6868ca54301ec6585ff503cfab76f69ad3beb0
ciphertext: 041d90bcfa34af06559c5f482d06a684492001bb3bd52dc2e9f2eb31cd2de27e595fad3178c0f65d3cd160e0444ae6d9cbfbd2a1e12e21525057d79b8ea24fed572426e3fdeba4a298c17fc481acb66db7b0c8f1d0d0701d
ciphertext: 04a440a994dc0a5f712b1190e1dc0bfff15c053e4a03dc3c74c0cfc965a2da5ed6d668a52b4ae1e320b5ed068fc338e2076f2bc68f156fb79d67daf74ab21c4036a23bebcca007417d5c8ed486750dd37b3f495de92312aa
ciphertext: 04033bfaa2fb90c667ca25e77abba6cdc8e6c601ebb5bf836456c810abe54a4d426b3e52477a8b97f1115905d0babbdda572d9294532d7eda032f6fc98a588c77b00b7bebfe1fe1f4319f3aa0b1776c6da02d9f24baa98c2
ciphertext: 047a1aa7e82084af63cdf76ad0bdd21865d38fdee7fa8902dbf5c0e4840c7209c9cb249698802313c83d22fc8e18b376012888ee0878d4e8c186c241b648180613b1ee460bf9eef5c9a6fab15541ae4bc16dd9f98a10c940
ciphertext: 04dbababe30bd8013bd74f846ed2f1bd818e5b826b59b9b6c6336a62e2e373e82e7f80d2a2fbc3094435e61a53325aba6585047af6bfa593260afc6e5ee737783a8dbbc60d3f99277eea95ed2671d2a81d369602388b7cb0
ciphertext: 04eb52c8d946bfd1d84b27858f78d174bf77509058d10d6bfe11ee5f6553b1c571b3c9c7389b08e596735342584c2be43f5ef4e6952d3db7b5239d00b2c7d22f1ca9e588a8f6dc5c8274d97d18999c4a88702d12b9d56ea6
ciphertext: 04808530ee927d5445a1e8f7a06b6bd8c1457cbf89ea6a75e2a28fd8899e06e8ccc5fab8b45536610a79a50ebf3ca1ed5fafb782fe483165fdc483c7e2e3c3724409d539cdbf586f090b783647d791f33ddfa8e2ba29e328
Related
I've generated a random 256 bit symmetric key, in a file, to use for encrypting some data using the OpenSSL command line which I need to decrypt later programmatically using the OpenSSL library. I'm not having success, and I think the problem might be in the initialization vector I'm using (or not using).
I encrypt the data using this command:
/usr/bin/openssl enc -aes-256-cbc -salt -in input_filename -out output_filename -pass file:keyfile
I'm using the following call to initialize the decrypting of the data:
EVP_DecryptInit_ex(ctx, EVP_aes_256_cbc(), nullptr, keyfile.data(), nullptr))
keyfile is a vector<unsigned char> that holds the 32 bytes of the key. My question is regarding that last parameter. It's supposed to be an initialization vector to the cipher algorithm. I didn't specify an IV when encrypting, so some default must have been used.
Does passing nullptr for that parameter mean "use the default"? Is the default null, and nothing is added to the first cipher block?
I should mention that I'm able to decrypt from the command line without supplying an IV.
What is the default IV when encrypting with EVP_aes_256_cbc() [sic] cipher...
Does passing nullptr for that parameter mean "use the default"? Is the default null, and nothing is added to the first cipher block?
There is none. You have to supply it. For completeness, the IV should be non-predictable.
Non-Predictable is slightly different than both Unique and Random. For example, SSLv3 used to use the last block of ciphertext for the next block's IV. It was Unique, but it was neither Random nor Non-Predictable, and it made SSLv3 vulnerable to chosen plaintext attacks.
Other libraries do clever things like provide a null vector (a string of 0's). Their attackers thank them for it. Also see Why is using a Non-Random IV with CBC Mode a vulnerability? on Stack Overflow and Is AES in CBC mode secure if a known and/or fixed IV is used? on Crypto.SE.
/usr/bin/openssl enc -aes-256-cbc...
I should mention that I'm able to decrypt from the command line without supplying an IV.
OpenSSL uses an internal mashup/key derivation function which takes the password, and derives a key and iv. Its called EVP_BytesToKey, and you can read about it in the man pages. The man pages also say:
If the total key and IV length is less than the digest length and MD5 is used then the derivation algorithm is compatible with PKCS#5 v1.5 otherwise a non standard extension is used to derive the extra data.
There are plenty of examples of EVP_BytesToKey once you know what to look for. Openssl password to key is one in C. How to decrypt file in Java encrypted with openssl command using AES in one in Java.
EVP_DecryptInit_ex(ctx, EVP_aes_256_cbc(), nullptr, keyfile.data(), nullptr))
I didn't specify an IV when encrypting, so some default must have been used.
Check your return values. A call should have failed somewhere along the path. Maybe not at EVP_DecryptInit_ex, but surely before EVP_DecryptFinal.
If its not failing, then please file a bug report.
EVP_DecryptInit_ex is an interface to the AES decryption primitive. That is just one piece of what you need to decrypt the OpenSSL encryption format. The OpenSSL encryption format is not well documented, but you can work it backwards from the code and some of the docs. The key and IV computation is explained in the EVP_BytesToKey documentation:
The key and IV is derived by concatenating D_1, D_2, etc until enough
data is available for the key and IV. D_i is defined as:
D_i = HASH^count(D_(i-1) || data || salt)
where || denotes concatentaion, D_0 is empty, HASH is the digest
algorithm in use, HASH^1(data) is simply HASH(data), HASH^2(data) is
HASH(HASH(data)) and so on.
The initial bytes are used for the key and the subsequent bytes for the
IV.
"HASH" here is MD5. In practice, this means you compute hashes like this:
Hash0 = ''
Hash1 = MD5(Hash0 + Password + Salt)
Hash2 = MD5(Hash1 + Password + Salt)
Hash3 = MD5(Hash2 + Password + Salt)
...
Then you pull of the bytes you need for the key, and then pull the bytes you need for the IV. For AES-128 that means Hash1 is the key and Hash2 is the IV. For AES-256, the key is Hash1+Hash2 (concatenated, not added) and Hash3 is the IV.
You need to strip off the leading Salted___ header, then use the salt to compute the key and IV. Then you'll have the pieces to feed into EVP_DecryptInit_ex.
Since you're doing this in C++, though, you can probably just dig through the enc code and reuse it (after verifying its license is compatible with your use).
Note that the OpenSSL IV is randomly generated, since it's the output of a hashing process involving a random salt. The security of the first block doesn't depend on the IV being random per se; it just requires that a particular IV+Key pair never be repeated. The OpenSSL process ensures that as long as the random salt is never repeated.
It is possible that using MD5 this way entangles the key and IV in a way that leaks information, but I've never seen an analysis that claims that. If you have to use the OpenSSL format, I wouldn't have any hesitations over its IV generation. The big problems with the OpenSSL format is that it's fast to brute force (4 rounds of MD5 is not enough stretching) and it lacks any authentication.
I have searched and found examples of AES with the default 256 key size and find it worked already. But when I want to use 128 key size, there is little information.
I have extracted code from the aes test from CryptoJS:
var C = CryptoJS;
var plainText = '00112233445566778899aabbccddeeff';
var key = '000102030405060708090a0b0c0d0e0f';
var encryptedText = C.AES.encrypt(C.enc.Hex.parse(plainText), C.enc.Hex.parse(key), { mode: C.mode.ECB, padding: C.pad.NoPadding }).ciphertext.toString();
console.log(encryptedText);
var decryptedText = C.AES.decrypt(C.lib.CipherParams.create({ ciphertext: C.enc.Hex.parse(encryptedText) }), C.enc.Hex.parse(key), { mode: C.mode.ECB, padding: C.pad.NoPadding }).toString();
console.log(decryptedText);
This worked, but if I want to use a different plain text like 'Hello World' then it failed. Also what if I want to use a password like 'my-key-001'? As I have read that CryptoJS expect to use 256 key size if I pass a password.
Your help is much appreciated.
This worked, but if I want to use a different plain text like 'Hello World' then it failed.
You have used the noPadding and that is the issue. The example is multiple of 16-byte that causes no problem, however your next plaintext is not. You can use noPadding if
your message is an exact multiple of the block size, though still not recommended.
you want to pad the message yourself, probably that is you want to test a new padding scheme that we don't see in your code.
You should you padding like
padding: CryptoJS.pad.Pkcs7
As I have read that CryptoJS expect to use 256 key size if I pass a password.
CryptoJS supports AES-128, AES-192, and AES-256. According to your key size it will select the key variants. If you use a password it will generate a 256-bit size. That is %40 times slower than AES-128 since it requires 14 rounds. However use a good password, see below.
Also what if I want to use a password like 'my-key-001'?
A password with high entropy is important otherwise the attackers can be successful by testing passwords. The key generation cannot increase entropy. Therefore you need a good way to generate high entropy passwords like using diceware.
How to encrypt in AES using CryptoJS with key size of 128?
Just provide a 128-bit key.
Does AES-128 has 128-bit security
Any block cipher, not only AES, has vulnerable to multi-target attacks. In that case it is not providing 128-bit security. Therefore you should use 192 or 256-bit keys.
For a more detailed see this question Has AES-128 been fully broken?
mode: C.mode.ECB
The ECB mode of operations is not advised, it is insecure and it leaks pattern. You should use modern encryption modes like AES-GCM which provides you not confidentiality but also, integrity and authentication.
While using GCM mode, make sure that you never use the same IV/nonce again under the same key. AES-GCM uses CTR mode for encryption and under the same key if the IV/nonce repeated then crig-dragging is possible. Also, it can leak the authentication key.
I've trying to encrypt my data using asymmetric encryption. I've chosen MD5 as the algorithm. PS: I know about MD5 collisions.
I'm following this blog to encrypt and decrypt my data. This uses SHA256. I'm able to run the code successfully with SHA1, SHA512 as well, but not with MD5.
Whenever, I change the algorithm to MD5, it says
cryptography.exceptions.UnsupportedAlgorithm: This combination of padding and hash algorithm is not supported by this backend.
Which padding should be used to encrypt the data with MD5?
My Code:-
# ########## Encrypting and decrypting ##########
message = b'encrypt me!'
encrypted = public_key.encrypt(
message,
padding.OAEP(
mgf=padding.MGF1(algorithm=hashes.MD5()),
algorithm=hashes.MD5(),
label=None
)
)
original_message = private_key.decrypt(
encrypted,
padding.OAEP(
mgf=padding.MGF1(algorithm=hashes.MD5()),
algorithm=hashes.MD5(),
label=None
)
)
Actually, MD5 is (an old) hash algorithm, it is not an encryption algorithm. A hash is used to get a sort of "checksum" for a given text (or data byte array). That "checksum" as a fix length, whatever is the size of the text you hash.
In cryptography, you typically may use hash function to get a private (symmetric) key from a passphrase or you may encrypt a hash with a private key : this is a digital signature.
SAP servers are capable of encrypting and hashing data. But there doesn't appear to be a suitable API to call. SAP Note 1456433 talks about the class CL_SEC_SXML_XENCRYPTION. The signature of basic encryption is clearly geared towards SSF and unsuitable to basic private key encryption/decryption. I don't want/need envelopes and user certificates. Just private keys.
I found an AES library on GitHub AES library in ABAP and tweaked that to suit us. But it is very slow. I would like to use the encryption libraries SAP has. Clearly, the libraries are there but find a suitably exposed API seems the issue.
Does anybody know how to use basic encryption in SAP?
In SAP ABAP stack, using ABAP.
Eg (a call to use AES-CBC 128, with PKCS7 padding
where only a private key and data to encrypt is required. As example:
public static method encrypt_xstring
importing i_key type xstring
i_data type xstring
i_initialization_vector type xstring optional
i_padding_standard type char10 optional
i_encryption_mode type char10 optional
exporting e_data type xstring
Use case is encrypting data on clients with a private key and sending the data to SAP system. The source supports private keys and libraries like AES-CBC.
And we have encrypted data interchange working.
Next step is to use a supported and faster library.
EDIT: In case anyone needs to encryption / decryption properly in abap
And is looking at the answer. Use class CL_SEC_SXML_WRITER.
CL_SEC_SXML_WRITER was exactly what i was looking for
BUT SAP didnt expose it properly. It is only useful for encryption no decryption.
When interacting with external libraries. Where PKCS7 padding is used and SALTs
or Initialization vectors are required.
SAP offer an ENCRYPT_IV but no Decrypt_IV. Why ????
So you cant use the tool and remain compliant. :(
It is not considered safe to use AES-CBC without IV.
Why would SAP do that ?
ENCRYPT_IV instead of ENCRYPT but no DECRYPT_IV
The offer an Add Padding but no remove padding. OK roll your own padding removal, no big deal. Its like the must be another library for the other direction.
So i can use the tool to encrypt but not decrypt.
My main problem was decrypting quickly strings sent from a mobile device.
So still need to use the old ABAP code for that :(
I have similar requirements and I found the cl_sec_sxml_writer class. Please have a look at the following example. Note that the writer requires XSTRING parameters which is why I'm using conversion classes.
REPORT zged_aes.
DATA lv_message_string TYPE string.
" create message
DATA(lr_conv_sec) = cl_abap_conv_out_ce=>create( ).
lr_conv_sec->write( data = 'This is my secret' ).
" create key
DATA(lr_conv_key) = cl_abap_conv_out_ce=>create( ).
lr_conv_key->write( data = 'MySymmetricKey' ).
" encrypt using AES256
cl_sec_sxml_writer=>encrypt(
EXPORTING
plaintext = lr_conv_sec->get_buffer( )
key = lr_conv_key->get_buffer( )
algorithm = cl_sec_sxml_writer=>co_aes256_algorithm_pem
IMPORTING
ciphertext = DATA(lv_message) ).
" decrypt message
cl_sec_sxml_writer=>decrypt(
EXPORTING
ciphertext = lv_message
key = lr_conv_key->get_buffer( )
algorithm = cl_sec_sxml_writer=>co_aes256_algorithm_pem
IMPORTING
plaintext = DATA(lv_message_decrypted) ).
" convert xstring to string for output
cl_abap_conv_in_ce=>create( input = lv_message_decrypted)->read( IMPORTING data = lv_message_string ).
" output secret message
WRITE lv_message_string.
I tested it on a NetWeaver 7.50 SP 6 system.
I got the ENCRYPT_IV method to work alongside method DECRYPT of class CL_SEC_SXML_WRITER.
The caveat here is that I didn't generate the Symmetric Key and IV by making use of Class cl_abap_conv_out_ce.
I already had my keys and IV from a Java implementation test.
The only thing I needed was to create the Key and IV as an XSTRING and initializing them with the Hex format of my Java implementation (they were in Byte format.
Because of this, I first converted them to Hex and passed those values to the ABAP Xstring types).
I'm having some troubles matching the value returned from RSA signing
a Base64 SHA1 hash in the actionscript as3crypto library with the result returned in c#.
I'm passing in a Base64 hash decoded as a byte array to the sign()
function provided in as3crypto and base64 encoding the result.
However, this result never matches the returned result from a c#
function which performs the same task. Does it matter that the
function takes in and returns hex even though it works at the byte
array level?
Please see my below signing function to check i haven't missed
anything!
private function signHash(hashInBase64:String):String
{
var src:ByteArray = Base64.decodeToByteArray(hashInBase64);
var key:RSAKey = getRSAKey();
var dst:ByteArray = new ByteArray();
key.sign(src, dst, src.length);
return Base64.encodeByteArray(dst);
}
Anyone had much experience with the AS3Crypto library?
Any help would be great!!!
Thanks,
Jon
I assume that your C# version is using RSA PKCS #1 version 1.5. The standard computes signatures by doing an RSA private key operation over a byte string composed as
0x00 0x01 || 0xff* || 0x00 || OID || hash
Looking at the as3crypto code shows that the RSAKey class does not add any OID during the sign operation. Hence if you don't do it you'll get incorrect results.
Looking at the code also shows that as3crypto is vulnerable to this attack, because it does not verify the padding properly. This attack is more than 3 years old. Hence it seems like a good to use a different library than as3crypto.
Now there is an ActionScript crypto library compatible with .NET. Here it is: http://code.google.com/p/flame. Looks like it supports RSA exactly the way .NET does.