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?
Related
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
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.
I know there's a billion answers on how to extract the modulus from an RSA key (I have a .cer file) and I want the 1024 bit (it's 1024 bit in my case) value from it. What I don't get is the following:
When I extract it, it's always not 1024 bits, but more. Has that something to do with padding or...? Looks like 136 bytes at the moment, so 64 bit too much. Not sure whether this is a constant or depends on the certificate
edit:
I retried with openssl x509 -modulus -inform PER -in file.cer and it resulted in 128 bytes. Guess that's it.
edit2:
So, this still is my problem. I did openssl x509 -inform DER -in file.cer -text and got a modulus of 129 bytes. Is my assumption correct that I can skip the first one because it is 0x00 which might just be used to make the whole thing positive again (first byte otherwise would be a 0xaa which might be negative)?
Simple question. What is the best (most universal) way to display a file hash? Below are two SHA256 hashes for the same file. One is displayed as base64 and one is...something else. The file hash will be used for auditing to make sure the file we send is the same as the file the auditor received. If the hash needs to be verified, I want to make sure I provide the hash that is the most easily verifiable.
SHA256 55461e72cccb74b475278189956b9db307bf44945e1639af93c34b224b7fcfd
SHA256 Base 64 VUYecszLdLR1J4GJlWudswe/RJReFjmvk8NLIkt/z9s=
55461e72cccb74b475278189956b9db307bf44945e1639af93c34b224b7fcfd
The point of Base64 is to constrain the character set to displayable characters. The hash is in hexadecimal which is even more constrained.
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.)