I'm trying to make decryption logic and knnow that encrypted string has been made using:
Key: 8d6ea4d3e6f8c4f8641516baa5e42b85
transformation: AES/CBC/ISO10126PADDING
salt: 1c4dd21d7ba43bdd
iterations: 0
Encrypted string: JO0blEp+nEl5nNhgUqoZRJNecogM1XHIXUCatPOJycs=
Key and salt are given samples here..The main point is to show the format in which I have this data. encryption methods is based on the default JCE provider of the JDK (SunJCE).
Now based on this infromation I have above, I'm trying to build Decryption logic. Few doubts:
1. As the AES-265 is used, can it have 128 bits Key and 64 bit salt values? or I'm interpreting the information wrongly.
2. seeing the encrypted string, it looks like it is Base64 encoded value and we need to decode it while decrypting. Is my understanding correct?
3. Below is the decryption logic that I'm writing that is giving error: "javax.crypto.BadPaddingException: Given final block not properly padded" when I call doFinal() function.
and I'm struck here from last three days:( . Can you please point out or give me the exact code that to be used here for decryption with having infromation:
public static void main(String[] args) throws Exception
{
String encstring = "JO0blEp+nEl5nNhgUqoZRJNecogM1XHIXUCatPOJycs=";
String salt1 = "1c4dd21d7ba43bdd";
String keyStr = "8d6ea4d3e6f8c4f8641516baa5e42b85";
byte[] keyBytes = Hex.decodeHex(keyStr.toCharArray());
SecretKey secret2 = new SecretKeySpec(keyBytes, "AES");
byte[] iv = new byte[]{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
AlgorithmParameterSpec params = new IvParameterSpec(iv);
Cipher cipher2 = Cipher.getInstance("AES/CBC/ISO10126PADDING", "SunJCE");
cipher2.init(Cipher.DECRYPT_MODE, secret2, params);
byte[] encryptedString = Base64.decodeBase64(encstring.getBytes());
byte[] plaintext1 = cipher2.doFinal(encryptedString);
System.out.println(new String(plaintext));
}
}
First a few observations:
You say it's AES256 (that uses 256 bit keys) but your key looks like it might be 32 hex digits which gives 128 bit of key data.
You say you have a salt but AES don't use a salt. And you actually don't use the salt in your code.
You talk about 0 iterations, but iterations are not something you specify to AES, and it would not be 0.
My guess is that your key is actually a password used to generate a key.
Somethig like:
SecretKeyFactory factory = SecretKeyFactory.getInstance(algorithm);
KeySpec spec = new PBEKeySpec(password, salt, iterations, keyLength);
SecretKey theKey = factory.generateSecret(spec);
Take a look in the answer to this question: Java 256-bit AES Password-Based Encryption
Related
I want to decrypt fmp4 segment.
This segment was encrypt with HLS Apple Tools (https://developer.apple.com/documentation/http_live_streaming/about_apple_s_http_live_streaming_tools)
METHOD is AES-128
IV is 1d48fc5dee84b5a3e9a428f055e03c2e
I have a key and IV (you can got the key, and segment in google drive https://drive.google.com/drive/folders/1xF-C9EXFvT8qjI--sBB6QMPn8cNW7L-D?usp=sharing)
To decrypt I use Poco library.
This is my code:
Poco::Crypto::Cipher::ByteVec readKey(const std::string& uri) {
Poco::Crypto::Cipher::ByteVec key;
auto stream = Stream::makeStream(uri);
if (stream->open(uri, {})) {
key.resize(KEY_SIZE);
stream->read((char*)&key[0], KEY_SIZE);
}
return key;
}
std::vector<uint8_t> _key = readKey("./unit-tests/resources/cipher-stream/file.key");
std::string ivSrc = "1d48fc5dee84b5a3e9a428f055e03c2e";
Poco::Crypto::Cipher::ByteVec iv {ivSrc.begin(), ivSrc.end()};
Poco::Crypto::CipherKey key("aes-128-cbc", _key, iv);
Poco::Crypto::Cipher::Ptr cipher = Poco::Crypto::CipherFactory::defaultFactory().createCipher(key);
Poco::FileInputStream src("./unit-tests/resources/cipher-stream/fileSequence1.m4s");
Poco::FileOutputStream dst("./unit-tests/resources/cipher-stream/fileSequence1_dec.m4s");
Poco::Crypto::CryptoOutputStream decryptor(dst, cipher->createDecryptor());
Poco::StreamCopier::copyStream(src, decryptor);
// decryptor.close();
src.close();
dst.close();
Problem description:
After decryption I got distorted data. You can see this at the beginning of the file. Please see picture below. On the right side of the image file is distorted.
The correct data you can see on the left side.
You're using the wrong IV; that will lead to the first block (16 bytes) being corrupted. Your IV hex value is 1d48fc5dee84b5a3e9a428f055e03c2e, but you're interpreting that as ASCII. It's using the first 16 bytes of your string and ignoring the rest.
I haven't used Poco in a long time and don't remember if there's a hex parser handy, but that's what you need. Or write the IV directly in hex rather than as an ASCII string.
I just start learning Bouncy Castle for AES encryption/decryption. I am using AES/CBC/PKCS7PADDING with 256-bit key.
BC can encrypt and decrypt text successfully, however after decryption I notice that there are always a few padding of null (0x00), which therefore fails my hash comparison. For example, suppose original input string is “1234567890”, the decrypted byte array is always:
{0x49,0x50,0x51,0x52,0x53,0x54,0x55,0x56,0x57,0x48,0x00,0x00,0x00,0x00,0x00,0x00}
Why the padding is not 0x06,0x06,0x06,0x06,0x06,0x06? And is there any way to deterministically tell the padding length (could be 0) after encryption so that I can get exactly the same string before encryption?
When you specify PKCS7, BC will add the padding to the data before encrypting, and remove it again when decrypting. PKCS7 with AES would always add at least 1 byte of padding, and will add enough data to make the input a multiple of the AES block size. When decrypting the padding is verified to be correct, and in the case of PKCS7 also serve as an indicator of how much of the last block of decrypted data is padding, and how much is real data.
If you try decrypting the encrypted and padded data without specifying PKCS7 in the decrypt step, the padding would still be in the decrypted data.
Edit:
To illustrate my point .. here is some Java code that encrypts "1234567890" with AES/CBC/PKCS7, and then decrypts it again both with and without the PKCS7 padding:
public class BCTest {
public static void doTest() throws Exception {
Security.addProvider(new BouncyCastleProvider());
byte[] clearData = "1234567890".getBytes();
SecretKey secretKey = new SecretKeySpec("0123456789ABCDEF".getBytes(), "AES");
AlgorithmParameterSpec IVspec = new IvParameterSpec("0123456789ABCDEF".getBytes());
// encrypt with PKCS7 padding
Cipher encrypterWithPad = Cipher.getInstance("AES/CBC/PKCS7PADDING", "BC");
encrypterWithPad.init(Cipher.ENCRYPT_MODE, secretKey, IVspec);
byte[] encryptedData = encrypterWithPad.doFinal(clearData);
System.out.println("Encryped data (" + encryptedData.length + " bytes): \t" + toHexString(encryptedData));
// decrypt with PKCS7 pad
Cipher decrypterWithPad = Cipher.getInstance("AES/CBC/PKCS7PADDING", "BC");
decrypterWithPad.init(Cipher.DECRYPT_MODE, secretKey, IVspec);
byte[] buffer1 = new byte[encryptedData.length];
int decryptLen1 = decrypterWithPad.doFinal(encryptedData, 0, encryptedData.length, buffer1);
System.out.println("Decrypted with Pad (" + decryptLen1 + " bytes): \t" + toHexString(buffer1));
// decrypt without PKCS7 pad
Cipher decrypterWithoutPad = Cipher.getInstance("AES/CBC/NOPADDING", "BC");
decrypterWithoutPad.init(Cipher.DECRYPT_MODE, secretKey, IVspec);
byte[] buffer2 = new byte[encryptedData.length];
int decryptLen2 = decrypterWithoutPad.doFinal(encryptedData, 0, encryptedData.length, buffer2);
System.out.println("Decrypted without Pad (" + decryptLen2 + " bytes):\t" + toHexString(buffer2));
}
private static String toHexString(byte[] bytes) {
return javax.xml.bind.DatatypeConverter.printHexBinary(bytes);
}
public static void main(String[] args) throws Exception {
BCTest.doTest();
}
}
Output:
Encryped data (16 bytes): 602CAE14358D0AC5C96E2D46D17E58E3
Decrypted with Pad (10 bytes): 31323334353637383930000000000000
Decrypted without Pad (16 bytes): 31323334353637383930060606060606
When decrypting with the padding option, the output have been striped of the padding - and the cipher indicates 10 bytes of decrypted data - the rest of the buffer is 0 filled. Decrypting without the padding option, results in the padding now being part of the decrypted data.
Edit2:
Now seeing the original code, confirms my hunch. The methode GetOutputSize don't return the output size of the decrypted string, but only the maximum needed space in an output buffer. The methode have the following documentation in the BC code:
/**
* return the size of the output buffer required for an update plus a
* doFinal with an input of len bytes.
*
* #param len the length of the input.
* #return the space required to accommodate a call to update and doFinal
* with len bytes of input.
*/
DoFinal returns the actual length of the decrypted data put in the buffer.
So in
byte[] plainTextBuffer = new byte[cipher.GetOutputSize(data.Length - IV_LENGTH)];
int length = cipher.DoFinal(data, iv.Length, data.Length - iv.Length, plainTextBuffer, 0);
The plainTextBuffer would be slightly larger than the actual decrypted data - the actual length of data would be in length.
i am using c# from bouncycastle. looks to me this might be a bug from bouncycastle, or at least bouncycastle c# implementation does not follow pkcs7 spec exactly.
my solution is to chop off the trailing bytes that are not included in the return length of DoFinal. still not very sure why there are padding of 0x00, which as said should not exist at all.
below is the code. i used AES/CBC/PKCS7PADDING for both encryption and decryption.
encryption --->
ICipherParameters keyParams = ParameterUtilities.CreateKeyParameter("AES", keyByte);
ICipherParameters aesIVKeyParam = new ParametersWithIV(keyParams, StringToByteArray(IV_STRING));
byte[] iv = ((ParametersWithIV) aesIVKeyParam).GetIV();
IBufferedCipher cipher = CipherUtilities.GetCipher("AES/CBC/PKCS7PADDING");
cipher.Init(true, aesIVKeyParam);
byte[] cipherText = new byte[iv.Length + cipher.GetOutputSize(data.Length)];
Array.Copy(iv, 0, cipherText, 0, iv.Length);
int length = cipher.DoFinal(data, 0, data.Length, cipherText, iv.Length);
decryption --->
ICipherParameters keyParams = ParameterUtilities.CreateKeyParameter("AES", keyByte);
byte[] iv = new byte[IV_LENGTH];
Array.Copy(data, 0, iv, 0, IV_LENGTH);
ICipherParameters aesIVKeyParam = new ParametersWithIV(keyParams, iv);
IBufferedCipher cipher = CipherUtilities.GetCipher("AES/CBC/PKCS7PADDING");
cipher.Init(false, aesIVKeyParam);
byte[] plainTextBuffer = new byte[cipher.GetOutputSize(data.Length - IV_LENGTH)];
int length = cipher.DoFinal(data, iv.Length, data.Length - iv.Length, plainTextBuffer, 0);
I am working with byte arrays and strings. I have a byte array that I modify and then use to generate a string. I have looked at lots of posts on this website that recommend using BlockCopy or System.Text.Encoding.Default.GetString(); I have tried those but for some reason the string I am getting has all gibberish characters.
Here is the problem and what i expect. Lets say i have hex encoded string of bytes as follows:
string str = "f20bdba6ff29eed7b046d1df9fb70000";
Corresponding array is:
byte[] arrayStr = new byte[] { 0xf2, 0x0b, 0xdb, 0xa6, 0xff, 0x29, 0xee, 0xd7, 0xb0, 0x46, 0xd1, 0xdf, 0x9f, 0xb7, 0x00, 0x00 };
Please note that 2 characters in above string represent byte.
Now, lets say I manipulate arrayStr and change the byte at array index 4 (0xff) to (0xe1). I want that I should be able to get a string such that:
string str = "f20bdba6e129eed7b046d1df9fb70000";
Look at BitConverter:
string str = BitConverter.ToString(arrayStr).Replace("-", "");
I just have a quick question about what this code mean. Sorry, been reading other posts but I couldn't fully grasp the concept since none seems to resemble this piece of code that I'm currently working in my embedded system.
int8u buf[1024];
memset(buf, 0, sizeof(buf));
*((int16u*)&buf[2]) = 0xbb01;
can someone explain to me what these lines mean?
It basically interprets the array of bytes buf as 16-bit words and then changes the second word to 0xbb01. Alternative representation:
int8u buf[1024];
memset(buf, 0, sizeof(buf));
int16u *words = buf;
buf[1] = 0xbb01;
&buf[2] takes the address to the second byte in buf. Then the cast to (int16u *) informs the compiler that the result is to be treated as a 16-bit unsigned integer. Finally, the memory on that address is set to 0xbb01.
Depending on the endianness of your system, the contents of buf could then be 0x00, 0x00, 0xbb, 0x01 or 0x00, 0x00, 0x01, 0xbb (followed by more NULs due to the memset()).
Please see the comment of the code for explanation
int8u buf[1024]; // intializing int array of size 1024 in RAM.
memset(buf, 0, sizeof(buf)); // fill in buffer with zero.
(int16u*)&buf[2] is a type casting for pointer which points to int16. here casting is given to &buf[2] i.e. address of buf[2].
*((int16u*)&buf[2]) = 0xbb01; // updating content of int16 -two byte intger starting at buf2
Why this is done ?
This is done as buf array was created is of int8u. and now we need to update int16 value 0xbb01. To do this, in above code we have created int16 pointer.
Step by Step simplification of above pointer
((int16u)&buf[2]) = 0xbb01;
updating content of ((int16u*)&buf[2]) by 0xbb01
&buf[2] is pointer to int16u and update its value by 0xbb01
update value at buf[2],buf[3] by 0xbb01.[#]
[#]: exact content of buf[2], buf[3] will depend on type of core architecture: big endian or small endian.
We have a current application where user login credentials are stored in a SQL Server DB. These are, basically, stored as a plain text username, a password hash, and an associated salt for this hash.
These were all created by built in functions in ASP.NET's membership/role system. Here's a row for a user named 'joe' and a password of 'password':
joe,kDP0Py2QwEdJYtUX9cJABg==,OJF6H4KdxFLgLu+oTDNFodCEfMA=
I've dumped this stuff into a CSV file and I'm attempting to get it into a usable format for Django which stores its passwords in this format:
[algo]$[salt]$[hash]
Where the salt is a plain string and the hash is the hex digest of an SHA1 hash.
So far I've been able to ascertain that ASP is storing these hashes and salts in a base64 format. Those values above decode into binary strings.
We've used reflector to glean how ASP authenticates against these values:
internal string EncodePassword(string pass, int passwordFormat, string salt)
{
if (passwordFormat == 0)
{
return pass;
}
byte[] bytes = Encoding.Unicode.GetBytes(pass);
byte[] src = Convert.FromBase64String(salt);
byte[] dst = new byte[src.Length + bytes.Length];
byte[] inArray = null;
Buffer.BlockCopy(src, 0, dst, 0, src.Length);
Buffer.BlockCopy(bytes, 0, dst, src.Length, bytes.Length);
if (passwordFormat == 1)
{
HashAlgorithm algorithm = HashAlgorithm.Create(Membership.HashAlgorithmType);
if ((algorithm == null) && Membership.IsHashAlgorithmFromMembershipConfig)
{
RuntimeConfig.GetAppConfig().Membership.ThrowHashAlgorithmException();
}
inArray = algorithm.ComputeHash(dst);
}
else
{
inArray = this.EncryptPassword(dst);
}
return Convert.ToBase64String(inArray);
}
Eseentially, pulls in the salt from the DB and b64 decodes it into a binary representation. It does a "GetBytes" on the raw password and then it concatinates them, salt first.
It then runs the SHA1 algorithm on this new string, base64 encodes it, and compares it against the value stored in the database.
I've attempted to write some code to try and reproduce these hashes in Python and I'm failing. I won't be able to use them in Django until I can figure out how this translates over. Here's how I'm testing:
import hashlib
from base64 import b64decode, b64encode
b64salt = "kDP0Py2QwEdJYtUX9cJABg=="
b64hash = "OJF6H4KdxFLgLu+oTDNFodCEfMA="
binsalt = b64decode(b64salt)
password_string = 'password'
m1 = hashlib.sha1()
# Pass in salt
m1.update(binsalt)
# Pass in password
m1.update(password_string)
# B64 encode the binary digest
if b64encode(m1.digest()) == b64hash:
print "Logged in!"
else:
print "Didn't match"
print b64hash
print b64encode(m1.digest())
I'm wondering if anyone can see any flaws in my approach or can suggest an alternate method. Perhaps you can take the algorithms above and the known password and salt above and produce the hash on your system?
It appears python is inserting a byte order marker when you convert a UTF16 string to binary. The .NET byte array contains no BOM, so I did some ghetto python that turns the UTF16 into hex, removes the first 4 characters, then decodes it to binary.
There may be a better way to rip out the BOM, but this works for me!
Here's one that passes:
import hashlib
from base64 import b64decode, b64encode
def utf16tobin(s):
return s.encode('hex')[4:].decode('hex')
b64salt = "kDP0Py2QwEdJYtUX9cJABg=="
b64hash = "OJF6H4KdxFLgLu+oTDNFodCEfMA="
binsalt = b64decode(b64salt)
password_string = 'password'.encode("utf16")
password_string = utf16tobin(password_string)
m1 = hashlib.sha1()
# Pass in salt
m1.update(binsalt + password_string)
# Pass in password
# B64 encode the binary digest
if b64encode(m1.digest()) == b64hash:
print "Logged in!"
else:
print "Didn't match"
print b64hash
print b64encode(m1.digest())
Two thoughts as to what could be going wrong.
First the code from the reflection has three paths:
If passwordFormat is 0 it returns the password as is.
If passwordFormat is 1 it creates the hash as your python code does.
If passwordFormat is anything other than 0 or 1 it calls this.EncryptPassword()
How do you know you are hashing the password, and not encrypting the password with this.EncryptPassword()? You may need to reverse the EncryptPassword() member function and replicate that. That is unless you have some information which ensures that you are hashing the password and not encrypting it.
Second if it is indeed hashing the password you may want to see what the Encoding.Unicode.GetBytes() function returns for the string "password", as you may be getting something back like:
0x00 0x70 0x00 0x61 0x00 0x73 0x00 0x73 0x00 0x77 0x00 0x6F 0x00 0x72 0x00 0x64
instead of:
0x70 0x61 0x73 0x73 0x77 0x6F 0x72 0x64
I hope this helps.