im sorry if this is a stupid question but i was curious, i have this code that translates into my name im wondering what hash function its using, i thought it was md5
this is my name:
saleh
and this is the code
9LjZ6QoOB1A%253d
pleaaase help
It's definitely not MD5 -- MD5 output always consists of 32 hexadecimal characters.
Related
If i create a SHA-256 has in the terminal i get a nice looking hex hash:
echo -n ChillyWilly | sha256sum
4c74e3994a247dfc31a515721528c78bb6ec09ccdcfd894d09f4aa44131393a8 -
If i try to do the same with the crypt(3) function then i get something entirely different:
const char* what = crypt("ChillyWilly", "$5$");
printf("%s\n", what);
$5$$fQITOGYPwBrwOSpjX1Uhx5Ock/J84zbrqmTtg/SlvMB
It looks like Base64 but it's not.
My assumption is that if the key and salt are equal then i should get the same result. All SHA-256 hashers in the web will generate the same result from the same key/salt combination.
How can i get the same hex hash with the crypt(3) function? I have set the $5$ as instructed on the crypt manpage that should force the crypt function into SHA-256 mode.
I know there are a few similar questions here but they did not seem to contain the correct answers.
Thanks!
While crypt can use SHA-256 when in $5$ mode, they aren't the same thing.
SHA-256 is a hash function, designed to run quickly. But crypt is a key-derivation function intended for hashing passwords. As such, it runs SHA-256 a large number of times (5000 by default) to make it slower and less prone to brute-force attacks. So it will give a different result than a simple SHA-256 use. You can see the details of the algorithm here.
As you saw, crypt also doesn't output the result as hex, but as a Base64-like encoding (not the standard Base64 but based on a similar idea). There's no point in trying to convert to hex if you do this expecting to get the same result as SHA-256.
crypt() will in fact use the same SHA-256 algorithm - but it does not return the hash as you would expect. After computing the hash it does it applies another transformation to the result, as seen here.
So I wouldn't count on using it and getting the same result as sha256sum, since it's built for a different purpose. You might look into using the openssl SHA256 implementation, or something else if you need it to match.
There is a problem parsing the subject in the mail header.
For example, the form of the subject is as follows.
subject: =?iso-2022-KR?B?DjlMOC4PIA....gyDzogT?=
My guess is that base64 decoding should include the escape character -SO, SI, ESC$)C-. However, decoding is not included.
How can I get a normal string?
I hope the results are as below.
Subject: like this, 안녕하세요.
Please give me a hint how to respond at the code level. in C
Update
sorry. I had a SO, SI, but I missed it. But there was no ESC$)C, The problem is resolved immediately and shared for others.
In the absence of a ESC$)C, the libiconv is a problem, but the gconv(in glibc) was not a problem. What I used was the libiconv. Changing to gconv has solved the problem.
thanks.
So in =?iso-2022-KR?B?DjlMOC4PIA....gyDzogT?= the Bsandwiched by question marks means base64 encoded. The iso-2022-KR is the character set. The DjlMOC4PIA....gyDzogT is the base64 encoded title.
You first base64 decode the title. It's easy to find a solution for this in C.
This will leave you with an array of binary bytes which is the title encoded in the ISO-2022-KR character set. Presumably you want to convert that to UTF-8 or some other character set your computer can handle. Your best bet for this part is to use a character set conversion utility. If you are on Linux or macOS, you can use the iconv library. See iconv_open, iconv and iconv_close.
Where is correct checking char* array is AES 128/192/256 crypt, or non crypt - is text?
not use OpenSSL, pls.
tldr: If you want a 100%-working solution, it´s completely impossible.
Long version:
First, stop thinking "binary vs text". That´s not how it works.
AES ciphertext surely is binary data in the computer, but "text" is too.
If you want do distinguish AES ciphertext from other non-AES data, it´s impossible because:
AES ciphertext can be some unreadable gargabe, but it can be a poem of Goethe too.
Every possible data thing can be ("is") a AES ciphertext for some plaintext with some key.
Non-AES data can be as much unreadable garbage as AES data. (Pseudo-) Random bytes as example: AES with proper input is an excellent random byte generator.
The other way round; if you want to distinguish proper and sane human-readable text from other things, it´s impossible because: There is no law or something what "text" is in your computer.
If you want to search for english letters, consider following points:
As said above, readable words can be AES ciphertext too.
English letters? What´s about German, Japanese, old Greek, Russian...?
How are letters mapped to bytes? ISO88591, UTF16LE with BOM, EBCDIC, own mappings...?
What´s about file formats like MS Word *.doc? In it, there´s text
too, yet it´s binary "garbage" data. Or compression algorithms: Gzip,
Rar etc. doesn´t make text less sane.
If you finally extracted proper letters, how do you know if it isn´t something like "miodsjoiusdJf"? Recognizing words and their meaning is a very big topic on it´s own, and nearly everything in it is guesswork.
I downloaded a file and used md5sum to see if the download was successful without corruption. I got the following value:
a7099fcf9572d91b10d0073b07e112cb ./Macaca_mulatta.MMUL_1.70.dna.chromosome.1.fa.gz
But when I checked the website I downloaded the file from, it gave me the following value.
10256 63747 Macaca_mulatta.MMUL_1.70.dna.chromosome.1.fa.gz
What is this 10 digit code? is it not md5?
I downloaded the file from : ftp://ftp.ensembl.org/pub/release-70/fasta/macaca_mulatta/dna/CHECKSUMS
Ensembl is using the unix 'sum' utilty to calcualte the CHECKSUM.gz file.
Here's more info about the program : http://en.wikipedia.org/wiki/Sum_%28Unix%29
To see if your download is correct, try:
sum Macaca_mulatta.MMUL_1.70.dna.chromosome.1.fa.gz
NOTE: It happened before that Ensembl did not update their CHECKSUM file so it can always happen that the download is correct but the CHECKSUM.gz file is incorrect.
They are not the same thing. MD5 is a checksum but there are other checksum algorithms that are not MD5, such as SHA, CRC etc.
Generally a checksum is a function that takes an input that's larger in size than its output and (it better) produces greatly different outputs even if one bit in the input is changed.
The output you're looking at consists of two 5-digit decimal numbers, so it's likely your checksum algorithm is CRC32. The unix sum command may be used to calculate/verify it.
MD5 is a way to do a checksum, but there are others. CRC is one, so is SHA. All MD5 does is produce a hash code, and it is not the only algorithm to do so. I'm not sure what the 10 digit one is, but it can't be MD5.
i'm using MD5 hashing to encrypt passwords for a program. But it is not creating all the characters and that to some are unreadable.
Here is an screenshot.
link-http://i46.tinypic.com/2qvf2o2.jpg
Any help is appreciated
Thanks
Presumably you want to convert the array of bytes returned by MD5 to a hexidecimal string for display. Something like d131dd02c5e6eec4.
Here's how you can do that:
In Java, how do I convert a byte array to a string of hex digits while keeping leading zeros?
You're interpreting the bytes returned by MD5 as raw character data.
Since MD5 does not return bytes that represent characters, you get meaningless results.
What you're getting back is a binary value. So it's a bunch of raw bytes that may or may not map to valid characters in your default codepage. What you should do is convert the byte[] to hex. You can use something like Apache Commons Codec to encode this. http://commons.apache.org/codec/apidocs/org/apache/commons/codec/binary/Hex.html#encodeHex(byte[])