Tag Info

We call a primitive broken, if there is any attack faster than bruteforce/what we expect of an ideal primitive. Broken does not mean that there are practical attacks. There are no known collisions in SHA-1. Still we call collision resistance of SHA-1 is broken, because there is a theoretical attack that can find collisions using fewer than $2^{80}$ calls to ...

There is a reasonably good explanation in Wikipedia. The idea is the following: SHA-1 is built around an internal "compression function" which takes as input the 160-bit state and a 512-bit message block, and returns a new state. The padding is designed so that it can be proven that a collision over the hash function necessarily implies at some point a ...

I would recommend phasing out SHA-1 in any scenario where collision-resistance of a hash is required, for there is a wide consensus that an attack with $2^{69}$ complexity would work, it would already be feasible by a resourceful entity, and attacks only get better. I'm still confident that SHA-1 is preimage and second-preimage resistant for all practical ...

The echo command will include a newline at the end. So when you use echo 'Rosetta Code' | sha1sum you are actually hashing the string Rosetta Code\n. Do the test using echo -n, the -n flag prevents the trailing newline character. Doing echo -n 'Rosetta Code' | sha1sum gives the same 48c98f7e5a6e736d790ab740dfc3f51a61abe2b5 hash that you were seeing ...

No, theoretically a SHA1 hash can be any 160-bit value, including the string of 160 zeroes. As for your second question, if we fudge a little bit and consider SHA1 a truly random function this becomes the same question as the following: If we flip 160 coins, what is the probability that at least 128 of them will be heads? Solution is left as an exercise ...

password = sha1 ( mainPassword . domainName . number ) Is this secure enough? Answer is no. Let me explain. The only part that is really unknown in the above is mainPassword. The rest can easily be guessed by a hacker. If your original password is weak (not many characters, no digits, no specials characters), the number of combinations to test is ...

The chance of a collision in such a set is approximately $ \frac{1/2 \cdot n^2}{2^{160}} $, which for n=100k evaluates to about $ 3.4 \cdot 10^{-39} $. So it is fair to say, such a collision won't occur accidentially. AFAIK nobody has every found a SHA-1 collision. Collisions become likely once you generate about $2^{80}$ or $10^{24}$ hashes. If ...

