Hash string using SHA-1 and base64 encode - r

How to hash a string using SHA-1 and base64 encode? I have package openssl and I can use sha1 function to has a string but I don't know how to combine sha-1 and base64 encode to my string.
For testing purpose, my string is:
HY8&V5EDJO8NYT9C2011-12-13T00:44:02ZTest123
I need to SHA-1 and base64 encode to output:
nuoiyUX6m+irC5rvB4QUSycfHGc=
Please could someone kindly advice?

As you are using the openssl package, use the following function
openssl::base64_encode(openssl::sha1(charToRaw("HY8&V5EDJO8NYT9C2011-12-13T00:44:02ZTest123")))

openssl generally operates on a file,basically stdin in a byte stream.
I am passing "HY8&V5EDJO8NYT9C2011-12-13T00:44:02ZTest123" in a form of printf, In a sequence of non-0 bytes (which may or may not form valid characters in UTF-8 or other character set/encoding).
Since the input is passed from the terminal, on a keyboard. The terminal will send corresponding characters (as written on the key label) encoded in its configured character set.
Usually, set in the current locale. You can find that by using a command "locale charmap".
We have to make sure the input is first convierted to UTF-8 and then passed to openssl. that the reason i have used icovn to convert bytes to the corresponding encoding in UTF-8.
So below command can be used to convert our string in sha1 and then base64 using openssl.
printf %s "HY8&V5EDJO8NYT9C2011-12-13T00:44:02ZTest123" | iconv -t utf-8 | openssl dgst -sha1 -binary | openssl enc -base64

$ echo nuoiyUX6m+irC5rvB4QUSycfHGc= | base64 -d | xxd -g 1
00000000: 9e ea 22 c9 45 fa 9b e8 ab 0b 9a ef 07 84 14 4b ..".E..........K
00000010: 27 1f 1c 67
And:
$ echo -n "HY8&V5EDJO8NYT9C2011-12-13T00:44:02ZTest123" | openssl sha1
(stdin)= 9eea22c945fa9be8ab0b9aef0784144b271f1c67
And:
$ cat test.c
#include <stdio.h>
#include <string.h>
#include <openssl/sha.h>
int main()
{
unsigned char ibuf[] = "HY8&V5EDJO8NYT9C2011-12-13T00:44:02ZTest123";
unsigned char obuf[20];
SHA1(ibuf, strlen(ibuf), obuf);
int i;
for (i = 0; i < 20; i++) {
printf("%02x ", obuf[i]);
}
printf("\n");
return 0;
}
And then:
$ gcc -I /usr/local/include/ test.c /usr/local/lib/libcrypto.a -o test.exe
$ ./test.exe
9e ea 22 c9 45 fa 9b e8 ab 0b 9a ef 07 84 14 4b 27 1f 1c 67

Maybe a little bit late, but try
$ echo -n "HY8&V5EDJO8NYT9C2011-12-13T00:44:02ZTest123" | openssl dgst -binary -sha1 | openssl enc -base64
This will:
Echo the string to the pipe
openssl will digest the string using SHA1 algorithm and pipe it
openssl will encode the resulting digested string from step 2 into a new string using base64 algorithm
And it will be echoed back to you.

Related

How to decode openssl enc'd data with salted password?

$ curl -s 'https://finance.yahoo.com/quote/MSFT/profile?p=MSFT' | awk -v ORS= 'match($0, /^ *root[.]App[.]main = (.*);$/, a) { print a[1] }' | jq -r .context.dispatcher.stores > /tmp/tmp.txt
$ file /tmp/tmp.txt
/tmp/tmp.txt: openssl enc'd data with salted password, base64 encoded
How can I decode the above data?

How to decrypt a large AES encrypted data with openssl command?

