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.
Related
Being a pentester, I have encountered a hash divided in two parts (the first one probably being the salt) seemingly encoded in Base64 but I am unable to find out the encryption type.
The input that gave me this hash is the string "password". Is anybody able to give me a hint ?
67Wm8zeMSS0=
s9bD0QOa7A6THDMLa39+3LmXgcxzUFdmszeZdlTUzjY=
Thanks in advance
Maybe it's SHA-256 encoded (or any other 256 bit hash algorithm), because if you base64 decode it and hex encode you get:
ebb5a6f3378c492d
b3d6c3d1039aec0e931c330b6b7f7edcb99781cc73505766b337997654d4ce36
The first has an length of 16 and the second a length of 64. That's probably not a coincidence.
Edit: Maybe it's hashed multiple times; an iterated hash. As this post says it is better to decompile the software.
Only the first 8 characters is encrypted when the Perl crypt function is used. Is there a way to get it to use more characters?
As an example:
$crypted_password = crypt ("PassWord", "SALT");
and
$crypted_password = crypt ("PassWord123", "SALT");
returns exactly the same result. $crypted_password has exactly the same value.
Would love to use crypt because it is a quick and easy solution to some none reversible encryption but this limit does not make it useful for anything serious.
To quote from the documentation:
Traditionally the result is a string of 13 bytes: two first bytes of the salt, followed by 11 bytes from the set [./0-9A-Za-z], and only the first eight bytes of PLAINTEXT mattered. But alternative hashing schemes (like MD5), higher level security schemes (like C2), and implementations on non-Unix platforms may produce different strings.
So the exact return value of crypt is system dependent, but it often uses an algorithm that only looks at the first 8 byte of the password. These two things combined make it a poor choice for portable password encryption. If you're using a system with a stronger encryption routine and don't try to check those passwords on incompatible systems, you're fine. But it sounds like you're using an OS with the old crappy DES routine.
So a better option is to use a module off of CPAN that does the encryption in a predictable, more secure way.
Some searching gives a few promising looking options (That I haven't used and can't recommend one over another; I just looked for promising keywords on metacpan):
Crypt::SaltedHash
Authen::Passphrase::SaltedDigest
Crypt::Bcrypt::Easy
Crypt::Password::Util
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.
Use AES/Rijndael or any symmetric encryption.
Encrypt the hidden value using itself as the key and a random IV.
Store the ciphertext + IV. Discard everything else.
To check the hash: try to decrypt using provided plaintext. If provided == decrypted, then it's OK.
Ignore ciphertext length problems.
Is this secure?
There is an existing method of generating a hash or MAC using an block cipher like AES. It's called CBC-MAC. It's operation is pretty simple. Just encrypt the data to be hashed using AES in CBC mode and output the last block of the ciphertext, discarding all prior blocks of the ciphertext. The IV for CBC would normally be left as zero, and the AES key can be used to produce a MAC.
CBC-MAC does have some limitations. Do not encrypt and MAC your data using the same key and IV, or the MAC will simply be equal to the last block of the ciphertext. Also, the size of the hash/MAC is limited to the size of block cipher. Using AES with CBC-MAC produces a 128 bit MAC, and MACs are usually expected to be at least this size.
Something worth noting is that CBC-MAC is a very inefficient way to produce a MAC. A better way to go would be to use SHA2-256 or SHA2-512 in HMAC. In my recent tests, using SHA256 in HMAC produces a result approximately as fast as AES in CBC-MAC, and the HMAC in this case is twice as wide. However, new CPUs will be produced with hardware acceleration for AES, allowing AES in CBC-MAC mode to be used to very quickly produce a 128 bit MAC.
As described, it has a problem in that it reveals information about the length of the data being hashed. That in itself would be some kind of weakness.
Secondly ... it is not clear that you would be able to check the hash. It would be necessary to store the randomly generated IV with the hash.
I was thinking about this while bicycling home, and one other possible issue came to mind. With a typical hashing scheme to store a password, it is best to run the hash a bunch of iterations (e.g., PBKDF2). This makes it much more expensive to run a brute force attack. One possibility to introduce that idea into your scheme might be to repeatedly loop over the encrypted data (e.g., feed back the encrypted block back into itself).
I want to use AES encryption in my application. I have come across some open source implementations of aes algorithm. By looking at them, I am confused about the following parameters:
AES key length. It is mentioned that key length should be 128, 192 or 256 bytes. What if my key is simply five digits i.e. 23467
AES plain-text length : is there any restriction on the aes plain-text length ?
AES output: What would be the minimum size of aes output string if my key length is say 5 digits and plain-text is say 10 characters.
Can anyone help me?
AES key length. It is mentioned that key length should be 128, 192 or 256 bits. What if my key is simply five digits i.e. 23467
It seems you're thinking of the key as a password of sorts. It isn't. A cryptographic key isn't meant to be memorized. It is a long string of randomly generated bytes that should be stored somewhere safe.
You can derivate a cryptographic key from a password, though, for instance using a hash function. In that case you input 234567 and use the resulting digest as the key. This has some security implications, however, as it makes your key vulnerable to dictionary and rainbow table attacks. Look up "password based encryption" for details on how to approach this securely; in particular, have a look at PBKDF2, described in RFC2898.
AES plain-text length : is there any restriction on the aes plain-text length ?
AES is the block cipher, the underlying building block of an encryption system. By itself it can only encrypt a single block of data (16 bytes), so cryptographers have created several "modes of operation" that enable us to encrypt a plaintext of arbitrary length. CTR is a fine example of a mode of operation that does not require any padding and can be parallelized.
AES output: What would be the minimum size of aes output string if my key length is say 5 digits and plain-text is say 10 characters.
That's entirely dependent on the mode of operation. In your case it will probably be either 10 (when no padding is required, for example with CTR) or 16 (for block-based modes such as CBC).
I think you mean 128 and 256. (Not 198.)
That's not a key. That's a password. You use an algorithm like PBKDF1 (google it) to derive a key from a password.
No. AES is a block cipher. It works on input blocks that are the same size as the key. You can use as many blocks as you like, chopping up your input into (say) 128-bit blocks. Make sure you use CBC or a similar mode for AES.
Your key is 128 or 256 bits. Your input would be 80 bits (10*8), padded to 128 or 256. Your output length is the same as the key size.
Try to find a crypto library that does most of the work for you. You don't want to mess around with just a basic AES function. You also need to handle IVs, AES modes, possibly a MAC, etc. I can't recommend anything because you don't say what language you're trying to use.