Well, the entire point of a cryptographical hash function is that no one can practically devise two messages that hash to the same value. Now, the SHA family of hashes use the Merkle–Damgård construction; that is, they have an iterated hash function, and each invocation of the hash function takes as input a fixed block size (either 512 or 1024 bits in the ...

If your password database will never be compromised, you can store plaintext passwords and nobody will be bothered. The only thing about plaintext passwords is that they can be accidentally remembered by admins who see them - a simple base64 will fix that. Equivalently, MD5 or SHA1, with salt or without, is just as fine. If your password database is ...

The main route of attack on your algorithm is not somehow "breaking SHA-1", but a brute-force/dictionary attack on all possible values of mainPassword. For this, using n-times iterated SHA-1 takes n-times the work as normal SHA-1, both for you and for the attacker. To make this really helpful, you should take a really high value for n - such as 2^20 or ...

Here is the relevant part of the algorithm (from Wikipedia, reformatted): Pre-processing: append the bit 1 to the message append 0 ≤ k < 512 bits 0, so that the resulting message length (in bits) is congruent to 448 ≡ −64 (mod 512) append length of message (before pre-processing), in bits, as 64-bit big-endian integer This ...

Systems that do this already exist, such as SuperGenPass. To address your questions in order: I mean if somebody know my algorithm and one or many passwords, could he find easily one of my other password? Easily? No. As long as SHA1 remains a secure hash function (which is currently the case, but all hash functions have a lifetime), the only way for ...

If you have an implementation of an integer modulo operator, then $$k = (447 - l) \bmod 512$$ should be the right solution. If your modulo operator can return negative results, do this: $$k = ((447 - l) \bmod 512 + 512) \bmod 512$$ This seems simpler than using your division and flooring. That said, you actually don't really need the number of zero ...

In practice (i.e. when actually implementing the function), you do not really calculate $k$. Things rather work like this: you have a 64-byte buffer. You process incoming data through that buffer; when it is full, you apply the compression function, which mutates the internal state (five 32-bit words for SHA-1, eight for SHA-256), and begin again at offset 0 ...

Answering the question as worded in its body: NO, $\mathrm{SHA1}$ is not designed so that the proposed construction is secure under the stated conditions. The design objective of the $\mathrm{SHA1}$ and $\mathrm{SHA2}$ hashes, as explained by NIST, is that it is computationally infeasible to find a message that corresponds to a given message digest, or ...

echo -n "06b2f82fd81b2c20" | sha1sum e42d65afd2bc126a2e8e609257287084c43fc06a echo -n "02c60cb75083ceef" | sha1sum e42d65afd277988908c01bc539c9d71aff728322 Notice the first ten characters of the SHA1 hash match, indicating a 40-bit match. Other pairs are 0534164decf1166c, 06670357183cba13 and 0addd115537e4b39, 09a3cbdd0d00773b. Note that I am ...

The distinction between real and fake salt is arbitrary. I suppose that your method would be called "fake salt" by those who make the distinction (concatenation versus "separate input parameter to the algorithm), but there is not really a difference in practice, as long as the hash algorithm is secure. A bit more secure (in the sence of "provenly secure") ...

325 MB/s is already good, i.e. you will not get much more with another implementation. Also, SHA-1 is a sequential algorithm, so multiple cores or a GPU will not help you. Specialized hardware is probably your best bet to make SHA-1 faster. (Also, if SHA-1 is the bottleneck then you are able to move data around faster than that, which is impressive; ...

In many existing padding schemes, without padding always being added there is a trivial second preimage attack. For simplicity let's assume a 10 bit hash function $h_{10}$ (extending this to other size hash functions is trivial). Let $m_1=101$ and $m_2=1011000000$. I claim that $h_{10}(m_1)=h_{10}(m_2)$. Since $m_2$ is 10 bits, no padding is needed. Since ...

SHA1 is fully described (including complete test vectors) in this FIPS publication, if you wanted to do it properly. But I think checking against the final digests of a couple inputs should be enough to point you to the correct version. I extracted them for you (inputs in ASCII, quotation marks excluded): "abc" (3 bytes) ...

Essentially yes, they do. Depending on the exact hash function you choose depends on the length of output you'd expect. For example, SHA256 produces 256 bits of output. This does then beg the question "but the length of the hash is fixed and there are infinite possible inputs??!!". That's correct, except that $2^{256}$ is ...

The two proposals in the question have their advantages and disadvantages. Using MD5 There are three major types of attacks to worry about. Preimage attacks: given $h$ find $m$ such that $H(m)=h$ Second preimage attacks: given $m$ find $m'\neq m$ such that $H(m)=H(m')$ Collision resistance: find any $m$ and $m'$ such that $H(m)=H(m')$ ...

The main advantage is speed: HMACs are much faster than an RSA signature. Given the question says you are signing SHA-1 hashes, there is no need to use a hash function in composition with RSA since the message will already be short-enough to sign directly. I doubt they are looking for an answer about the security of the underlying hash.

In step 4.1 of the algorithm: Counter is expected to be a 1 byte binary value no_of_bits_to_return is a 4 byte bigendian binary value input_string is a variable length binary value $||$ is concatination (just like you guessed) So, Hash(&bytearray) would be appropriate. The trickiest part is the 'no_of_bits_to_return' -- that's bigendian (and so a ...

For free software-based solutions on an x86_64, OpenSSL is the best around. Intel's IPP is purported to be 20% faster, and it's software-only, but it's not free (about 200USD, or 80USD for the academic version) and you have to fill out a form saying you're not from N. Korea, etc. There are hardware accelerators in the form of SSL cards/chips, but are ...

I'd recommend HMAC. It's designed to mix a key and a message in a secure way. HMAC(K,m) = H((Key ⊕ opad) ∥ H((Key ⊕ ipad) ∥ Message)). Where H is a normal hash function such as SHA1, opad and ipad are constants. ∥ stands for concatenation. The main disadvantage of HMAC is that it requires two hash function calls, which makes significantly more expensive ...

You don't need to compute this at all, this is just a mathematical description for defining the padding on the message as a whole. This is because you don't need to process the whole message at once, which is useful if the message is very large (say a very large file), or if you are on a small system with little RAM (say a microcontroller). You can fill a ...

First off, hashing is not encryption. Those are two very different concepts. You should read those links, they'll help you understand: Encryption Hash function As for your original question: What happens to the security of SHA-1 when truncated? Here is an answer that's true for all hash functions: In general using a hash function ...

SHA-1 is only academically broken. So, it is still secure for all uses. The problem is, attacks only get better. So, migrating to SHA-2 (or at least planning for a SHA-2 migration) would be a good move. That said, of interesting note is that even if SHA-1 were practically broken it might still be okay for use in HMAC.

The security of your method depends critically on the security of your main password. As Paul pointed out, it is the major difficult element in your method. It is not trivial to find a strong password, or better a strong passphrase. I often suggest Diceware for this purpose; it takes the guessing out of just how strong your master passphrase is.