I want to decrypt large AES encrypted data:
Encrypted data: 7dS560FiDJvUji7c+ky/9nQp+HwK3SEOkY4zefqlFuEyF2/vevrv8K4GJNr2zxD7+j28RK97LmaHjwY9F+/feO6T2DAQuJQsT3wp/fKCPyErwZggsE+ufzvEJZK/XObR8CdbBe8EGZC//JsuMo7MV6SSe267jp4U2iIz4xIFxUlFVy9QcjTr6AUJZdVogedreBgy3/q/isAqOvwoHuj74MV5gkfaXWvmqESjMF4s5wMsYmS1WuBWOR6rw+TSwuL52CiVC5arHuJJEKuodO58bJ+1Ip9uelUIOETswiZmZB6gpTkbos7ij0BpJregejT+9vsDO1tB7+QpByMqeeEbEiSp4N833Z29WmVmy+HpxdZvOPIJ2pyelVhRVPPs/V7VREs4v8/e3X1jR0saA1sSyKYNgIGZUWaQTJwBNi87IPkGiUtyhPnrrKh+BighshJi+Jd+s3+sTYM5CaADvaGhm3wx96rBQi2So+NmFcm5cQa4jRA4S8sLGHmniUO0iiEcxQ2FvlGt+0PBqdbCPewBgOHdjpBUYjs1oR4pV5VjbjTfuIh75G7TS6TZT/gMewJXOXPw88zsSgjXVjRK0obOXaJBKABJ8AqKbKULWHoeMuWW4OdiSZ7mNVt6N40LK/u12vpqWU7Wt5XbSeE3arJPjljEV7WhafKvIOHFx+cK0wB9LQnFUrx/FTLL5HDDEkhnVkm02vxXSFKDwP36VgQnPpvOnY5fbJUTyjnwJcO8I9/H1hYwzPRhos2eNAdHZ3aMysU8zSobwUVto9GnQrvVmVURFyEX6fwifkrf2DTfCsDNSsHt4DLCtsszABKTwTezUoBesNkndk/Qkcd13GEZjTHoyP2tLp85nYwbwI6P+yr1jeu9v3ocN5p0LWPXdwlyTo55WeYkGzlJLsM6d9sut1qlcyQ2AZ536+eYFAIURJkmSexwfbdRebwckvqURRO3a55WCbLxVARKDHnyfculr/ndwyZF7J0RX4G1KcwSgfRdnBpUCkpGeQRImv5Ry5RYXwp5XfKQDrGTCEhV3XtDBD4b2eTxw4KwgJUq9T6IQjNNyPyDwM5AFxS2Y+4wAA0PA2iADfVe3kZrOKYpZvVn0Q== (base64 encoded)
Key: uHe2MCmggLlugpGBiMVuXTck7OT8Nk8g (base64 encoded)
Cipher: AES-256-CBC
IV: LNP8U7pc6GjxzxAtgw4s3A== (base64 encoded)
I try to use this command for it:
openssl aes-256-cbc -d -in data.enc -out data.dec -K $key -iv $iv
In $key and $iv i decoded from encoded values this way
iv=$( cat response.json | jq .iv -r | openssl base64 -d | xxd -p | tr -d '\n' )
But i have crashed data like this
^GÌ<8a>û)F"PEi~^K±jÔ^AcWSM
23NDwSOqovXSFGNfy3WatkCreYRd7kcWSM";

global variables names in optimized ELF binary

Why ELF files keep the actual names of global variables? rather than just keeping their addresses. Here is an example file:
int oren; int moish;
int main(int argc, char **argv)
{
if (argc>3)
{
oren=2;
moish=5;
return oren+moish;
}
return 8;
}
I compiled it and looked for moish with
$ gcc -O3 main.c -o main
$ objdump -D ./main | grep "moish"
I was a bit surprised to find the actual name moish inside (since I'm not sure
what it is needed for):
504: c7 05 06 0b 20 00 05 movl $0x5,0x200b06(%rip) # 201014 <moish>
0000000000201014 <moish>:
Any reason to keep it?
I was a bit surprised to find the actual name moish inside
UNIX binaries traditionally keep the symbol table in linked binary (executable or DSO) to assist in debugging. The symbol table is not used for anything else, and you can remove it from the binary using strip command, or linking with -Wl,-s flag.
After strip the disassembly looks like this:
105a: c7 05 c8 2f 00 00 05 movl $0x5,0x2fc8(%rip) # 402c <__cxa_finalize#plt+0x2ffc>

