Is there a hash function with 2048bit output?

Is there a publicly available cryptographic hashing algorithm with 2048 bit output?

The standard ones are "only" up to 512 bit (SHA-512, WHIRLPOOL).

(2048 bits are 256 bytes, so it would be useful for generating a full-length key for the ARC4 cipher)

-

migrated from stackoverflow.comOct 17 '11 at 15:20

This question came from our site for professional and enthusiast programmers.

I have nothing productive to add, but might I inquire why you need such strong encryption? The usual suspects pass the brute force and mathematical attack tests very well, so usually there is no need for this "overkill", if you will. – 0xCAFEBABE Oct 17 '11 at 11:46
0xcafebabe, it seems that my answer to yout question was migrated into the question itself.. (: – mykhal Oct 17 '11 at 16:00
While this isn't a hash function at all, PBKDF2 should do what you need. It also gives you the ability to control how much time to spend on generating keys, thereby making it harder to brute force the key. – Stefano Palazzo Nov 9 '11 at 9:07

One well-known hash function that I'm aware of is Keccak. You can find a public domain reference and optimized implementations on their website.

Its output size is variable and arbitrary, so you can just set it to 2048 bits. However, the authors only make security claims up to 1592 bits...

-

I was already wondering why you would need 2048 bits, because brute forcing a 512 bit output hash takes already a $2^{256}$ operations on average (w.r.t to collision resistance, due to the Birthday Paradox – preimage and second-preimage attacks take on average $2^{511}$ hashes), which is secure enough, for all kinds of hardware available today.

I assumed that you would probably want to transform the hash output into some form of key with a length of 2048 bits, your comment confirmed this. In that case, what you need is not necessarily a hash output of that length, but you need a secure Key Derivation Function (KDF) that allows "stretching" the random hash output to the desired size.

Have a look for example at the KDF described in NIST Special Publication 800-56A: “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography ” that describes how to stretch hash outputs to arbitrary sizes securely.

When equipped with such a KDF, it basically doesn't matter what hash function you are using (as long as it itself is secure) so you can safely use one of the family hashes (SHA-256, 512 etc.).

-
i think it would be the best answer, if i wanted to derive the key from short human generated passwords. thanks – mykhal Oct 18 '11 at 14:13

Others have already questioned this to some degree. I think I'll do a bit more of the same.

About the best you can hope to get from a hash is to "distill" entropy from the input. It can't, however, produce any more entropy than the input already contained (and will usually discard at least a little).

That means for a 2048-bit has to make any real sense, you need to provide it with an input that contains at least 2048 bits of entropy. As Shannon showed long ago, English text (for one example) typically contains about one bit of entropy per character. That means for your 2048-bit result to mean much (if anything) you need to give it roughly 2048 bytes of input. That's enough that for most practical purposes you can forget about memorizing it, so you pretty much need to start from a file -- but the minute you do that you've created a much greater security vulnerability.

Under most normal circumstances, you're probably going to get more security from a shorter hash. About the only way I can see this as being even potentially useful would be stored on something like a smart card. Even then it's pretty pointless, but at least it wouldn't necessarily be hurting your security, just wasting all your smart card space on a single "password" instead of the much greater number it could normally store.

-

One lesser-know hash function is ASH-2, which is based in the SHA-512 with a rearrangement in the data input and the use of some pepper to produce the final result.

-
it looks like an interesting hobby crypto project.. :) it's funny how an author repeatedly mistyped HAVAL-128. thanks for a tip. – mykhal Oct 17 '11 at 17:26
I don't think ASH is really useful for key derivation purposes ... half of its output is the pepper, which is actually an input. – Paŭlo Ebermann Oct 17 '11 at 17:28

I don't have an answer to your question beyond what emboss gave.

However, I have to ask: why do you think you need to do this? If you're using RC4, well, RC4 can take a shorter key; do you really think that RC4 with a 256 bit key would be insufficient for your needs? RC4 has known weaknesses (both with the initial bytes and the distinguishers); if you really security requirements that a $\ge$ 256 bit key is mandated (which I really doubt), then you probably don't want RC4 at all, but instead use a better cipher (which as AES-256).

Now, you might simply be looking for cheap overkill (that is, making part of the cryptographical system far stronger than needed); IMO, there's nothing really wrong with cheap overkill (as long as you understand that this doesn't actually make the system any more secure). On the other hand, the fact that you had to ask means that this overkill might not be as cheap for you as you were hoping.

-
i don't need this, i am just curious.. btw, do you think arc4 is much weaker than aes, when discarding several thousands of first stream bytes? it at least has an advantage in not having block chaining mode weaknesses – mykhal Oct 17 '11 at 17:08
I'm curious as to what you mean by 'block chaining mode weaknesses'. I know of only three: 1) if you use a bad (predictable) IV source, 2) a couple of ways for an attacker to modify the encrypted data and get useful information (which means that you need to use a MAC to protect the data), and 3) data which is leaked if you go over the "birthday bound" (which is quite unlikely if you're using AES). (1) is easy to fix; (2) isn't an issue (RC4 also needs a MAC), and if the volume of data you have is even close to make (3) an issue, then RC4 probably isn't a good choice either – poncho Oct 17 '11 at 18:04
i won't have so strong confidence in AES security in situation when US company can sell CPUs with AES instructions, without any export regulations :) – mykhal Oct 17 '11 at 18:10
@mykhal The AES instructions just make encrytion and decryption a bit faster, not more or less secure. (Of course, you can think there is some conspiracy, so the NSA knows some weaknesses that no one else knows. I doubt that.) – Paŭlo Ebermann Oct 17 '11 at 19:18
my point was, that having the encryption standard acceleration in common hardware makes its usage yet more widespread, therefore efforts to develop AES cracking machine by certain agencies would be understandable :) planting backdoors into systems is probably more successful approach.. – mykhal Oct 17 '11 at 20:24