if there is a password longer then 14 characters, how would LM hash the characters after the 14th and how would it combine it with the hashing from the first 14 characters?
Thank you in advance
Note: LM hash is compromised and should not be used anymore.
LM hash does not support strings longer than 14 characters. If you are going to use the algorithm internally only and do not need compatibility with other systems, you could for example compute separate hashes for each 14 byte block and xor them together.
Related
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 have the starting 6 characters of a hash e.g. 48bf5c
And I do know that my salt is of format : "watch__bisqwit__" + randomString (of length 7 -25)
I want to find a randomString such that hash generated will have the same starting characters.
My brute-forcing solution:
So for above starting 6chars (48bf5c), I will get hash as 48bf5c2260fb658b4eb389026831ad23 (not really useful for the problem) and salt as watch__bisqwit__2EZrgDzAkYdKHR1HP5tn (need to use this).
My brute forcing solution takes about 5-10 mins to get me to the solution.
Thanks in advance.
Whats the smallest hash I can get without making things overly collidable? I figure a good example is hashing "foo".
input = foo
sha1 = 0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33
sha1 + b64 = C+7Hteo/D9vJXQ3UfzxbwnXaijM
Are there any other standards out there like Base64 that utilize unicode characters? maybe including upper/lower umlaut characters such as Ü and ü to pack more bits into each character? Ideally I'd love to compress the sha1 hash into 4-6 unicode characters I can tack onto a URL.
Reversibly encoding the hash doesn't impact collision rate... Unless your encoding causes some loss of data (then it isn't reversible any more).
Base64 and other binary-to-text encoding schemes are all reversible. Your first output is the hexadecimal (or base16) representation, which is 50% efficient. Base64 achieves 75% efficiency, meaning it cuts the 40-character hex representation to 28 characters.
The most efficient binary encoding scheme is yEnc, which achieves 98% efficiency, meaning a 100 byte long input will be roughly 102 bytes when encoded with yEnc. This is where the real problem arises for you: SHA-1 outputs are 160 bits (20 bytes) long. If you achieve 200% character-byte efficiency by using every 2-byte UTF16 character, you're still looking at 10 characters. You can't achieve this, because 2-byte values from U+D7FF to U+E000 are not valid UTF16 characters. Those byte values are reserved as prefixes for higher-plane characters.
Even if you find such a hyper-efficient1 encoding scheme using unicode, you can't really use those as URLs. Unicode characters are forbidden from URLs and to be standards compliant, you should use % encodings for your URLs. Many browsers will automatically convert them, so you may find this acceptable, but many of the characters you would regularly use would not be human readable and many more would appear to be in different languages.
At this point, if you really need short URLs, you should reconsider using a hash value and instead implement your own identity service (e.g. assign every page or resource an incremental ID, which is admittedly hard to scale) or utilizing another link-shortening service.
1: This not possible from a bit standpoint. Unicode could achieve a higher character-to-bit ratio, but the unicode characters themselves are represented by multiple bytes. The % encodings for UTF8, which most browsers use as the default for unrecognized encodings, get messy quickly.
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.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why UTF-32 exists whereas only 21 bits are necessary to encode every character?
The maximum Unicode code point is 0x10FFFF in UTF-32. UTF-32 has 21 information bits and 11 superfluous blank bits. So why is there no UTF-24 encoding (i.e. UTF-32 with the high byte removed) for storing each code point in 3 bytes rather than 4?
Well, the truth is : UTF-24 was suggested in 2007 :
http://unicode.org/mail-arch/unicode-ml/y2007-m01/0057.html
The mentioned pros & cons being :
"UTF-24
Advantages:
1. Fixed length code units.
2. Encoding format is easily detectable for any content, even if mislabeled.
3. Byte order can be reliably detected without the use of BOM, even for single-code-unit data.
4. If octets are dropped / inserted, decoder can resync at next valid code unit.
5. Practical for both internal processing and storage / interchange.
6. Conversion to code point scalar values is more trivial then for UTF-16 surrogate pairs
and UTF-7/8 multibyte sequences.
7. 7-bit transparent version can be easily derived.
8. Most compact for texts in archaic scripts.
Disadvantages:
1. Takes more space then UTF-8/16, except for texts in archaic scripts.
2. Comparing to UTF-32, extra bitwise operations required to convert to code point scalar values.
3. Incompatible with many legacy text-processing tools and protocols. "
As pointed out by David Starner in http://www.mail-archive.com/unicode#unicode.org/msg16011.html :
Why? UTF-24 will almost invariably be larger then UTF-16, unless you
are talking a document in Old Italic or Gothic. The math alphanumberic
characters will almost always be combined with enough ASCII to make
UTF-8 a win, and if not, enough BMP characters to make UTF-16 a win.
Modern computers don't deal with 24 bit chunks well; in memory, they'd
take up 32 bits a piece, unless you declared them packed, and then
they'd be a lot slower then UTF-16 or UTF-32. And if you're storing to
disk, you may as well use BOCU or SCSU (you're already going
non-standard), or use standard compression with UTF-8, UTF-16, BOCU or
SCSU. SCSU or BOCU compressed should take up half the space of UTF-24,
if that.
You could also check the following StackOverflow post :
Why UTF-32 exists whereas only 21 bits are necessary to encode every character?