I'm trying to reverse engineering an app and I'm seeing that it encrypt an string using RSA/ECB/PKCS1Padding method
before this it's loading something similar to a private key from another string with a method called "1.2.840.113549.1.12.1.3" I googled this and found out that it's a PKCS12 key
I don't have access to the codes and I'm reading this data using frida so I don't understand what’s being done actually.
What I need to do is to be able to do the same rsa encryption so I need the key for rsa
I have a sample input and output to try and test if the key is right or not. I also have a hex string which I'm guessing it’s from a pfx file, another hex string generated from the previous one which looks like a private key and another smaller hex string which might be the password for pfx (I'm not sure about this)
On further investigation I found out that class name for the key is : com.android.org.bouncycastle.jcajce.PKCS12Key
This is also the second hex string (replaced part of it with X) that I think is kind of a private key but I wasn't able to verify it :
3082035f3082035b060b2a864886f70d010c0a0103a082031430820310060a2a864886f70d01091601a0820300048202fc308202f8308201e0a00302010202106fb86aeca71187a94a49a31d57f64795300d06092a864886f70d01010b05003018311630140603550403130d524e4430382e7365702e6e6574301e170d3230303331353038353030325XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX9d4d602c133addaa58422e3af20ee97c8a9936b3134301306092a864886f70d0109153106040401000000301d06092a864886f70d01091431101e0e003700320034004e006500770000
what I tried until now :
converted the first hex string to binary and saved it into a file and then used openssl pkcs12 -in -out command to get pem formatted file, but it failed with error 4630589100:error:0DFFF0A8:asn1 encoding routines:CRYPTO_internal:wrong tag
Related
When I type
openssl sha256 filename.pdf
What value is used to create a digest? Is it a meta data of that file or every byte data of that pdf? I tried openssl sha256 on a large files(~2GB) and it did not take a long time, so my guess is that openssl does not use every byte in a file. So what value(byte) is used?
I have an authority certificate generated in PEM encoding. Does it mean I can call it both ca.pem and ca.crt? Can .crt and .pem mean the same thing? Or are they actually different formats?
To a file, file names and extensions don't matter.
Windows does maintain an association of extensions to semantic types (and semantic types to what-to-do-with-this), which is the ftype/assoc system.
C:\>assoc .cer
.cer=CERFile
C:\>ftype CERFile
CERFile=%SystemRoot%\system32\rundll32.exe cryptext.dll,CryptExtOpenCER %1
We can also ask "What are all of the associations?", and filter that:
C:\>assoc | findstr CERFile
.cer=CERFile
.crt=CERFile
.der=CERFile
So Windows will treat any of .cer, .crt, and .der the same.
PEM, on the other hand, is not a default association:
C:\>assoc .pem
File association not found for extension .pem
In general, a ".pem" would suggest that it is some data in the Privacy Enhanced Mail (PEM) format, which is
(Beginning of file or a newline)
5 hyphens
BEGIN
a space
One or more characters ending in not-a-space
5 hyphens
A newline
Base64 data, formatted 64 characters to a line
A newline
5 hyphens
END
a space
The same string as in BEGIN
5 hyphens
Newline or end-of-file
The word(s) identify the data format, which is then used by the reader. For a certificate, for example, that's "BEGIN CERTIFICATE".
Certificates really are defined in a binary syntax called DER (Distinguished Encoding Rules (for ASN.1 data)). Certificate processors ultimately need the binary data (which is what got base64-encoded), but they can differ on whether they expect DER or PEM data. To many Windows APIs the certificate can be presented in either form and the underlying system content sniffs to figure out which format the data is in.
There's no real standard or heuristic for if .cer, .crt, or .der is PEM or DER data; though one would sort of expect .der to be DER :). (But lots of things are DER-encoded; not just certificates)
Does it mean I can call it both ca.pem and ca.crt?
If you're loading things by filename, it probably doesn't matter. If you're using OpenSSL commandline tools it definitely doesn't matter (but they want the data to be PEM encoded by default).
If you're on Windows and you want double-clicking to work, you want .cer or .crt.
What is the format of public DSA key? And are all certificates are stored in base64?
Do you mean the public key format used in a certificate?
Generally, a public key in a certificate is stored in the SubjectPublicKeyInfo field (cf. RFC 5280)
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
The specifics for DSA can be found in RFC 3370. Usually the parameters of the AlgorithmIdentifier contain an instance of the Dss-Parms giving you p, k, g and the subjectPublicKey BIT STRING contains the public key y encoded as an DER-encoded INTEGER.
Concerning Base64: Strictly speaking certificates are not Base64-encoded but use an extended form of it, the PEM format, a plain text format which is the Base64 encoding of a X.509 certificate (RFC5280) enclosed between the lines
"-----BEGIN CERTIFICATE-----"
...
"-----END CERTIFICATE-----"
or
"-----BEGIN X509 CERTIFICATE----"
...
"-----END X509 CERTIFICATE----".
The certificate itself is the DER encoding of the ASN.1 structure as described in RFC 5280. See X.690 for details of DER (Distinguished Encoding Rules).
Most certificates are stored either in PEM format or directly in their raw DER-encoded form.
There is a great deal of information and references on this page for the specifications.
http://en.wikipedia.org/wiki/Digital_Signature_Algorithm
I need to generate a large random string to encrypt some passwords with in perl. The keys I am using now to encrypt with are generated from the Gibson Research Corp website. They were meant to be place holders for me to test with. Now I am looking to make something final.
I would like the key to be something enclosed in a file kinda like a SSL cert but not nearly as long, right now I am using a 64-bit key for testing I would think 1024-bit key would be a bit overkill, this key is NEVER going to be seen on the internet it is just to encrypt password in my config file from "prying" eyes more or less. The reason for it to be in file of some kind would so the encrypter could read it and the decrypter could also read and they would stay in sync using the same key rather than have to copy and paste the keys into each script and therefore have a chance of user error.
Using the Perl hex function, you can convert a decimal number into a hexadecimal one.
Here's a snippet that creates a string of 32 random hex digits:
my $rand_hex = join "", map { unpack "H*", chr(rand(256)) } 1..16;
Here's another - simpler - way to generate 32 random hex digits:
use Digest::MD5 qw(md5_hex);
my $rand_hex2 = md5_hex(rand);
I'm writing small program to encrypt/decrypt files using AES. I'm using Cryptopp library.
I need help to understand some things.
When I'm encrypting file I should write IV at the beginning of file to decrypt it later?
I wan't to check password given do decrypt file was correct. Should I:
put some string at beginning of file (ex. TRUE) before it's encrypted. After decryption check it.
Check MD5 of file before encryption. Put it at beginning of encrypted file. Read MD5 before decryption, decrypt file, check MD5 of decrypted file and compare them.
Writing the IV at the beginning of the file is fine. Appending to the end is another option.
Do not put a static string into the plaintext: ENIGMA transcripts were more easily broken for very similar reasons, and the zip format makes brute-forcing passwords very easy for this identical mistake.
The md5 approach sounds tolerable; but hmac-sha256 would provide significantly stronger integrity claims. (I think you could even re-use the AES key or the IV for hmac-sha256, but I'm not positive of its safety.)