I'm curious about some basics of MD5 encryption I couldn't get from Google, Java questions here nor a dense law paper:
1-How to measure, in bytes, an MD5 hash string? And does it depends if the string is UNICODE or ANSI?
2-Is MD5 an assymetric algorythm?
Example: If my app talks (http) to a REST webservice using a key (MD5_128 hash string, ANSI made of 9 chars) to unencrypt received data, does that account for 9x8=72 bytes in an assymetric algorithm?
I'm using Windevs 25 in Windows, using functions like Encrypt and HashString, but I lack knowledge about encryption.
Edit: Not asnwered yet, but it seems like I need to know more about charsets before jumping to hashes and encryption. https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/
An MD5 hash is 128 bits, 16 bytes. The result is binary, not text, so it is neither "ANSI" nor "Unicode". Like all hashes, it is asymmetric, which should be obvious from the fact that you can hash inputs which are longer than 128 bits. Since it is asymmetric, you cannot "unencrypt" (decrypt) it. This is by design and intentional.
I was trying to hash 'abc' as a hex number input on two different sites, but both give different hash.
Later I found out, that one site interprets it as '0abc' and the second one as 'abc0'.
Since I'm finishing my sha256 hashing program, I was wondering which one is correct.
Thank you
On my NetBSD system, there is a password hash in master.passwd that looks like this:
$sha1$[5 numbers]$[8 letters]$[17 alpha numeric].[10 alpha numeric]
For privacy concerns I left out the actual values. Would someone be willing to explain the different parts of this? I was under the impression that SHA1 resulted in 20 bytes, so I was very confused about what part was the actual hash, and what part was the salt, and what part everything else was.
The relevant parts can be found in NetBSD src/lib/libcrypt.
For the format: crypt-sha1.c
The format of the encrypted password is:
$<tag>$<iterations>$<salt>$<digest>
where:
<tag> is "sha1"
<iterations> is an unsigned int identifying how many rounds
have been applied to <digest>. The number
should vary slightly for each password to make
it harder to generate a dictionary of
pre-computed hashes. See crypt_sha1_iterations.
<salt> up to 64 bytes of random data, 8 bytes is
currently considered more than enough.
<digest> the hashed password.
The digest is 160 bits = 20 bytes, but it is encoded using base64 (4 bytes for 3 source bytes) to 28 bytes (with one zero padding byte). See util.c for that.
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 am new to decoding techniques and have just learnt about base64, sha-1, md5 and a few others yesterday.
I have been trying to figure out what "orkut" worms actually contain.
I was attacked by many orkut spammers and hackers in the past few days, and there is a similarity in the URLs that they send to us.
I don't know what information it contains but I need to figure it out.
The problem lies in the following texts:
Foo+bZGMiDsstRKVgpjhlfxMVpM=
lmKpr4+L6caaXii9iokloJ1A4xQ=
The encoding above appears to be base64 but it is not, because whenever I try to decode it using online base64 decoders, I get raw output and it doesn't decode accurately.
Maybe some other code has been mixed with base64.
Can anyone please help me to decode it?
It's part of an orkut worm. This page has some details. Notice it mentions the JSHDF["Page.signature.raw"] variable you're finding these strings in.
It's a SHA1-hash of the page it was found on. This page shows the decoded form of it.
The encoding above appears to be base64 but it is not, because when-ever I try to decode
it using online base64 decoders I get raw output and it doesn't decode accurately.
What makes you think that the decoding is incorrect? Typically you'd base64 or hex encode binary content so that it can be transported as text. You wouldn't base64 encode text so it isn't surprising that decoding the strings you've provided above results in ASCII gobbledygook.
Haha, if it was that easy, it would not be worth a hack! You have to try a lot harder than just simply decoding it once.
They could be merely hashes.
If they are hashes, "reversing" them is algorithmically impossible if the original content is over a certian size, because after a certain source data size, hashing becomes a lossy compression function.
Often times Foo+whatever is the result of a salted hash. It is common to store hash results with salt, and the salt can be stored in the clear. To separate the salt from the actual hash value, a + sign is commonly used.
Base64 is used, so that the binary result of the hash can be stored in text. You can tell that the last part of those strings might be valid Base64 because Base64 content will always be a multiple of 4. It outputs 4 valid ASCII characters for every 3 bytes of input. It pads the end with "=" signs.
So, for Foo+bZGMiDsstRKVgpjhlfxMVpM=, this may be the result of taking some input, be it a message of some sort, or whatever, and applying the salt "Foo", and then hashing the result. The string value bZGMiDsstRKVgpjhlfxMVpM= likely is the binary result of some hash function. An online Base64 decoder shows that the value, in Hex, instead of Base64, is { 6D 91 8C 88 3B 2C B5 12 95 82 98 E1 95 FC 4C 56 93 }. Yes, this is not ASCII text.
Base64, binary, hexadecimal, decimal, are all ways of representing values. Think of the part after the + as just a number. The above 136-bit number may be the result of a 128-bit hash, and an 8-bit CRC, for example. Who knows? I don't know why you're getting spammed, or why these spam messages have these strings attached to them, but this may be some insight into the nature of the structure of the strings.