Crypto++ aes-256-ecb result is different with openssl

I'm trying to encrypt a simple string such as "Hello World!" via Crypto++, and decrypt it via Crypto++ succeed. but I got an error when decrypt Crypto++ encrypted result via OpenSSL command.
My C++ code:
#include <iostream>
#include <aes.h>
#include <base64.h>
#include <modes.h>
std::string aes_encrypt(std::string key, std::string plain)
{
std::string result;
CryptoPP::ECB_Mode<CryptoPP::AES>::Encryption ecb_encryptor((byte *)key.c_str(), CryptoPP::AES::MAX_KEYLENGTH);
auto encryptor = new CryptoPP::StreamTransformationFilter(ecb_encryptor,
new CryptoPP::Base64Encoder(new CryptoPP::StringSink(result), false),
CryptoPP::StreamTransformationFilter::ZEROS_PADDING);
CryptoPP::StringSource(plain, true, encryptor);
return result;
}
std::string aes_decrypt(std::string key, std::string cipher)
{
std::string result;
CryptoPP::ECB_Mode<CryptoPP::AES>::Decryption ecb_decryptor((byte *)key.c_str(), CryptoPP::AES::MAX_KEYLENGTH);
auto decryptor = new CryptoPP::Base64Decoder(new CryptoPP::StreamTransformationFilter(ecb_decryptor,
new CryptoPP::StringSink(result),
CryptoPP::StreamTransformationFilter::ZEROS_PADDING));
CryptoPP::StringSource(cipher, true, decryptor);
return result;
}
int main(int argc, char **argv)
{
const char *key = "1234567890";
const char *plain = "Hello World!";
std::cout << "plain: " << plain << std::endl;
std::string cipher = aes_encrypt(key, plain);
std::cout << "cipher: " << aes_encrypt(key, plain) << std::endl;
std::cout << "plain: " << aes_decrypt(key, cipher) << std::endl;
return 0;
}
Output:
plain: Hello World!
cipher: bVgt4KsCOTULujusMJvhhw==
plain: Hello World!
OpenSSL command:
xxx#xxxdeMacBook-Pro ~ $ echo -n 'Hello World!' | openssl enc -e -aes-256-ecb -nosalt -a -A -pass pass:1234567890
7sQWFmxUUQ8DpoXh9DXS8g==
xxx#xxxdeMacBook-Pro ~ $ echo -n '7sQWFmxUUQ8DpoXh9DXS8g==' | openssl enc -d -aes-256-ecb -nosalt -a -A -pass pass:1234567890
Hello World!
Try to use OpenSSL to decrypt Crypto++ result failed:
xxx#xxxdeMacBook-Pro ~ $ echo -n 'bVgt4KsCOTULujusMJvhhw==' | openssl enc -d -aes-256-ecb -nosalt -a -A -pass pass:1234567890
bad decrypt
78710:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/crypto/evp/evp_enc.c:330:
That's because you're using a different padding (Zero Padding in Crypto++ vs. PKCS#7 padding in OpenSSL) and a completely different key.
In OpenSSL, the key is derived from the password that you provide (it's called -pass after all) using the EVP_BytesToKey function.
If you want to use a proper AES key, you can use the -K commandline option to provide a Hex encoded key (should be 32, 48 or 64 characters long).
In Crypto++ you're directly passing a broken key to ecb_encryptor. AES supports keys of 16, 24 and 32 bytes length and nothing in between. But you're providing a 10 byte key and tell Crypto++ that the key is actually 32 byte long. This probably results in a random key because the remaining bytes in memory probably contain some junk values.
If you want to use the password-based encryption of OpenSSL, Crypto++ provides an implementation of OpenSSL's EVP_BytesToKey function.
Whether you decide to use an valid AES key or a password is up to you. Remember that an AES key is supposed to be randomly generated to be secure and a password must be long enough to provide any good security. I would say the password must be roughly 30% longer than the bit strength that you're going for (for 128 bit security you would need a randomly generated password of 21 characters containing uppercase, lowercase letters and digits).
Security considerations:
You should never use ECB mode. It's deterministic and therefore not semantically secure. You should at the very least use a randomized mode like CBC or CTR. It is better to authenticate your ciphertexts so that attacks like a padding oracle attack are not possible. This can be done with authenticated modes like GCM or EAX, or with an encrypt-then-MAC scheme.

Struggling to decrypt a CENC-encoded file with Bento4 tools

I have a file which i've encrypted in CENC, and i'm trying to now decrypt it using mp4decrypt from the bento4 mp4decrypt tools. The file consists of a single h264 track in an mp4 file. This is the output of mp4info --verbose
File:
major brand: dash
minor version: 0
compatible brand: iso6
compatible brand: dash
Movie:
duration: 0 ms
time scale: 120000
fragments: yes
Found 1 Tracks
Track 1:
flags: 7 ENABLED IN-MOVIE IN-PREVIEW
id: 1
type: Video
duration: 0 ms
language: und
media:
sample count: 0
timescale: 120000
duration: 0 (media timescale units)
duration: 0 (ms)
bitrate (computed): 6386.097 Kbps
display width: 1920.000000
display height: 817.021271
Sample Description 0
[ENCRYPTED]
Coding: encv
Scheme Type: cenc
Scheme Version: 65536
Scheme URI:
Protection System Details:
[schi] size=8+32
[tenc] size=12+20
default_AlgorithmID = 1
default_IV_size = 8
default_KID = [23 b6 70 1b e9 8b 4e ea 80 4e 9b 59 6c 59 37 a5]
Bytes: 0000000000000001000000000000000000000000000000000780033000480000004800000000000000010a41564320436f64696e670000000000000000000000000000000000000000000018ffff000000476176634301640028ffe1002e67640028acc8501e019effc0c7c0c81a808080a000007d200017701c00000301c9c380000773595359803c60c65801000668e938233c8f
Coding: avc1 (H.264)
Width: 1920
Height: 816
Depth: 24
AVC Profile: 100 (High)
AVC Profile Compat: 0
AVC Level: 40
AVC NALU Length Size: 4
AVC SPS: [67640028acc8501e019effc0c7c0c81a808080a000007d200017701c00000301c9c380000773595359803c60c658]
AVC PPS: [68e938233c8f]
Codecs String: avc1.640028
So to decrypt it using the above key, surely I would do:
mp4decrypt --key 1:23b6701be98b4eea804e9b596c5937a5 --show-progress input.mp4 output.mp4
MP4 Decrypter - Version 1.4
(Bento4 Version 1.5.0.0)
(c) 2002-2015 Axiomatic Systems, LLC
usage: mp4decrypt [options] <input> <output>
Options are:
--show-progress : show progress details
--key <id>:<k>
<id> is either a track ID in decimal or a 128-bit KID in hex,
<k> is a 128-bit key in hex
(several --key options can be used, one for each track or KID)
note: for dcf files, use 1 as the track index
note: for Marlin IPMP/ACGK, use 0 as the track ID
note: KIDs are only applicable to some encryption methods like MPEG-CENC
--fragments-info <filename>
Decrypt the fragments read from <input>, with track info read
from <filename>.
All I get is zero output on the command-line, and the output file is still unplayable.
Any ideas? the video track is for the whole file, it's not split into segments itself.
You are trying to decipher the file with the Key ID instead of the Key itself. "23 b6 70 1b e9 8b 4e ea 80 4e 9b 59 6c 59 37 a5" is the identifier of the key, not the key itself. Sure you will not decipher. It is in the file in order for the DRM system to retrieve the key (sending or searching the keyID for getting the Key itself in return).
Try to use the key value to decipher.
Your mp4encrypt command should have been used with an option like:
--key 1::0000000000000000
as your IV size is 8

Resources